.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .sp 1P .ce 1000 \v'12P' \s12PART\ V \v'4P' .RT .ce 0 .sp 1P .ce 1000 \fBI.500\(hySeries Recommendations\fR \v'2P' .ce 0 .sp 1P .ce 1000 \fBINTERNETWORK\ INTERFACES\fR .ce 0 .sp 1P .LP .rs .sp 31P .ad r Blanc .ad b .RT .LP .bp .LP \fBMONTAGE: PAGE 2 = PAGE BLANCHE\fR .sp 1P .RT .LP .EF '% Fascicle\ III.9\ \(em\ Rec.\ I.500'' .OF '''Fascicle\ III.9\ \(em\ Rec.\ I.500 %' .LP .bp .sp 2P .LP \fBRecommendation\ I.500\fR .RT .sp 2P .sp 1P .ce 1000 \fBGENERAL\ STRUCTURE\ OF\ THE\ ISDN\ INTERWORKING\ RECOMMENDATIONS\fR .EF '% Fascicle\ III.9\ \(em\ Rec.\ I.500'' .OF '''Fascicle\ III.9\ \(em\ Rec.\ I.500 %' .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP \fB1\fR \fBIntroduction\fR .sp 1P .RT .PP An ISDN is a network, in general evolving from a telephony Integrated Digital Network, that provides end\(hyto\(hyend digital connectivity to support a wide range of services, including voice and non\(hyvoice services, to which users have access by a limited set of standard multi\(hypurpose user network interfaces. In contrast, existing dedicated networks have always been developed for specific (types of) services. Therefore, especially in the initial phase, the ISDN may support many services which in principle are still existent in dedicated networks. Thus, it is necessary to provide interworking between ISDN and dedicated networks to allow communication between terminals belonging to equivalent services offered through different networks. .PP There will be a need for interworking functions (IWF) between ISDN and dedicated networks to cope with the different environments given by the various networks. The structure of these IWFs showing the functions necessary for the mapping should be uniform to permit, if possible, a common use of functional parts in several IWFs. Detailed description of these IWFs, which (as far as is possible), should permit conveyance of ISDN features through existing networks, is given in the I.500\(hySeries of Recommendations. .PP The I.500\(hySeries of Recommendations deal with network aspects of interworking. .RT .sp 2P .LP \fB2\fR \fBOrganization of ISDN interworking Recommendations\fR .sp 1P .RT .PP Figure\ 1/I.500 shows the organization of the ISDN interworking Recommendations contained in the I.500\(hySeries Recommendations, and the relationship with other Recommendations. The Recommendations in Figure\ 1/I.500 have been grouped by level of detail into: .RT .LP \(em general level; .LP \(em scenario level; .LP \(em functional level; .LP \(em protocol level. .sp 1P .LP 2.1 \fIGeneral level\fR .sp 9p .RT .PP Recommendations I.500 and I.510 form the general level, i.e., the basis for Recommendations in the scenario and functional levels. .PP Recommendation I.500 describes the organization of the (ISDN interworking) Recommendations and the structure of the I.500\(hySeries of Recommendations, whilst I.510 sets out the ISDN interworking principles. .RT .sp 1P .LP 2.2 \fIScenario level\fR .sp 9p .RT .PP The scenario level of Recommendations describes the general arrangements for interworking between ISDN and ISDN, and between ISDN and dedicated networks. Recommendation\ I.515 specifying the parameter exchange which may be necessary for interworking situations, is also located at the scenario level. .RT .sp 1P .LP 2.3 \fIFunctional level\fR .sp 9p .RT .PP The detailed level is formed by those Recommendations that are specifying the interworking functional requirements of the interworking scenarios shown in the scenario level Recommendations. .RT .sp 1P .LP 2.4 \fIProtocol level\fR .sp 9p .RT .PP In the protocol level, the protocols listed are those that appear at the reference points K\dx\uand\ N\dx\u. .PP \fINote\fR \ \(em\ ISDN interworking related subjects that correspond to the above four levels are also dealt with in the Recommendations\ I.310, I.324, I.340, X.300 and\ X.301. Recommendation\ I.310 defines the interworking reference points and an outline description of IWF. .bp .PP Recommendation I.340 defines ISDN Connection Types. .PP Recommendations\ X.300 and X.301 give the guiding principles and functions for interworking between networks offering data services described in Recommendations\ X.1 and\ X.10. .RT .PP 2.5 Recommendations which relate to interworking are shown in Figure\ 1/I.500 and are assigned to the levels listed in \(sc\ 2. As the contents of some Recommendations cover more than one level, these Recommendations appear at each level to which they relate. .sp 9p .RT .LP .rs .sp 30P .ad r \fBFigure 1/I.500, (N), p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP \fB3\fR \fBReferences\fR .sp 1P .RT .PP The references are general to all I.500 Recommendations and are to be read in conjunction with Figure\ 1/I.500, where the organization of ISDN interworking Recommendations is shown. .RT .sp 1P .LP 3.1 \fIInterworking\fR .sp 9p .RT .PP X.300\(hySeries Interworking between public networks, and between public networks and other networks for the provision of data transmission services .RT .LP I.324 ISDN architecture functional model .LP I.340 Connection types/elements for ISDN\(hyISDN interworking .LP X.31 Support of packet\(hymode terminal equipment by an ISDN .LP X.81 Interworking between an ISDN circuit switched and a circuit switched public data network (CSPDN) .bp .sp 1P .LP 3.2 \fIServices and network capabilities\fR .sp 9p .RT .PP X.1 International user classes of service in public data networks and integrated services digital networks (ISDNs) .RT .LP X.2 International data transmission services and optional user facilities in public data networks and ISDNs .LP X.10 Categories of access for data terminal equipment (DTE) to public data transmission services .LP I.122 Framework for providing additional packet\(hymode bearer services .LP I.200\(hySeries Service aspects supported by an ISDN .LP I.310 ISDN \(em Network functional principles .LP I.320 ISDN protocol reference model .LP I.325 Reference configurations for ISDN connection types .LP I.411 ISDN user\(hynetwork interfaces \(em reference configurations .LP I.412 ISDN user\(hynetwork interfaces \(em Interface structures and access capabilities .LP I.420 Basic rate user\(hynetwork interface .LP I.421 Primary rate user\(hynetwork interface .LP I.441 .LP (Q.921) \-v'10p' ISDN user\(hynetwork interface data link layer specification \v'10p' .LP I.451 .LP (Q.931) \-v'10p' ISDN user\(hynetwork interface layer\ 3 specification \v'10p' .sp 1P .LP 3.3 \fISignalling\fR .sp 9p .RT .PP Q.700 Network protocols (MTP, ISUP, etc.) .RT .LP Q.120\(hyQ.180 Specification of Signalling Systems No.\ 4 and No.\ 5 .LP Q.251\(hyQ.300 Specification of Signalling System No.\ 6 .LP Q.310\(hyQ.490 Specification of Signalling Systems R1 and R2 .LP X.25 Interface between data terminal equipment (DTE) and data circuit equipment (DCE) for terminals operating in the packet\(hymode and connected to public data networks by dedicated circuits .LP X.71 Decentralized terminal and transit control signalling system on international circuits between synchronous data networks .LP X.75 Packet switched signalling system between public networks providing data transmission services .LP U.12 Terminal and transit control signalling system for telex and similar services on international circuits (type\ D signalling) .sp 1P .LP 3.4 \fIRate adaptation\fR .sp 9p .RT .PP I.460 Multiplexing, rate adaptation and support of existing interfaces .RT .LP I.461 .LP (X.30) \-v'10p' Support of X.21, X.21 | fIbis\fR | and X.20 | fIbis\fR | based DTEs by an ISDN \v'10p' .LP I.462 .LP (X.31) \-v'10p' Support of packet\(hymode terminal equipment by an ISDN \v'10p' .LP I.463 .LP (V.110) \-v'10p' Support of DTEs with V\(hySeries type interfaces by an ISDN \v'10p' .LP I.464 Multiplexing, rate adaptation and support of existing interfaces for restricted 64\ kbit/s transfer capability .LP I.465 .LP (V.120) \-v'10p' Support by ISDN of DTEs with V\(hySeries type interfaces with provision for statistical multiplexing .bp .sp 1P .LP 3.5 \fINumbering\fR .sp 9p .RT .PP X.121 International numbering plan for public data networks .RT .LP X.122 Numbering plan interworking between a Packet Switched Public Data Network (PSPDN) and an Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN) in the short\(hyterm .LP I.331 .LP (E.164) \-v'10p' Numbering plan for the ISDN era \v'10p' .LP E.166 Numbering plan interworking in the ISDN era .LP I.330 ISDN numbering and addressing principles .LP I.332 Numbering principles for interworking between ISDNs and dedicated networks with different numbering plans .LP F.69 Plan for telex destination codes .sp 2P .LP \fBRecommendation\ I.510\fR .RT .sp 2P .sp 1P .ce 1000 \fBDEFINITIONS\ AND\ GENERAL\ PRINCIPLES\ FOR\ ISDN\ INTERWORKING\fR .EF '% Fascicle\ III.9\ \(em\ Rec.\ I.510'' .OF '''Fascicle\ III.9\ \(em\ Rec.\ I.510 %' .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP \fB1\fR \fBIntroduction\fR .sp 1P .RT .PP This Recommendation sets forth the general principles for interworking between ISDNs, between ISDNs and other networks, and internal to an ISDN. The need for interworking stems from the coexistence of existing dedicated networks with ISDNs and from the use of different, yet compatible, bearer services or teleservices for the provision of an end\(hyto\(hyend telecommunication service. When ISDNs are introduced, it is to be expected that most users will need to interwork with the users of other networks, especially public switched telephone networks (PSTNs), public land mobile networks (PLMNs) and dedicated data networks. .PP Normally, each instance of communication within an ISDN will take place between the users of services with identical attribute values. However, communication may also take place between users of services with non\(hyidentical attribute values. In these cases interworking functions (IWFs) will be required. In general, when an ISDN user communicates with the user of another network, if the service perceived by the user of that other network were to be defined by the attribute method, the values would not be identical to those of the ISDN user. .PP The purpose of interworking is to enable the users of \*Qdifferent\*U services on an ISDN to establish a useful communication or for an ISDN user to establish a useful communication with a user of another network and vice\(hyversa. The term \*Qservice\*U in this Recommendation implies a telecommunication service as defined in Recommendation\ I.210. .PP To permit interworking, interworking capabilities, making use of IWFs, may be required in one or more of the following: .RT .LP \(em the ISDN, .LP \(em any other network involved, .LP \(em customer equipment. .sp 2P .LP \fB2\fR \fBScope\fR .sp 1P .RT .PP This Recommendation contains the definitions and general principles to be applied in instances of ISDN interworking, which include interworking between ISDNs, between ISDNs and other networks, and internal to an\ ISDN. .bp .PP The ISDN interworking configurations to be considered within the scope of this Recommendation include the interconnection of two networks where at least one network is an ISDN, the concatenation of more than two networks where an ISDN interconnects other networks (as a transit network), or the interconnection of two ISDNs by one or more other networks. .PP ISDN interworking, as defined in this Recommendation, is considered to take place whenever end\(hyto\(hyend communication has to be provided: .RT .LP a) between different networks where at least one network is an ISDN, or .LP b) between telecommunication services with different lower or higher layer attributes or both, where at least one of the interworking telecommunication service is supported by the ISDN, or .LP c) between different networks and between telecommunication services with different lower or higher layer service attributes, or both. .PP ISDN interworking, as defined in this Recommendation, is intended to cover both voice and non\(hyvoice applications. .PP \fINote\fR \ \(em\ Interworking at layers above layer\ 3 of the OSI model is not generally specified within this Recommendation and is for further study. .RT .sp 2P .LP \fB3\fR \fBAbbreviations\fR .sp 1P .RT .PP CCSN Common channel signalling network (SS\ No.7) .RT .LP CE Connection element .LP CS Circuit switched .LP CSPDN Circuit switched public data network .LP DTE Data terminal equipment .LP ISDN Integrated Services Digital Network .LP IWF Interworking function .LP OSI Open Systems Interconnection .LP PDN Public data network .LP PH Packet handler .LP PLMN Public land mobile network .LP PS Packet switched .LP PSPDN Packet switched public data network .LP PSTN Public switched telephone network .LP SS\ No.7 Signalling System No.\ 7 .LP TA Terminal adaptor .LP TE Terminal equipment .sp 2P .LP \fB4\fR \fBDefinitions\fR .sp 1P .RT .sp 1P .LP 4.1 \fIDefinitions related to services and network capabilities\fR .sp 9p .RT .PP The definitions which follow are related to services and to network capabilities. In those instances where terms already are defined in other Recommendations, appropriate references are made to such Recommendations. .PP The following definitions apply to ISDN interworking: .PP \fITelecommunication service\fR , as defined in Recommendation I.210. .PP \fIBearer service in the ISDN\fR , as defined in Recommendation I.210 and in the I.230\(hySeries. .PP \fITeleservice\fR , as defined in Recommendation\ I.210 and in the I.240\(hySeries, provides the full capacity for communication through terminal and network lower and higher layer functions. .PP \fIBearer service in dedicated networks:\fR | The term \fIbearer service\fR | in dedicated networks is characterized by a set of lower layer attributes (e.g.\ data transmission services, as defined in Recommendation\ X.1, for use in public data networks) and corresponds to the term \fIbearer service\fR in an ISDN. Examples of \fIbearer services\fR in dedicated networks are data transmission over a data network and data transmission over the telephone network. .bp .PP \fISupplementary service\fR , as defined in Recommendation I.210 and in the I.250 Series. .PP \fIBearer capability\fR , as defined in Recommendation I.210, specifies the technical features of a \fIbearer service\fR in an ISDN as these appear to a user at the access point (S/T\ reference point). The term \fIbearer capability\fR also may be used with respect to dedicated networks. A \fIbearer capability\fR does not include any terminal functions. .RT .sp 1P .LP 4.2 \fIDefinitions related to general ISDN interworking configurations\fR .sp 9p .RT .PP This section provides concepts and definitions of terms relevant to the general ISDN interworking configuration. Figure\ 1/I.510 depicts the scope of application of several key terms. .RT .LP .rs .sp 25P .ad r \fBFigure 1/I.510, (N), p.\fR .sp 1P .RT .ad b .RT .PP In accordance with Figure 1/I.510, the following terms are defined: .sp 1P .LP \fBinterworking\fR .sp 9p .RT .PP Within the scope of the I.500\(hySeries of Recommendations, the term \fIinterworking\fR | is used to express interactions between networks, between end systems, or between parts thereof, with the aim of providing a functional entity capable of supporting an end\(hyto\(hyend communication. The interactions required to provide a functional entity rely on functions and on the means to select these functions. .RT .sp 1P .LP \fBinterworking functions (IWFs)\fR .sp 9p .RT .PP The functions referred to in the Interworking definition above, which include the conversion of physical and electrical states and the mapping of protocols. An IWF may be implemented in the ISDN, in the other network(s), at the user's premises, through a third\(hyparty service provider, or in some combination of these. .bp .PP The IWFs needed as a result of a service requirement for interworking are categorized as connection\(hydependent IWFs or communication\(hydependent IWFs . The relationships among these terms and definitions for connection\(hydependent IWFs and for communication\(hydependent IWFs are contained in Figure\ 2/I.510. .RT .LP .rs .sp 25P .ad r \fBFigure 2/I.510, (N), p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP \fB5\fR \fBTelecommunication services to be supported by ISDN\fR \fBinterworking configurations\fR .sp 1P .RT .PP This section contains a list of telecommunication services that are supported by interconnections between ISDNs and between ISDNs and other networks and defines the types of interworking functions required. The concept of \(sc\ 5 take into account: .RT .LP a) the definitions as outlined in \(sc\ 4; .LP b) existing networks to be interconnected with ISDN (ISDNs, PSTNs, CSPDNs, PSPDNs, others); .LP c) services to be offered with the ISDN and through interworking with ISDN. .PP End\(hyto\(hyend communication may require: .LP i) interworking at lower layers; .LP ii) interworking at higher layers; .LP iii) interworking at both lower and higher layers. .PP Table 1/I.510 displays the networks that support telecommunication services which are also supported by an ISDN and which are candidates, therefore, for interworking with an ISDN in the provision of one of those telecommunication services. Furthermore, Table\ 1/I.510 depicts the type of interworking functions that may be required for each interworking configuration. Note that the table does not indicate the possibility for interworking between different telecommunication services (e.g.\ telex\(hyto\(hyTeletex). .bp .ce \fBH.T. [T1.510]\fR .ce TABLE\ 1/I.510 .ce \fBNetwork support of telecommunication services\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(90p) | cw(18p) sw(18p) sw(18p) sw(18p) sw(18p) sw(48p) , ^ | c | c | c | c | c | c. { Telecommunication services supported by the ISDN } ISDN interconnected with ISDN PSTN CSPDN PSPDN Telex Other dedicated networks _ .T& lw(90p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) . Telephony 0 N \(em \(em \(em N _ .T& lw(90p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) . { Data transmission (see Note 2) } (L) N, | N, | L) N, | L) \(em N, | L) _ .T& lw(90p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) . Telex 0 \(em \(em \(em N, | N, | _ .T& lw(90p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) . Teletex 0 N, | N, | N, | \(em N, | , | _ .T& lw(90p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) . Fascimile 0 N, | N, | N, | \(em N, | .TE .LP 0 No interworking functions foreseen .LP N Connection\(hydependent interworking needed .LP L Lower layer communication\(hydependent interworking needed .LP H Higher layer communication\(hydependent interworking needed .LP (\ ) N/L/H may be needed .LP \fINote\ 1\fR \ \(em\ The list of services in Table 1/I.510 is not exhaustive and is therefore for further study. In particular, bearer services must be included. .LP \fINote\ 2\fR \ \(em\ See Recommendation X.1 for a description of data transmission services. .LP \fINote\ 3\fR \ \(em\ It is assumed for Table 1/I.510 that, for the cases of ISDN\(hyto\(hyISDN interworking, the telecommunication services listed above are supported in both ISDNs by the same bearer, no interworking functions are therefore required. ISDN\(hyto\(hyISDN interworking situations that involve different bearers, as an extension of Table\ 1/I.510, are for further study. .nr PS 9 .RT .ad r \fBTableau 1/I.510 [T1.510], p.\fR .sp 1P .RT .ad b .RT .LP .sp 1 .sp 2P .LP \fB6\fR \fBISDN interworking configurations\fR .sp 1P .RT .PP This section contains the general interworking reference configurations that form the basis of all possible ISDN interworking configurations covered by the I.500\(hySeries of Recommendations. .PP The configurations are entirely functional and do not serve any aspect of the interworking function(s) needed in any specific instance of interworking. The complexities of specific cases are considered in the Recommendations that deal at a scenario level of detail with the individual types of networks with which an ISDN may be interconnected, i.e.\ Recommendations\ I.520, I.530,\ etc. .PP The network interworking reference point is the K\dx\uor \dx\ureference point when the network directly interconnected to the ISDN is a non\(hyISDN or an ISDN, respectively. .RT .sp 1P .LP 6.1 \fIReference points for network interconnections\fR .sp 9p .RT .PP The protocol reference model for ISDN interworking is outlined in \(sc\ 5 of Recommendation\ I.320. .PP The reference points K\dx\uand N\dx\ufor network interconnections are defined in Recommendation\ I.324, \(sc\ 4.2.4. .bp .PP According to Note 1 to Figure\ 8/I.324 the value x\ =\ 1 signifies that interworking functions exist in the ISDN. The value x\ =\ 2 signifies that no interworking functions are required in the ISDN. No assumption is made regarding interworking functions outside the ISDN. Regardless of the value of x, the possibility of interworking functions in the other networks, between the networks, or of some combination of these situations, is kept open. The case of N\d1\ucovers the situation when interworking functions are split between the two ISDNs involved. .RT .sp 1P .LP 6.1.1 \fIInterworking using one\(hystage selection (one\(hystage\fR \fIinterworking)\fR .sp 9p .RT .PP Interworking using one\(hystage selection is possible when the interconnection of networks takes place by interconnecting trunk lines. It is also possible when the networks are physically inseparable [for example, see b) of Figure\ 6/I.510, and associated text]. In this type of interworking, each of the terminals involved in a communication has assigned to it a directory number from the numbering plan of the network to which it is connected. For call establishment, one\(hystage selection is assumed. An example of this type of interworking is the interconnection of a CSPDN using X.71 interexchange signalling and an ISDN using SS\ No.\ 7 interexchange signalling. .PP For interworking by one\(hystage selection, the interconnection of networks takes place at reference points K\dx\uor \dx\u(see Figure\ 3/I.510). .PP The application of existing interfaces and the specification of new interfaces at the K\dx\uand N\dx\ureference points for interworking by one\(hystage selection needs further study. .PP \fINote\fR \ \(em\ In Recommendation X.300 this category of interworking is defined as \*Qinterworking by call control mapping\*U (see \(sc\ 6.2.1 of Recommendation\ X.300). .RT .LP .rs .sp 9P .ad r \fBFigure 3/I.510, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 6.1.2 \fIInterworking using two\(hystage selection\fR \fI(two\(hystage\fR \fIinterworking)\fR .sp 9p .RT .PP Interworking using two\(hystage selection is sometimes required, e.g.\ access to a PSPDN through an ISDN according to case\ A of Recommendation\ X.31. In this example, each of the terminals involved in a communication has assigned to it a directory number from the numbering plan of the PSPDN. For call establishment, two\(hystage selection is assumed: first, a connection is established through the ISDN to the appropriate PSPDN port; second, a connection is established through the PSPDN to the called terminal. .PP The logical appearance of interworking by two\(hystage selection at reference point\ K\d2\u(see Note\ 1) may be that of a customer access (see Figure\ 4/I.510). .PP The application of existing interfaces and the specification of new interfaces at the K\d2\u\ reference point for interworking by two\(hystage selection is for further study. .PP \fINote\ 1\fR \ \(em\ Since, in the case of interworking using two\(hystage selection depicted in Figure\ 4/I.510, no IWFs are required in the ISDN, only reference point\ K\d2\uis relevant. .PP \fINote\ 2\fR \ \(em\ In Recommendation X.300, examples of this category of interworking are defined as \*Qinterworking by port access\*U (see \(sc\ 6.2.2 of Recommendation\ X.300). .bp .RT .LP .rs .sp 9P .ad r \fBFigure 4/I.510, (N), p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 6.2 \fIISDN\(hyto\(hyISDN interconnection\fR .sp 1P .RT .sp 1P .LP 6.2.1 \fIReference configuration\fR .sp 9p .RT .PP With regard to ISDN\(hyto\(hyISDN interworking in the context of the I.500\(hySeries of Recommendations, the functionality required for bearer service interworking is contained in ISDN\(hyto\(hyISDN internetwork interfaces. .PP Figure\ 5/I.510 shows a reference configuration for ISDN\(hyto\(hyISDN interworking. The services offered at the endpoints may be different. .PP ISDN\(hyto\(hyISDN interworking may involve the functionality required for interworking to take place between ISDNs operated by, for instance, different Administrations. .RT .LP .rs .sp 14P .ad r \fBFigure 5/I.510, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 6.2.2 \fIConnection types\fR .sp 9p .RT .PP Applicable Recommendation: I.520. .RT .LP a) ISDN circuit mode | (hy | SDN circuit mode (both ISDNs supporting a circuit\(hyswitched bearer service); .LP b) ISDN packet mode | (hy | SDN packet mode (both ISDNs supporting the ISDN virtual circuit bearer service defined in Recommendation\ X.31 under case\ b); .LP c) ISDN packet mode | (hy | SDN circuit mode (interworking where a packet switched bearer is requested by one ISDN and a circuit switched bearer by the other ISDN); .LP d) ISDN packet mode | (hy | SDN circuit mode (interworking, where a circuit switched bearer is requested in one ISDN to obtain access to the packet handler of another ISDN for communication over an ISDN virtual circuit bearer service). .bp .sp 2P .LP 6.3 \fIInterworking between ISDNs and other networks\fR .sp 1P .RT .sp 1P .LP 6.3.1 \fIReference configurations\fR .sp 9p .RT .PP Network interworking is required whenever an ISDN and a non\(hyISDN are interconnected to provide an end\(hyto\(hyend connection. .PP Network interworking functions typically would contain the functionality needed for conversion of physical and electrical interface characteristics and for mapping of layer\ 2 and layer\ 3 network protocols. Examples of such network interworking functions are: signalling conversions, information transfer, protocol conversions, analogue\(hyto\(hydigital (and \fIvice\fR \fIversa\fR ) conversions, and interworking between different numbering and charging plans. .PP Two reference configurations for network interworking are shown in Figure\ 6/I.510. The services offered at the endpoints may be different. .PP The separation between an ISDN and a non\(hyISDN may not always be obvious. A local exchange may, for example, support both traditional telephony service and ISDN services. The physical network components supporting these services may be inseparable. From a functional perspective, such a case might be covered by a) of Figure\ 6/I.510, while b) of Figure\ 6/I.510 might be more appropriate from an implementation point of view. .RT .LP .rs .sp 16P .ad r \fBFigure 6/I.510, (N), p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 6.3.2 \fIConnection types\fR .sp 1P .RT .sp 1P .LP 6.3.2.1 \fIISDN\(hyPSTN\fR .sp 9p .RT .PP Applicable Recommendation: I.530. .RT .LP a) ISDN circuit mode\(hyPSTN .LP \(em speech .LP \(em 3.1 kHz .LP \(em 64 kbit/s unrestricted .LP b) ISDN packet mode, X.31 case b)\(hyPSTN. .sp 1P .LP 6.3.2.2 \fIISDN\(hyCSPDN\fR .sp 9p .RT .PP Applicable Recommendation: I.540. .RT .LP a) ISDN circuit mode\(hyCSPDN; .LP b) ISDN packet mode, X.31 case b)\(hyCSPDN .bp .sp 1P .LP 6.3.2.3 \fIISDN\(hyPSPDN\fR .sp 9p .RT .PP Applicable Recommendation: I.550. .RT .LP a) ISDN circuit mode\(hyPSPDN; .LP b) ISDN circuit mode, to provide interworking port access to a PSPDN, X.31, case\ a); .LP c) ISDN packet mode, X.31 case b)\(hyPSPDN. .sp 1P .LP 6.3.2.4 \fIISDN\(hyTelex\fR .sp 9p .RT .PP Applicable Recommendation: I.560. .RT .LP a) ISDN circuit mode\(hyTelex .LP b) ISDN packet mode\(hyTelex .sp 1P .LP 6.3.2.5 \fIISDN\(hyPrivate networks\fR .sp 9p .RT .PP Interworking between ISDNs and private networks may occur at reference points S/T; other reference points, if required, need to be specified. .RT .sp 1P .LP 6.4 \fIISDN internal interworking\fR .sp 9p .RT .PP Internal ISDN interworking involves the capabilities required for interworking between different connection elements within an ISDN, as well as the capabilities required to support other interworking requirements within an ISDN. .PP A reference configuration is given in Figure\ 7/I.510. The services offered at the endpoints may be different. .PP Not all aspects of internal ISDN interworking may be subject to standardization. The existence and functionality of such interworking, however, may have an impact on the required functionality of network interworking or ISDN\(hyto\(hyISDN interworking. .RT .LP .rs .sp 15P .ad r \fBFigure 7/I.510, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 6.5 \fINetwork concatenation configurations\fR .sp 9p .RT .PP \fINote\ 1\fR \ \(em\ The impact of network concatenation configurations (i.e.\ cascaded networks) on ISDN and existing networks and on the mechanisms and functionalities for the realization of these networks is for further study. .PP \fINote\ 2\fR \ \(em\ In the case of cascaded (concatenated) networks, other than ISDN networks, a requirement may exist for interworking functions between pairs of such networks. .bp .RT .sp 1P .LP 6.5.1 \fIReference configurations\fR .sp 9p .RT .PP See Figure 8/I.510. .RT .LP .rs .sp 18P .ad r \fBFigure 8/I.510, (N), p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 6.5.2 \fIConnection types\fR .sp 1P .RT .sp 1P .LP 6.5.2.1 \fIISDN\(hyPSTN\(hyISDN\fR .sp 9p .RT .PP Applicable alternatives at reference points K\dx\uare described in \(sc\ 6.3.2.1 and in Recommendation\ I.520. .RT .sp 1P .LP 6.5.2.2 \fIISDN\(hyPSPDN\(hyISDN\fR .sp 9p .RT .PP Applicable alternatives at reference points K\dx\uare described in \(sc\ 6.3.2.3 and in Recommendation\ I.520. .RT .sp 1P .LP 6.5.2.3 \fIISDN\(hyCSPDN\(hyISDN\fR .sp 9p .RT .PP Applicable alternatives at reference points K\dx\uare described in \(sc\ 6.3.2.2 and in Recommendation\ I.520. .RT .sp 1P .LP 6.5.2.4 \fIISDN\(hyPSPDN\(hyPSTN\fR .sp 9p .RT .PP Applicable alternatives at reference points K\dx\uare described in \(sc\ 6.3.2.3. .RT .sp 1P .LP 6.5.2.5 \fIISDN\(hyPSPDN\(hyCSPDN\fR .sp 9p .RT .PP Applicable alternatives at reference points K\dx\uare described in \(sc\ 6.3.2.3. .RT .sp 1P .LP 6.5.2.6 \fIISDN\(hyPSPDN\(hyTelex\fR .sp 9p .RT .PP Applicable alternatives at reference points K\dx\uare described in \(sc\ 6.3.2.3. .RT .sp 1P .LP 6.5.2.7 \fIISDN\(hyCSPDN\(hyPSPDN\fR .sp 9p .RT .PP Applicable alternatives at reference points K\dx\uare described in \(sc\ 6.3.2.2. .bp .RT .sp 2P .LP \fB7\fR \fBInterworking functional requirements \(em General aspects\fR .sp 1P .RT .sp 1P .LP 7.1 \fICategories of interworking functions\fR .sp 9p .RT .PP The following network\(hyrelated characteristics and protocols depend on the network type (ISDN circuit\(hyswitched, ISDN packet\(hyswitched, PSTN, CSPDN, PSPDN,\ etc.) and may be identified at the point of network interworking for conversion or mapping: .RT .LP a) network characteristics related to the connection type, such as interface characteristics, switching mode, bit rate, transfer mode,\ etc., and non\(hyprotocol conversion\(hyrelated characteristics such as numbering plan and special routing; .LP b) network\(hyto\(hynetwork protocols used for call establishment interexchange signalling, such as SS No.\ 7, X.71, X.75,\ etc. (e.g.\ SS No.\ 7 ISUP to another User Part of SS No.\ 7, SS No.7 to non\(hyISDN signalling system, D\(hychannel signalling to non\(hyISDN user access signalling systems based on national standards); .LP c) protocols used for the support of those supplementary services and service signals which have network\(hyto\(hynetwork relevance, as in the case, for example, of the closed user group facility; .LP d) signals due to network operation and maintenance; .LP e) inband protocol conversion IWFs such as rate adaption, modem pools, and generation of inband tones and announcements. .PP The definition of the conversion or mapping functions is the subject of specific interworking Recommendations which address ISDN interworking at a functional level of detail (see Recommendation\ I.500). .PP Interworking functional must take into account the mapping of protocols (protocol elements) dedicated to the support of OSI network layer service characteristics. These requirements should be formulated with the recognition that the networks involved in ISDN interworking may support the OSI network layer service as defined in Recommendation\ X.213 in different ways and to different extents (see Recommendation\ X.300,\ \(sc\ 6). .RT .sp 1P .LP 7.2 \fIMapping principles\fR .sp 9p .RT .PP Interworking implies the transfer of information between two different entities across an interface. This transfer may imply the need to map different protocols with respect to coding, sequencing, and timing. Ideally, no information content should be lost in mapping. This objective may not be achievable in all circumstances. Three different cases are identified: .RT .LP a) one\(hyto\(hyone mapping, where the information is transferred across the interface without any loss; .LP b) mapping with degraded information transfer, where parts of information are lost when crossing the interface; .LP c) no meaningful mapping possible, due to the fact that crucial parts of one protocol cannot be represented in the other protocol. .PP In these cases, appropriate actions have to be taken at the interworking point with respect to one or both of the communicating entities. .sp 1P .LP 7.3 \fIGuidelines on the description of mapping functions\fR .sp 9p .RT .PP For further study. .RT .sp 1P .LP 7.4 \fIFunctional requirements for lower layer service interworking\fR .sp 9p .RT .PP (For example, mapping of layer\ 2 and layer\ 3 protocols by end systems in support of end\(hyto\(hyend communication). .PP For further study. .RT .sp 1P .LP 7.5 \fIFunctional requirements for higher layer service interworking\fR .sp 9p .RT .PP For further study. .bp .RT .sp 2P .LP \fB8\fR \fBGeneral aspects of \fR \fBselection mechanisms for interworking\fR \fBfunctions\fR .sp 1P .RT .PP ISDN interworking will involve sets of different functional elements dedicated to the various cases of network interworking. For each call where interworking is required, specific interworking functions have to be selected (see Figure\ 9/I.510). .RT .LP .rs .sp 22P .ad r \fBFigure 9/I.510, (N), p.\fR .sp 1P .RT .ad b .RT .PP When the IWF is not an addressed entity, the following concept for the selection of interworking functions is therefore defined: .LP a) Connection\(hydependent interworking functions are selected by evaluation of user\(hynetwork and network\(hynetwork signalling information. Relevant information includes: .LP \(em bearer capability, .LP \(em low layer compatibility, .LP \(em service indication, .LP \(em routing information (address information, transit network information), .LP \(em information on supplementary services (facilities), if applicable; .LP b) Network\(hyprovided communication\(hydependent interworking functions are selected by evaluation of user\(hynetwork and network\(hynetwork signalling information. Relevant information includes: .LP \(em service indication, .LP \(em lower and higher layer compatibility information, .LP \(em information on supplementary services (facilities), if applicable; .LP c) End\(hysystem\(hyprovided communication\(hydependent interworking functions, if available, are activated by one of the following approaches: .LP \(em by evaluation of user\(hynetwork signalling information during the call establishment phase (service indication and lower/higher compatibility information), .LP \(em by evaluation of user\(hyto\(hyuser compatibility information during the parameter exchange phase. .PP \fINote\fR \ \(em\ Examination of these information elements requires further study. .bp .sp 2P .LP \fBRecommendation\ I.511\fR .RT .sp 2P .sp 1P .ce 1000 \fBISDN\(hyTO\(hyISDN\ LAYER\ 1\ INTERNETWORK\ INTERFACE\fR .EF '% Fascicle\ III.9\ \(em\ Rec.\ I.511'' .OF '''Fascicle\ III.9\ \(em\ Rec.\ I.511 %' .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP \fB1\fR \fBGeneral\fR .sp 1P .RT .PP The objective of this Recommendation is to define the layer 1 aspects of the ISDN interworking, including reference configuration and interworking functions. .PP \fINote\fR \ \(em\ For the international interworking between networks based on different digital hierarchies and speech encoding laws, see Recommendation\ G.802. .RT .sp 2P .LP \fB2\fR \fBReference configuration\fR .sp 1P .RT .PP General reference configuration and logically defined reference points for ISDN interworking with other networks or other\ ISDNs are given in Figure\ 4/I.310, where\ K, M and\ N are defined as logical reference points for interworking. However, from the viewpoint of physical interworking, the digital sections and digital links defined in Rec.\ G.701 are shared among the logically different networks of the same network provider. Therefore, the commonly designated reference point for layer\ 1 interworking should be established so that it can be used as the common layer\ 1 specification for the logically different reference points\ K, M and\ N. .RT .sp 1P .LP 2.1 \fILayer 1 reference configuration\fR .sp 9p .RT .PP Figure 1/I.511 shows the layer 1 reference configuration and layer\ 1 reference point\ Q. .PP Figure 1/I.511 reflects the interworking between different network providers each of which has logically different networks or special facilities. The number of logically different networks which a network provider has is one or more; however, at least one network provider should contain an\ ISDN. .PP The internetwork termination\ (IT) is a functional grouping associated with the proper physical and electromagnetic termination of the network as well as section, link and/or circuit termination of the network. Note that specific functions of IT may be performed with one or more pieces of equipment. .PP Reference point Q should be one of the equipment interfaces listed in Recs.\ G.702 and\ G.707. The specification of\ Q can be used as the common description of the layer\ 1 specification for the different logical interfaces\ K, M and\ N. .PP The digital link of each network should be terminated at\ Q. .RT .sp 1P .LP 2.2 \fIPhysical realizations of reference configuration\fR .sp 9p .RT .PP Figure 2/I.511 gives examples of configurations made up of combinations of physical interfaces at reference point\ Q; Figure\ 2a/I.511 shows an interface without transmission section (line or radio); and Figures\ 2b/I.511 and\ 2c/I.511 show interfaces with transmission sections. .PP In every case, reference point\ Q should appear as the equipment interface. .PP The mandatory functions of IT described in \(sc\ 3 are the same in each application, while the optional functions may be different according to the following cases, if interworking: .RT .LP \(em with or without transmission sections, .LP \(em with or without master\(hyslave relation, such as master\(hyslave synchronization and remote maintenance between two network providers. .sp 2P .LP \fB3\fR \fBLayer 1 interworking functions\fR .sp 1P .RT .PP Layer\ 1 interworking functions at Q, which may be performed by the IT, should be classified into mandatory and optional functions. .bp .RT .LP .rs .sp 47P .ad r \fBFigure 1/I.511, (N), p. 11\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 47P .ad r \fBFigure 2/I.511, (N), p. 12\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 3.1 \fIMandatory functions\fR .sp 9p .RT .PP Every item related to mandatory functions should always be carried out in order be classified into mandatory and optional functions. .RT .sp 1P .LP 3.1.1 \fIProviding standardized equipment interfaces\fR .sp 9p .RT .PP Reference point Q should be applied to one of the equipment interfaces standardized in the G.700\(hyG.900\ Series Recommendations for digital networks, transmission systems and multiplexing equipment. .PP Items to be standardized are as follows: .RT .LP 1) \fIInterface bit rate\fR .LP Interface bit rate at Q should be selected from among the hierarchical bit rates defined in Recs.\ G.702 and\ G.707. .LP It should be noted that the interworking hierarchy be applied to the international interworking as defined in Rec.\ G.802 when interconnection based on an asynchronous hierarchy is adopted. .LP 2) \fIPhysical/electrical characteristics\fR .LP Physical/electrical characteristics at Q should conform to the relevant part of G.700\(hyG.900\ Series Recommendations. .LP 3) \fIFunctional characteristics\fR .LP Functional characteristics at Q should conform to the relevant part of G.700\(hyG.900\ Series Recommendations. .LP 4) \fITime slot assignment\fR .LP There are two methods for assigning time slots in the frame structure to various channels: the fixed format method and the variable format method. A set of examples of both methods is described in Figure\ 3/I.511. .LP \fIFixed format\fR \ \(em\ Time slots for interworking information channels are pre\(hyassigned in a fixed manner in the interworking frame structure by bilateral negotiation. .LP \fIVariable format\fR \ \(em\ A flexible time slot is allocated to any information channel on a demand assignment basis. .LP 5) \fITime slot sequence integrity\fR .LP Time slot sequence integrity should be performed. Furthermore, it is preferable to perform time slot sequence integrity with 8\ kHz integrity. .LP \fI\fR .rs .sp 20P .ad r \fBFigure 3/I.511, (N), p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 3.1.2 \fIProviding layer 1 maintenance capability\fR .sp 9p .RT .PP Reference point Q should meet the maintenance requirements defined in the relevant part of the M\(hySeries and N\(hySeries Recommendations. .PP Items to be standardized are as follows: .RT .LP 1) \fITermination of the digital link\fR .LP Termination of the digital link should conform to the relevant part of the M\(hySeries Recommendations. .LP 2) \fITermination of the digital circuit\fR .LP Termination of the digital circuit should conform to the relevant part of the M\(hySeries Recommendations and is deferred for further study. .sp 1P .LP 3.2 \fIOptional functions\fR .sp 9p .RT .PP Not all of the items of the optional functions can be achieved at reference point\ Q. Only some of them are selected according to the features of each connection type or differences in the relationship between network providers. .RT .sp 1P .LP 3.2.1 \fIProviding interworking between different connection types\fR \fIin layer\ 1\fR .sp 9p .RT .PP In some applications, connection types which are different in layer\ 1 items can be successfully interconnected over reference point\ Q by using the optional capabilities listed below. .PP Items to be standardized are as follows: .RT .LP 1) \fICoding rule conversion\fR .LP i) \(*m\(hyA law coding rule conversion should be performed according to Rec.\ G.802 in the case of speech and 3.1\ kHz audio services; .LP ii) Unrestricted 64\ kbit/s digital service shall not be subject to network provided conversion. .LP 2) \fIInterconnection among connection types with different\fR \fIlayer\ 1 attributes\fR .LP Rate adaption should be performed according to Recs.\ I.460, I.461, I.462, I.463 and\ I.464. .sp 1P .LP 3.2.2 \fIProviding network synchronization clock\fR .sp 9p .RT .PP If network synchronization is performed over reference point Q by other methods than the plesiochronous method, the clock should meet the requirement defined in Rec.\ G.812. .RT .sp 2P .LP \fBRecommendation\ I.515\fR .RT .sp 2P .sp 1P .ce 1000 \fBPARAMETER\ EXCHANGE\ FOR\ ISDN\ INTERWORKING\fR .EF '% Fascicle\ III.9\ \(em\ Rec.\ I.515'' .OF '''Fascicle\ III.9\ \(em\ Rec.\ I.515 %' .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP \fB1\fR \fBGeneral\fR .sp 1P .RT .sp 1P .LP 1.1 \fIScope\fR .sp 9p .RT .PP The objective of this Recommendation is to provide overall parameter exchange principles and functional descriptions for ISDN interworking. This Recommendation describes the principles for parameter exchange mechanisms. It is recognized that depending on the available (end\(hyto\(hyend) signalling capability, the exchange of parameters may use either out\(hy or in\(hyband procedures. .PP 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 compatibility 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. .bp .PP 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. .PP \fINote\fR \ \(em\ Where interworking procedures exist, the appropriate references are made herein. .RT .LP .rs .sp 47P .ad r \fBFigure 1/I.515, (N), p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 1.2 \fIDefinitions and abbreviations\fR .sp 9p .RT .PP 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 Recommendation. .RT .LP \(em \fBbearer capability information\fR .LP Specific information defining the lower layer characteristics of the network. .LP \(em \fBlow layer compatibility information\fR .LP Information defining the lower layer characteristics of a TE or TA. .LP \(em \fBhigh layer compatibility information\fR .LP Information defining the higher layer characteristics of a terminal. .LP \(em \fBprotocol identifier\fR .LP Information defining the specific protocols used by a terminal to support data transfer. .LP \(em \fBprogress indicator\fR .LP Information supplied to indicate to the ISDN terminal that interworking has occurred. .LP \(em \fBout\(hyband parameter exchange\fR .LP Information exchanged via signalling channels which are not within the channel used for user information transfer. .LP \(em \fBin\(hyband parameter exchange\fR .LP Information exchanged using the same information channel as that used for the user information transfer. .sp 2P .LP \fB2\fR \fBPrinciples\fR .sp 1P .RT .sp 1P .LP 2.1 \fITypes of parameter exchanges\fR .sp 9p .RT .PP Three types of parameter exchange need to be considered: .RT .LP i) end\(hyto\(hyend, out\(hyband as shown in Figure\ 2/I.515. Parameter exchange is accomplished via the D\(hychannel and Signalling Systems\ No.\ 7; .LP ii) end\(hyto\(hyend, in\(hyband as shown in Figure\ 3/I.515. .LP iii) Parameter exchange to select IWFs as shown in Figure\ 4/I.515. .PP The in\(hyband parameter exchange occurs after the establishment of an end\(hyto\(hyend connection and may provide for establishment of compatibility between the endpoints, based on characteristics such as protocol, rate adaption scheme and modem type. .sp 1P .LP 2.2 \fIRelationship of\fR \fIparameter exchange\fR \fIto\fR \fIcall\fR \fIestablishment\fR .sp 9p .RT .PP Parameter exchange may occur: .RT .LP i) prior to call establishment (call negotiation). In this case parameter exchange will occur using out\(hyband techniques; .LP ii) after call establishment, prior to information transfer. In this case parameter exchange may occur using either in\(hyband or out\(hyband techniques; .LP iii) during the information transfer phase of the call. In this case parameter exchange will occur using either in\(hyband or out\(hyband techniques. .sp 1P .LP 2.2.1 \fIParameter exchange prior to call establishment (call\fR \fInegotiation)\fR .sp 9p .RT .PP 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 networks) for: .RT .LP a) terminal section (see Recs.\ I.333, Q.931, Q.932); .LP b) selection of interworking requirements when interworking between ISDN and other dedicated networks is identified (e.g. modem type); .LP c) the appropriate selection of network (ISDN or other network) functions to support the service required (e.g. use of call progress indicator); .LP d) the selection of network functions when interworking between incompatible terminals is identified or when interworking of different services is required. .PP Each of the requirements a) through d) above are necessary during the call establishment phase. Therefore, call or service negotiation mechanisms should be included within basic call establishment procedures. Further study is required. .bp .LP .rs .sp 9P .ad r \fBFigure 2/I.515, (N), p. 15\fR .sp 1P .RT .ad b .RT .LP .rs .sp 21P .ad r \fBFigure 3/I.515, (N), p. 16\fR .sp 1P .RT .ad b .RT .LP .rs .sp 9P .ad r \fBFigure 4/I.515, (N), p. 17\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 2.2.1.1 \fICall negotiation types\fR .sp 9p .RT .PP Three types of call negotiation are currently envisaged: .RT .LP \(em user to network, .LP \(em network to user, .LP \(em user to user. .PP The relationship between user\(hyto\(hyuser call negotiation and network\(hyto\(hyuser call negotiation required further study. .PP Call negotiation in each of the above cases may involve the forwarding of parameters to the destination, may involve forwarding of parameters on request, or may involve forward and backward negotiation to establish compatible terminal and network parameters. .RT .sp 1P .LP 2.2.1.2 \fIInformation elements available for call negotiation\fR .sp 9p .RT .PP Three information elements are currently associated with call negotiation (see note): .RT .LP \(em bearer capability (BC); .LP \(em low layer compatibility (LLC); .LP \(em high layer compatibility (HLC). .PP The relationship of these information elements to parameter exchange functions is for further study. .PP \fINote\fR \ \(em\ BC, LLC, HLC are information elements defined in Recommendation\ Q.931. .RT .sp 1P .LP 2.2.1.3 \fITransfer of information\fR .sp 9p .RT .PP The transfer of information associated with call negotiation is illustrated in figure\ 5/I.515. .RT .LP .rs .sp 30P .ad r \fBFigure 5/I.515, (N), p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 2.2.2 \fIParameter exchange after call establishment and prior to\fR \fIinformation transfer phase\fR .sp 9p .RT .PP This parameter exchange may be necessary when signalling to allow adequate compatibility checking during the call set\(hyup phase is not available, or when additional capability checking is required due to characteristics of the terminals which are not defined in call establishment procedures. .PP When out\(hyband parameter exchange is used refer to \(sc\ 3.1.2. .PP When in\(hyband paramaeter exchange is used refer to \(sc\ 3.2.1. .RT .sp 1P .LP 2.2.3 \fIParameter exchange during information transfer phase\fR .sp 9p .RT .PP This parameter exchange may be necessary when configurations change during the information transfer phase (e.g. maintenance, sub\(hychannel information). Detailed aspects are for further study. .RT .LP \fB3\fR \fBParameter exchange procedures\fR .sp 1P .RT .sp 2P .LP 3.1 \fIOut\(hyband parameter exchange\fR .sp 1P .RT .sp 1P .LP 3.1.1 \fIPrior to call establishment\fR .sp 9p .RT .PP Refer to Recs.\ Q.931 and Q.\ 764. Other protocols are for further study. .RT .sp 1P .LP 3.1.2 \fIAfter call establishment and prior to information transfer phase\fR .sp 9p .RT .PP Refer to Recs.\ Q.931 and\ Q.764. .RT .sp 1P .LP 3.1.3 \fIDuring information transfer phase\fR .sp 9p .RT .PP Refer to Recs.\ Q.931 and\ Q.764. .RT .sp 2P .LP 3.2 \fIIn\(hyband parameter exchange\fR .sp 1P .RT .sp 1P .LP 3.2.1 \fIAfter call establishment and prior to information transfer\fR .sp 9p .RT .PP The following parameter exchange sequence identifies one method of establishment compatibility during interworking between an ISDN and existing networks and between ISDNs: .RT .LP \(em call establishment phase (e.g. refer to Recs.\ Q.931 and\ Q.764); .LP \(em originating terminal changes from idle condition to busy condition; .LP \(em connection enters paramters exchange phase; .LP \(em connection enters information transfer phase. .sp 1P .LP 3.2.1.1 \fIVoice services\fR .sp 9p .RT .PP Refers to Recommendation G.725. .RT .sp 1P .LP 3.2.1.2 \fIParameter exchange mechanism for terminal adaption protocol\fR \fIidentification\fR .sp 9p .RT .PP Some In\(hyband Parameter Exchange (IPE) procedures are in existence, e.g.\ Appendix\ I of Recommendation\ V.110. Two circuit mode terminal adaption procedures are emerging within CCITT (i.e.\ I.463/V.110 and I.465/V.120). In many countries, the Terminal Adaptor\ (TA) desing 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\(hyISDN network, terminal adaption implementations which support multiple terminal 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. .bp .PP It should be noted that it is good practice to design data terminals, for circuit\(hymode applications, which can automatically answer or originate calls, automatically establish compatibility if possible and, if necessary, to disconnect when connected to an incompatible terminal. .PP Though it is recognized that out\(hyband procedures are preferable where applicable (i.e., intra\(hyISDN situations), for interworking with dedicated networks, in\(hyband parameter exchange procedures may be required. .PP Alternative methods exist for distinguishing between terminal adapttion protocols. One satisfactory method is the use of self identification by examining the incoming bit stream. The method would be sed on the need to provide, in any TA or TE1, the ability to determine when it is connected to an incompatible TE1 or TA/TE2 or, through an IWF, with an incompatible terminal or another network. Appendix\ II describes one such procedure. .PP An alternative satisfactory method is to use protocol identification (PID) procedure. Appendix\ I presents an in\(hyband parameter exchange procedure for establishing a common terminal adaption\ (TA) protocol between communicating\ TA devices. .RT .sp 1P .LP 3.2.2 \fIDuring the information transfer phase\fR .sp 9p .RT .PP For further study. .RT .sp 2P .LP \fB4\fR \fBParameter exchange functions\fR .sp 1P .RT .PP Parameters exchanged to support interworking may be divided into the following three categories. These parameters may be exchanged end\(hyto\(hyend or between an endpoint and an IWF. The list of parameters presented here are examples; for any given instances of communication, different parameters may be required. .RT .sp 1P .LP 4.1 \fINumbering parameters\fR .sp 9p .RT .LP \(em subscriber number; .LP \(em sub\(hyaddress; .LP \(em terminal selection (see Recommendation\ I.333). .sp 1P .LP 4.2 \fIProtocol control parameters\fR .sp 9p .RT .PP 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. .RT .sp 1P .LP 4.3 \fIDTE/DCE configuration parameters\fR .sp 9p .RT .PP DTE/DCE configuration parameters are used to identify specific transmission or communication capabilities of the called DTE. The following is a list of such configuration parameters: .RT .LP \(em modem type (e.g., V\(hySeries number) .LP \(em data rate (e.g., 9.6 kbit/s, 56 kbit/s) .LP \(em synchronization (e.g., synchronous or asynchronous) .LP \(em parity (odd, even or no parity) .LP \(em transmission mode (e.g., half or full duplex) .LP \(em number of start/stop bits (e.g., 1\ or\ 2) .LP \(em terminal clock source (e.g., network provided, network independent) .LP \(em terminal interface signals (e.g., 106, 108) .LP \(em sub\(hychannel information. .sp 1P .LP 4.4 \fIOperations and maintenance parameters\fR .sp 9p .RT .PP Operations and maintenance parameters are used to convey/monitor the status of the DTE/DCE at the terminating points. Status monitored may include: .RT .LP \(em terminal power (ON or OFF) .LP \(em terminal presence (connected or disconnected) .LP \(em terminal interface signals status (e.g., 106, 108) .LP \(em terminal clock source (e.g., network provided, network independent) .LP \(em loopback status (e.g., ON or OFF) .bp .sp 2P .LP \fB5\fR \fBParameter exchange for selection of IWF\fR .sp 1P .RT .PP When an IWF is involved in a connection, parameters can be exchanged to establish compatibility. .PP There are a variety of techniques that can be used to provide compatibility of functions in an interworking environment. These can be categorized into two types. A single stage approach in which the network automatically inserts the IWF, and a two\(hystage approach in which the user must provide additional information to complete the interworking connection. .PP \fINote\fR \ \(em\ For examples of interworking configurations, refer to the appropriate I.500\(hySeries Recommendations. Appendix\ III details examples of parameter exchange for the selection of IWFs in the case of ISDN\(hyPSTN interworking for data. .RT .sp 1P .LP 5.1 \fISingle stage\fR .sp 9p .RT .PP In a single stage approach, the interworking function is handled automatically by the network. In order to ensure compatibility of the parameters the following techniques may be used: .RT .LP i) parameter registration ( service profile )\ \(em\ the DTE/DCE parameters are registered with the ISDN; .LP ii) parameter negotiation\ \(em\ parameter negotiation may be possible between networks and end\(hyusers or between networks or between users to determine parameter compatibility where suitable signalling exists. The signalling capabilities and parameters required may vary and are for further study. For example, see Appendix\ I of\ V.110; .LP iii) default parameter identification\ \(em\ the network provides an interworking function with common parameters. Any DCE must conform to the IWF common parameters; .LP iv) parameter adaption \ \(em\ the interworking function recognizes and adapts to the end\(hyuser's parameters. For example, for ISDN\(hyPSTN the interworking function may adapt to the modulation standard of the modem (see Appendix\ III). .sp 1P .LP 5.2 \fITwo stages\fR .sp 9p .RT .PP In the two\(hystage approach, during the first stage the user accesses the IWF and establishes the required parameters. In the second stage of the call the IWF uses the parameters to complete the end\(hyto\(hyend connection. .RT .sp 2P .LP \fB6\fR \fBReference\fR .sp 1P .RT .PP See Recommendation\ I.500. .RT .ce 1000 APPENDIX\ I .ce 0 .ce 1000 (to Recommendation I.515) .sp 9p .RT .ce 0 .ce 1000 \fBProtocol for identification of terminal adaption protocols\fR .sp 1P .RT .ce 0 .PP I.1 As shown in Figure I\(hy1/I.515 the total in\(hyband parameter exchange consists of two distinct phases. These are: .sp 1P .RT .LP a) Phase\ 1\ \(em the protocol identification (PID) phase, which occurs at the bearer rate (64\ kbit/s); .LP b) Phase\ 2\ \(em the in\(hyband parameter exchange (IPE) which is part of the rate adaption (RA) protocol used during the call. .PP Both these phases are optional and may or may not be implemented depending on the particular situation. .LP 1) Phase\ 1\ \(em PID: after call establishment PID phase begins. .LP 2) Phase\ 2\ \(em IPE: the IPE is imbedded within the TA protocol. It is the responsibility of the RA protocol designers to create an IPE that is applicable to the services and requirements of a particular TA protocol. An example is Appendix\ I to Rec.\ V.110 in which a complete IPE is specified for\ V.110. .LP \(em The IPE allows parameters to be exchanged between TA devices to ensure end\(hyto\(hyend compatibility before entering the data (information) phase. .LP \(em In the case of a successful IPE the protocol enters the data (information) phase. .LP \(em In the case of unresolvable differences between the TA devices, the IPE will provide a call progress message that can be used to take further action or clear the call. .bp .LP .rs .sp 40P .ad r \fBFigure I\(hy1/I.515, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP I.2 \fIIdentification procedure\fR .sp 9p .RT .PP All TA devices that follow this procedure shall start with the simple protocol identification technique described here before entering the TA protocol phase. The method is designed especially for digital networks. .PP The protocol identification is performed during the following three steps after the call is placed by using the normal call establishment procedures: .RT .LP 1) end\(hyto\(hyend synchronization; .LP 2) passing the Protocol Identifier (PI); .LP 3) making a decision regarding the type of TA to use for the call. .bp .PP For the case of a device with a PID and one without a PID which interwork, a timer value (\fIN\fR\d\fIp\fR\\d\fIi\fR\\d\fId\fR\u) should be set in the PID for defaulting to the preferred terminal adaption protocol. \fIN\fR\d\fIp\fR\\d\fIi\fR\\d\fId\fR\umust be long enough to allow for initial line settling and short enough to prevent the PID from causing the terminal adaption protocol to time out and clear its call. The value of timer \fIN\fR\d\fIp\fR\\d\fIi\fR\\d\fId\fR\ushould be set to allow for long delay connections (e.g. satellites). .PP Refer to Figure\ I\(hy2/I.515 for the timer sequence diagram of a successful protocol identification procedure. The sequence and acronyms in Figure\ I\(hy2/I.515 are described in \(sc\(sc\ I.3 to\ I.5. .RT .LP .rs .sp 45P .ad r \fBFigure I\(hy2/I.515, (N), p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP I.3 \fIEnd\(hyto\(hyend synchronization\fR .sp 9p .RT .PP After the physical call has been established, the originating end sends continuous ready bytes (5Fhex) waiting to detect the answering end. The answering end sends continuous sync bytes (57hex). (See Figure\ I\(hy3/I.515). .PP When the originating end sees at least 32 contiguous sync bytes (57hex) it is in sync and starts sending continuous sync bytes (57hex). .PP When the answering end sees 32 contiguous sync bytes it is in sync. .PP The receivers at each end wait for at least 32 contiguous occurrences (4\ ms) of the sync byte to be received without corruption before initiating the protocol. The sequence can then proceed to the next step. .PP The synchronization method described in this section allows for: .RT .LP 1) settling of the physical circuit; .LP 2) notice in the network; .LP 3) positive identification of the fact that TA devices are present at both ends; .LP 4) transmission on restricted 64 kbit/s links and through networks that use bit\ 8 for signalling; and .LP 5) simple implementation. .ce \fBH.T. [T1.515]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(36p) | cw(18p) sw(18p) sw(18p) sw(18p) sw(18p) sw(18p) sw(18p) sw(18p) sw(36p) , ^ | c | c | c | c | c | c | c | c | l. Initialization bytes B1 B2 B3 B4 B5 B6 B7 B8 _ .T& lw(36p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(36p) . Originating end 0 1 0 1 1 1 1 1 (5F in hexadecimal) _ .T& lw(36p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(36p) . Answering end 0 1 0 1 0 1 1 1 { (57 in hexadecimal) } .TE .LP \fINote\ 1\fR \ \(em\ B1 is transmitted and received first. .LP \fINote\ 2\fR \ \(em\ B8 is set to 1 for transmission and ignored on reception. .LP FIGURE\ I\(hy3/I.515 .nr PS 9 .RT .ad r \fBFigure I\(hy3/I.515 (comme tableau) [T1.515], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP I.4 \fIPassing the protocol identifier\fR \fI(PI)\fR .sp 9p .RT .PP This is the critical information that is to be passed and therefore a special technique is used to provide robustness in the face of noise, and yet maintain simplicity. .PP The PI is split into two bytes and three identical pairs are sent (refer to Figure\ I\(hy4/I.515). .RT .PP The PI passing technique described in this section: .LP 1) provides positive identification of the protocol bytes (low and high byte codes); .LP 2) provides redundant pairs of byte codes which allows for a technique to determine the protocol identification in the presence of noise (i.e. repeated three times); .LP 3) allows all eight bits of the PI to be used even on networks that use bit\ 8 for signalling; and .LP 4) allows for operation on restricted 64\ kbit/s networks and networks that use bit\ 8 for signalling (i.e. guarantees one's density, bit\ 8 set to\ 1). .sp 1P .LP I.5 \fITA decision\fR .sp 9p .RT .PP After the answering end has received 32 contiguous sync\(hybytes (\(sc\ I.3), it then sends its PI. The protocols supported by the answering end are coded in the PI byte (see Figure\ I\(hy5/I.515) and transmitted to the originating end. The originating end will check the PI and decide which (if any) TA protocol it wishes to support. .bp .RT .LP .rs .sp 19P .ad r \fBFigure I\(hy4/I.515, (N), p. 22\fR .sp 1P .RT .ad b .RT .ce \fBH.T. [T2.515]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) . P7 P6 P5 P4 P3 P2 P1 P0 _ .T& cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) . V.110 V.120 X.30 X.31 res. res. res. res. | ua\d\u)\d .TE .LP Example:\ 11000000 supports V.110 and V.120 protocols. .LP \fINote\fR \ \(em\ Bits marked \*Qres.\*U are set to 0, pending future allocation. .LP \ua\d\u)\d\ Use of P0 as an extension bit is for further study. .LP FIGURE\ I\(hy5/I.515 \fBPI interpretation\fR .nr PS 9 .RT .ad r \fBFigure I\(hy5/I.515 (comme tableau) [T2.515], p. 23\fR .sp 1P .RT .ad b .RT .PP After the answering end has sent its PI, it sends a distinct \*Qidle byte\*U (see Figure\ I\(hy6/I.515) continuous and waits for the matching PI from the originating end. .ce \fBH.T. [T3.515]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | lw(48p) . B1 B2 B3 B4 B5 B6 B7 B8 _ .T& cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) . 0 1 1 1 1 1 1 1 (7F in hexadecimal) .TE .LP \fINote\ 1\fR \ \(em\ B1 is transmitted and received first. .LP \fINote\ 2\fR \ \(em\ B8 is set to 1 for transmission and ignored on reception. .LP FIGURE I\(hy6/I.515 \fBIdle byte\fR .nr PS 9 .RT .ad r \fBFigure I\(hy6/I.515 (comme tableau) [T3.515], p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP The originating end then sends back its PI with only the bit that corresponds to the desired TA protocol set to\ 1. .PP If the originating end cannot support any of the answering end's TA protocols, it sends back a null PI byte (Figure\ I\(hy7/I.515), and then terminates the call using normal call disconnection procedures. .RT .ce \fBH.T. [T4.515]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | lw(48p) . P0 P1 P2 P3 P4 P5 P6 P7 _ .T& cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(48p) . 0 0 0 0 0 0 0 0 { (00 in hexadecimal) FIGURE\ I\(hy7/I.515 \fBNull PI byte\fR } _ .TE .nr PS 9 .RT .ad r \fBFigure I\(hy7/I.515 (comme tableau) [T4.515], p.\fR .sp 1P .RT .ad b .RT .PP The method described in this section: .LP a) supports various CCITT recognized forms of TA schemes; .LP b) allows for future TA schemes; .LP c) limits the proliferation of TA schemes; .LP d) allows the originating end to control the selection of the common TA protocol; and .LP e) provides a positive indication of a failed call. .ce 1000 APPENDIX\ II .ce 0 .ce 1000 (to Recommendation I.515) .sp 9p .RT .ce 0 .ce 1000 \fBTA protocol self identification\fR .sp 1P .RT .ce 0 .PP This appendix discusses guidelines for self\(hyidentification procedures that may be used by multi\(hyprotocol terminal adaptor (MTA) implementations in selecting the protocol to be used on an individual connection. It is assumed that the multi\(hyprotocol terminal adaptor supports the procedures of Recs.\ I.463 (V.110) and I.465\ (V.120). Where out\(hyband signalling is available, multi\(hyprotocol terminal adaptors should function in accordance with the protocol negotiated during call set\(hyup. Self\(hyidentification procedures are only applicable where such signalling capabilities are not available. .sp 1P .RT .sp 1P .LP II.1 \fIMTAs intended to interwork with uni\(hyprotocol TAs\fR .sp 9p .RT .PP The MTA may initiate transmission as if it were a uni\(hyprotocol TA conforming to any of the capabilities provided. 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\(hyprotocol TA as indicated by the received signals. If compatibility is not achieved it would provide a disconnect. .PP It is noted that there is a range of capabilities that may be implemented in TAs conforming to either Rec.\ I.463 (V.110) or Rec.\ I.465 (V.120). For distinguishing the capabilities of the different TA protocols, an MTA should follow the procedures specified in the individual Recommendations. .RT .sp 1P .LP II.2 \fIMTAs intended to interwork with other MTAs\fR .sp 9p .RT .PP The MTA should initiate transmission, following the connect indication, in accordance with Rec.\ I.465\ (V.120). .PP \fINote\fR \ \(em\ Self identification can be extended to accommodate multiple protocols. It is only necessry 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 suported 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\ \(em\ see, for example, Recs.\ I.463 (V.110) and I.465\ (V.120)]. .bp .RT .ce 1000 APPENDIX\ III .ce 0 .ce 1000 (to Recommendation I.515) .sp 9p .RT .ce 0 .ce 1000 \fBParameter exchange for selection of IWFs\fR .sp 1P .RT .ce 0 .ce 1000 \fBin the case of ISDN\(hyPSTN data interworking\fR .ce 0 .LP III.1 \fIMechanisms for modem selection\ \(em\ General options\fR .sp 1P .RT .PP The IWF would have to cooperate with the user to establish the appropriate modem selection. The interworking function may also be required to convert the signalling format, and negotiate the required data signalling rate (modem rate). .PP There are two general categories of modem selection techniques: .RT .LP a) mechanisms which do not require the ISDN user to have prior\fR knowledge of the modem characteristics of the PSTN user; .LP b) mechanisms which may require the ISDN user to have prior\fR knowledge of the modem characteristics of the PSTN user. .PP \fINote\fR \ \(em\ The preferred methods for modem selection for ISDN\(hyPSTN calls are for further study. .sp 2P .LP III.1.1 \fIMechanisms which do not require the ISDN user to have prior\fR \fIknowledge of the modem characteristics of the PSTN user\fR .sp 1P .RT .sp 1P .LP III.1.1.1 \fIUse of a multi\(hystandard modem at the IWF\fR .sp 9p .RT .PP The modem in the IWF recognizes and adapts to the end\(hyuser modulation standard. The number of, and choices of, modulation standards that would be supported in the IWF is for further study and would normally be a service provider option. For examples of possible implementation see Recs.\ V.100 and\ V.32. .RT .sp 1P .LP III.1.1.2 \fINegotiation\fR .sp 9p .RT .PP Negotiation between end\(hyuser and network or between networks or between users to determine compatible modem characteristics may be possible where suitable signalling methods exist. The signalling capabilities and parameters required are for further study, and would normally be a service provider option. .RT .sp 1P .LP III.1.1.3 \fIRegistration\fR .sp 9p .RT .PP The DTE/DCE characteristics of the PSTN user are registered with the ISDN. .RT .sp 2P .LP III.1.2 \fIMechanisms which may require the ISDN user to have prior\fR \fIknowledge of modem characteristics of the PSTN user\fR .sp 1P .RT .sp 1P .LP III.1.2.1 \fIDefault identification\fR .sp 9p .RT .PP Any DTE uses the same default modem characteristics. .RT .sp 1P .LP III.1.2.2 \fISelection by ISDN user of the modem dynamically\fR .sp 9p .RT .PP Using available parameter exchange mechanisms (i.e. SN, LLC/BC, IPE) the user selects specific TA/modem characteristics at the\ IWF. .RT .sp 2P .LP III.2 \fIISDN bearer capabilities for interworking\fR .sp 1P .RT .sp 1P .LP III.2.1 \fI3.1 kHz ISDN bearer capability\fR .sp 9p .RT .PP See Figure III\(hy1/I.515. .PP In the scenario the following cases are considered: .RT .LP \(em terminal is connected to ISDN access via a modem and uses a 3.1\ kHz audio bearer through TA; .LP \(em terminal selection in ISDN is made by means of multiple subscribers numbers. .bp .PP The PSTN user uses only the number corresponding to the appropriate terminal in ISDN for a call to that terminal. ISDN user does the same for calls to other terminals in ISDN or PSTN. .LP .rs .sp 8P .ad r \fBFigure III\(hy1/I.515, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP III.2.2 \fI64 kbit/s ISDN bearer capability\fR .sp 9p .RT .PP The following modem selection procedures apply to ISDN\(hyPSTN interworking (see Figure\ III\(hy2/I.515) since the ISDN and PSTN will share network transmission and switching facilities. These modem selection procedures assume that the modem interworking point will be the originating (for ISDN to PSTN calls) or terminating (for PSTN to ISDN calls) ISDN exchange, i.e. modem pools are available at each ISDN exchange. .PP The modems in the modem pool at each ISDN exchange can be grouped by their speeds; suitable codes and/or full Subscriber Numbers (SNs) can be assigned to each group of modems. .RT .LP .rs .sp 12P .ad r \fBFigure III\(hy2/I.515, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP III.3 \fIOptions for modem selection\fR .sp 9p .RT .PP The modem selection procedures outlined in this section are provided as potential options, which Administrations may choose, with modifications as required, to suit their own operating environment and applications. .RT .sp 2P .LP III.3.1 \fIISDN\(hyPSTN calls (bidirectional)\fR .sp 1P .RT .sp 1P .LP III.3.1.1 \fIOption 1 (example of the method detailed in \(sc\ III.1.1.1)\fR .sp 9p .RT .PP This is a single stage modem selection procedure which relies upon the following system requirements: .RT .LP \(em data terminals on the ISDN have separate SNs; .LP \(em the ISDN exchange can distinguish whether any incoming call is from the PSTN and can distinguish that an outgoing call is destined for the PSTN. .bp .PP For a voice\(hyband data call originated by a PSTN terminal, and intended for a data terminal on the ISDN, the terminating ISDN exchange will intercept the call and direct the call to an IWF. At the IWF, a modem will be inserted into the path, and the modem will recognize and adapt to the modulation standard used by the PSTN user. The IWF may pass parameters (e.g.\ LLC) to the called user when establishing the ISDN portion of the call. .PP For a data call originated in the ISDN intended for a data terminal on the PSTN, the ISDN exchange will intercept the call and direct the call to the IWF. The IWF will use the requested service (BC/LLC) on the ISDN portion of the call. At the IWF, a modem will be inserted into the path, and the modem will recognize and adapt to the modulation standard used by the PSTN user. .RT .sp 1P .LP III.3.1.2 \fIOption 2 (example of the method detailed in III.1.1.3)\fR .sp 9p .RT .PP This is a single stage modem selection procedure which relies on the following system requirements: .RT .LP \(em circuit data terminals on ISDN loops have separate SNs; .LP \(em a call progress indicator that PSTN to ISDN, or ISDN to PSTN interworking has occurred; and .LP \(em service profiles of destination terminals are available at the ISDN exchange (data \fIvs\fR speech terminals, pre\(hysubscribed modem type). .sp 1P .LP III.3.1.2.1 \fIPSTN\(hyto\(hyISDN call\fR .sp 9p .RT .PP The terminating ISDN exchange recognizes that: .RT .LP \(em the call is from the PSTN (from the call progress indicator); .LP \(em the call is for a data terminal (from service profile); and .LP \(em the modem type subscribed to (from service profile). .PP The terminating exchange will insert the pre\(hysubscribed modem type from the pool. .sp 1P .LP III.3.1.2.2 \fIISDN\(hyto\(hyPSTN call\fR .sp 9p .RT .PP The ISDN terminal will initiate the callas a 64\ kbit/s, rate adapted digital data call for all calls to both ISDN and PSTN destinations. On the receipt of the progress indicator (ISDN/PSTN interworking), the local exchange will insert the pre\(hysubscribed modem type in the path. .PP If the calling ISDN terminal knows \fIa priori\fR | that the called terminal in on a PSTN analogue loop, it may indicate in the \fIset\(hyup\fR message the pre\(hysubscribed modem type to be inserted. .RT .sp 2P .LP III.3.2 \fIISDN\(hyto\(hyPSTN calls\fR .sp 1P .RT .sp 1P .LP III.3.2.1 \fIOption 3 (example of the method detailed in III.1.2.2)\fR .sp 9p .RT .PP For a data call originated by a data terminal on the ISDN, the modem selection is done by using some appropriate information elements in the Q.931 \fIset\(hyup\fR message. Modem selection by the calling party is dependent upon the calling party's prior knowledge of the modulation standard used by the called party on the PSTN or upon the user of a multi\(hystandard modem at the IWF. The appropriate modem is inserted in the end\(hyto\(hyend path. .RT .sp 2P .LP III.3.3 \fIPSTN\(hyto\(hyISDN calls\fR .sp 1P .RT .sp 1P .LP III.3.3.1 \fIOption 4 (example of the method detailed in III.1.2.2 using\fR \fIsubscriber number.)\fR .sp 9p .RT .PP This is a two\(hystage method in which the modem pools at each exchange are grouped according to modulation standard and/or speed and each group is assigned a full subscriber number\ (SN). The first stage selects an appropriate modem and the second stage completes the connection to the desired terminal through the selected modem. Separate SNs for the data terminals on the ISDN digital loop are not needed because it is the responsibility of the PSTN subscriber to request a modem from the pool when he needs a data connection; the IWF will generate the appropriate bearer capability. However, the PSTN terminal equipment should have the capability to input a second set of digits, i.e.\ the called number (e.g. using V.25 | fIbis\fR protocol). .bp .PP Therefore for a PSTN\(hyto\(hyISDN data call, the PSTN user first dials the address of the appropriate group of modems at the terminating exchange. Once this connection is established the PSTN user dials the address of the called ISDN subscriber. This set of digits is used by the signalling conversion functionality (part of the IWF at the terminating exchange) to set\ up the connection from the modem to the called ISDN terminal. The exchange of call progress tones for this case needs further study. .RT .sp 1P .LP III.3.3.2 \fIOption 5 (example of the method detailed in III.1.1.2)\fR .sp 9p .RT .PP This is a single\(hystage modem selection procedure which relies upon the following system requirements: .RT .LP \(em circuit data terminals on ISDN loops have separate SNs; .LP \(em PSTN terminals have suitable signalling capabilities to indicate the modem speed/type in response to a request from the terminating exchange; .LP \(em the ISDN exchange can distinguish whether an incoming call is from the PSTN or the ISDN (using call progress indicator); and .LP \(em the ISDN exchange maintains a data base on service profiles of terminals served by the exchange (analog\ \fIvs\fR digital, and speech\ \fIvs\fR data in case of digital subscribers). .PP The user must be aware of any special operational requirements. .PP For a voice\(hyband data call originated by a PSTN terminal, and intended for a digital data terminal on the ISDN, the terminating ISDN exchange will recognize that: .RT .LP \(em the call is coming from the PSTN; and .LP \(em the call is intended for a digital data terminal on the ISDN. .PP The terminating ISDN exchange will intercept the call and send a suitable tone/signal back to the originating PSTN subscriber. Using some suitable signalling capability, the PSTN subscriber will indicate the code for modem selection, which will be used by the terminating exchange to attach a suitable modem and complete the path to the digital data terminal. .LP .rs .sp 27P .sp 2P .LP \fBMONTAGE: RECOMMANDATION I.520 SUR LE RESTE DE CETTE PAGE\fR .sp 1P .RT .LP .bp