5i' PART V I.500-Series Recommendations INTERNETWORK INTERFACES Blanc MONTAGE: PAGE 2 = PAGE BLANCHE Recommendation I.500 GENERAL STRUCTURE OF THE ISDN INTERWORKING RECOMMENDATIONS (Melbourne, 1988) 1 Introduction An ISDN is a network, in general evolving from a telephony Integrated Digital Network, that provides end-to-end digital con- nectivity to support a wide range of services, including voice and non-voice services, to which users have access by a limited set of standard multi-purpose user network interfaces. In contrast, exist- ing 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 communi- cation between terminals belonging to equivalent services offered through different networks. 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 per- mit, 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 net- works, is given in the I.500-Series of Recommendations. The I.500-Series of Recommendations deal with network aspects of interworking. 2 Organization of ISDN interworking Recommendations Figure 1/I.500 shows the organization of the ISDN interworking Recommendations contained in the I.500-Series Recommendations, and the relationship with other Recommendations. The Recommendations in Figure 1/I.500 have been grouped by level of detail into: - general level; - scenario level; - functional level; - protocol level. 2.1 General level Recommendations I.500 and I.510 form the general level, i.e., the basis for Recommendations in the scenario and functional lev- els. Recommendation I.500 describes the organization of the (ISDN interworking) Recommendations and the structure of the I.500-Series of Recommendations, whilst I.510 sets out the ISDN interworking principles. 2.2 Scenario level 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 situa- tions, is also located at the scenario level. 2.3 Functional level The detailed level is formed by those Recommendations that are specifying the interworking functional requirements of the inter- working scenarios shown in the scenario level Recommendations. 2.4 Protocol level In the protocol level, the protocols listed are those that appear at the reference points Kxand Nx. Note - 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. Recommendation I.340 defines ISDN Connection Types. Recommendations X.300 and X.301 give the guiding principles and functions for interworking between networks offering data ser- vices described in Recommendations X.1 and X.10. 2.5 Recommendations which relate to interworking are shown in Figure 1/I.500 and are assigned to the levels listed in S 2. As the contents of some Recommendations cover more than one level, these Recommendations appear at each level to which they relate. Figure 1/I.500, (N), p. 3 References The references are general to all I.500 Recommendations and are to be read in conjunction with Figure 1/I.500, where the organ- ization of ISDN interworking Recommendations is shown. 3.1 Interworking X.300-Series Interworking between public networks, and between public networks and other networks for the provision of data transmission services I.324 ISDN architecture functional model I.340 Connection types/elements for ISDN-ISDN interworking X.31 Support of packet-mode terminal equipment by an ISDN X.81 Interworking between an ISDN circuit switched and a circuit switched public data network (CSPDN) 3.2 Services and network capabilities X.1 International user classes of service in public data networks and integrated services digital networks (ISDNs) X.2 International data transmission services and optional user facilities in public data networks and ISDNs X.10 Categories of access for data terminal equip- ment (DTE) to public data transmission services I.122 Framework for providing additional packet-mode bearer services I.200-Series Service aspects supported by an ISDN I.310 ISDN - Network functional principles I.320 ISDN protocol reference model I.325 Reference configurations for ISDN connection types I.411 ISDN user-network interfaces - reference con- figurations I.412 ISDN user-network interfaces - Interface structures and access capabilities I.420 Basic rate user-network interface I.421 Primary rate user-network interface I.441 (Q.921) -v'10p' ISDN user-network interface data link layer specification I.451 (Q.931) -v'10p' ISDN user-network interface layer 3 specif- ication 3.3 Signalling Q.700 Network protocols (MTP, ISUP, etc.) Q.120-Q.180 Specification of Signalling Systems No. 4 and No. 5 Q.251-Q.300 Specification of Signalling System No. 6 Q.310-Q.490 Specification of Signalling Systems R1 and R2 X.25 Interface between data terminal equipment (DTE) and data circuit equipment (DCE) for terminals operating in the packet-mode and connected to public data networks by dedicated circuits X.71 Decentralized terminal and transit control signalling system on international circuits between synchronous data networks X.75 Packet switched signalling system between pub- lic networks providing data transmission services U.12 Terminal and transit control signalling system for telex and similar services on international circuits (type D signalling) 3.4 Rate adaptation I.460 Multiplexing, rate adaptation and support of existing interfaces I.461 (X.30) -v'10p' Support of X.21, X.21 | fIbis | and X.20 | fIbis | based DTEs by an ISDN I.462 (X.31) -v'10p' Support of packet-mode terminal equipment by an ISDN I.463 (V.110) -v'10p' Support of DTEs with V-Series type inter- faces by an ISDN I.464 Multiplexing, rate adaptation and support of existing interfaces for restricted 64 kbit/s transfer capability I.465 (V.120) -v'10p' Support by ISDN of DTEs with V-Series type interfaces with provision for statistical multiplexing 3.5 Numbering X.121 International numbering plan for public data networks 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-term I.331 (E.164) -v'10p' Numbering plan for the ISDN era E.166 Numbering plan interworking in the ISDN era I.330 ISDN numbering and addressing principles I.332 Numbering principles for interworking between ISDNs and dedicated networks with different numbering plans F.69 Plan for telex destination codes Recommendation I.510 DEFINITIONS AND GENERAL PRINCIPLES FOR ISDN INTERWORKING (Melbourne, 1988) 1 Introduction 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 coex- istence of existing dedicated networks with ISDNs and from the use of different, yet compatible, bearer services or teleservices for the provision of an end-to-end 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 pub- lic switched telephone networks (PSTNs), public land mobile net- works (PLMNs) and dedicated data networks. 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-identical attribute values. In these cases inter- working 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. The purpose of interworking is to enable the users of "dif- ferent" 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-versa. The term "service" in this Recom- mendation implies a telecommunication service as defined in Recommendation I.210. To permit interworking, interworking capabilities, making use of IWFs, may be required in one or more of the following: - the ISDN, - any other network involved, - customer equipment. 2 Scope This Recommendation contains the definitions and general prin- ciples to be applied in instances of ISDN interworking, which include interworking between ISDNs, between ISDNs and other net- works, and internal to an ISDN. 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 net- works (as a transit network), or the interconnection of two ISDNs by one or more other networks. ISDN interworking, as defined in this Recommendation, is con- sidered to take place whenever end-to-end communication has to be provided: a) between different networks where at least one network is an ISDN, or b) between telecommunication services with dif- ferent lower or higher layer attributes or both, where at least one of the interworking telecommunication service is supported by the ISDN, or c) between different networks and between telecom- munication services with different lower or higher layer service attributes, or both. ISDN interworking, as defined in this Recommendation, is intended to cover both voice and non-voice applications. Note - Interworking at layers above layer 3 of the OSI model is not generally specified within this Recommendation and is for further study. 3 Abbreviations CCSN Common channel signalling network (SS No.7) CE Connection element CS Circuit switched CSPDN Circuit switched public data network DTE Data terminal equipment ISDN Integrated Services Digital Network IWF Interworking function OSI Open Systems Interconnection PDN Public data network PH Packet handler PLMN Public land mobile network PS Packet switched PSPDN Packet switched public data network PSTN Public switched telephone network SS No.7 Signalling System No. 7 TA Terminal adaptor TE Terminal equipment 4 Definitions 4.1 Definitions related to services and network capabili- ties 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. The following definitions apply to ISDN interworking: Telecommunication service , as defined in Recommendation I.210. Bearer service in the ISDN , as defined in Recommendation I.210 and in the I.230-Series. Teleservice , as defined in Recommendation I.210 and in the I.240-Series, provides the full capacity for communication through terminal and network lower and higher layer functions. Bearer service in dedicated networks: | The term bearer ser- vice | 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 bearer service in an ISDN. Examples of bearer services in dedicated networks are data transmission over a data network and data transmission over the telephone network. Supplementary service , as defined in Recommendation I.210 and in the I.250 Series. Bearer capability , as defined in Recommendation I.210, speci- fies the technical features of a bearer service in an ISDN as these appear to a user at the access point (S/T reference point). The term bearer capability also may be used with respect to dedicated networks. A bearer capability does not include any terminal func- tions. 4.2 Definitions related to general ISDN interworking confi- gurations 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. Figure 1/I.510, (N), p. In accordance with Figure 1/I.510, the following terms are defined: interworking Within the scope of the I.500-Series of Recommendations, the term interworking | 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-to-end communica- tion. The interactions required to provide a functional entity rely on functions and on the means to select these functions. interworking functions (IWFs) 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-party service provider, or in some combination of these. The IWFs needed as a result of a service requirement for interworking are categorized as connection-dependent IWFs or communication-dependent IWFs terms and definitions for connection-dependent IWFs and for communication-dependent IWFs are contained in Figure 2/I.510. Figure 2/I.510, (N), p. 5 Telecommunication services to be supported by ISDN inter- working configurations 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 S 5 take into account: a) the definitions as outlined in S 4; b) existing networks to be interconnected with ISDN (ISDNs, PSTNs, CSPDNs, PSPDNs, others); c) services to be offered with the ISDN and through interworking with ISDN. End-to-end communication may require: i) interworking at lower layers; ii) interworking at higher layers; iii) interworking at both lower and higher layers. Table 1/I.510 displays the networks that support telecommuni- cation services which are also supported by an ISDN and which are candidates, therefore, for interworking with an ISDN in the provi- sion 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-to-Teletex). H.T. [T1.510] TABLE 1/I.510 Network support of telecommunication services __________________________________________________________________________________________________________________________ ISDN interconnected with { ISDN PSTN CSPDN PSPDN Telex Other dedicated networks __________________________________________________________________________________________________________________________ Telephony 0 N - - - N __________________________________________________________________________________________________________________________ { Data transmission (see Note 2) } (L) N, | N, | L) N, | L) - N, | L) __________________________________________________________________________________________________________________________ Telex 0 - - - N, | N, | __________________________________________________________________________________________________________________________ Teletex 0 N, | N, | N, | - N, | , | __________________________________________________________________________________________________________________________ Fascimile 0 N, | N, | N, | - N, | __________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 0 No interworking functions foreseen N Connection-dependent interworking needed L Lower layer communication-dependent interworking needed H Higher layer communication-dependent interworking needed ( ) N/L/H may be needed Note 1 - 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. Note 2 - See Recommendation X.1 for a description of data transmission services. Note 3 - It is assumed for Table 1/I.510 that, for the cases of ISDN-to-ISDN interworking, the telecommunication services listed above are supported in both ISDNs by the same bearer, no interwork- ing functions are therefore required. ISDN-to-ISDN interworking situations that involve different bearers, as an extension of Table 1/I.510, are for further study. Tableau 1/I.510 [T1.510], p. 6 ISDN interworking configurations This section contains the general interworking reference con- figurations that form the basis of all possible ISDN interworking configurations covered by the I.500-Series of Recommendations. 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. The network interworking reference point is the Kxor xreference point when the network directly interconnected to the ISDN is a non-ISDN or an ISDN, respectively. 6.1 Reference points for network interconnections The protocol reference model for ISDN interworking is outlined in S 5 of Recommendation I.320. The reference points Kxand Nxfor network interconnections are defined in Recommendation I.324, S 4.2.4. According to Note 1 to Figure 8/I.324 the value x = 1 signi- fies 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 N1covers the situation when interworking functions are split between the two ISDNs involved. 6.1.1 Interworking using one-stage selection (one-stage interworking) Interworking using one-stage 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-stage 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. For interworking by one-stage selection, the interconnection of networks takes place at reference points Kxor x(see Figure 3/I.510). The application of existing interfaces and the specification of new interfaces at the Kxand Nxreference points for interworking by one-stage selection needs further study. Note - In Recommendation X.300 this category of interworking is defined as "interworking by call control mapping" (see S 6.2.1 of Recommendation X.300). Figure 3/I.510, (N), p. 6.1.2 Interworking using two-stage selection (two-stage interworking) Interworking using two-stage 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-stage selection is assumed: first, a connection is established through the ISDN to the appropriate PSPDN port; second, a connec- tion is established through the PSPDN to the called terminal. The logical appearance of interworking by two-stage selection at reference point K2(see Note 1) may be that of a customer access (see Figure 4/I.510). The application of existing interfaces and the specification of new interfaces at the K2 reference point for interworking by two-stage selection is for further study. Note 1 - Since, in the case of interworking using two-stage selection depicted in Figure 4/I.510, no IWFs are required in the ISDN, only reference point K2is relevant. Note 2 - In Recommendation X.300, examples of this category of interworking are defined as "interworking by port access" (see S 6.2.2 of Recommendation X.300). Figure 4/I.510, (N), p. 6.2 ISDN-to-ISDN interconnection 6.2.1 Reference configuration With regard to ISDN-to-ISDN interworking in the context of the I.500-Series of Recommendations, the functionality required for bearer service interworking is contained in ISDN-to-ISDN internet- work interfaces. Figure 5/I.510 shows a reference configuration for ISDN-to-ISDN interworking. The services offered at the endpoints may be different. ISDN-to-ISDN interworking may involve the functionality required for interworking to take place between ISDNs operated by, for instance, different Administrations. Figure 5/I.510, (N), p. 6.2.2 Connection types Applicable Recommendation: I.520. a) ISDN circuit mode | (hy | SDN circuit mode (both ISDNs supporting a circuit-switched bearer service); 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); 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); 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). 6.3 Interworking between ISDNs and other networks 6.3.1 Reference configurations Network interworking is required whenever an ISDN and a non-ISDN are interconnected to provide an end-to-end connection. 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 conver- sions, analogue-to-digital (and vice versa ) conversions, and interworking between different numbering and charging plans. Two reference configurations for network interworking are shown in Figure 6/I.510. The services offered at the endpoints may be different. The separation between an ISDN and a non-ISDN may not always be obvious. A local exchange may, for example, support both tradi- tional 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 appropri- ate from an implementation point of view. Figure 6/I.510, (N), p. 6.3.2 Connection types 6.3.2.1 ISDN-PSTN Applicable Recommendation: I.530. a) ISDN circuit mode-PSTN - speech - 3.1 kHz - 64 kbit/s unrestricted b) ISDN packet mode, X.31 case b)-PSTN. 6.3.2.2 ISDN-CSPDN Applicable Recommendation: I.540. a) ISDN circuit mode-CSPDN; b) ISDN packet mode, X.31 case b)-CSPDN 6.3.2.3 ISDN-PSPDN Applicable Recommendation: I.550. a) ISDN circuit mode-PSPDN; b) ISDN circuit mode, to provide interworking port access to a PSPDN, X.31, case a); c) ISDN packet mode, X.31 case b)-PSPDN. 6.3.2.4 ISDN-Telex Applicable Recommendation: I.560. a) ISDN circuit mode-Telex b) ISDN packet mode-Telex 6.3.2.5 ISDN-Private networks Interworking between ISDNs and private networks may occur at reference points S/T; other reference points, if required, need to be specified. 6.4 ISDN internal interworking 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 inter- working requirements within an ISDN. A reference configuration is given in Figure 7/I.510. The ser- vices offered at the endpoints may be different. Not all aspects of internal ISDN interworking may be subject to standardization. The existence and functionality of such inter- working, however, may have an impact on the required functionality of network interworking or ISDN-to-ISDN interworking. Figure 7/I.510, (N), p. 6.5 Network concatenation configurations Note 1 - 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 net- works is for further study. Note 2 - In the case of cascaded (concatenated) networks, other than ISDN networks, a requirement may exist for interworking functions between pairs of such networks. 6.5.1 Reference configurations See Figure 8/I.510. Figure 8/I.510, (N), p. 6.5.2 Connection types 6.5.2.1 ISDN-PSTN-ISDN Applicable alternatives at reference points Kxare described in S 6.3.2.1 and in Recommendation I.520. 6.5.2.2 ISDN-PSPDN-ISDN Applicable alternatives at reference points Kxare described in S 6.3.2.3 and in Recommendation I.520. 6.5.2.3 ISDN-CSPDN-ISDN Applicable alternatives at reference points Kxare described in S 6.3.2.2 and in Recommendation I.520. 6.5.2.4 ISDN-PSPDN-PSTN Applicable alternatives at reference points Kxare described in S 6.3.2.3. 6.5.2.5 ISDN-PSPDN-CSPDN Applicable alternatives at reference points Kxare described in S 6.3.2.3. 6.5.2.6 ISDN-PSPDN-Telex Applicable alternatives at reference points Kxare described in S 6.3.2.3. 6.5.2.7 ISDN-CSPDN-PSPDN Applicable alternatives at reference points Kxare described in S 6.3.2.2. 7 Interworking functional requirements - General aspects 7.1 Categories of interworking functions The following network-related characteristics and protocols depend on the network type (ISDN circuit-switched, ISDN packet-switched, PSTN, CSPDN, PSPDN, etc.) and may be identified at the point of network interworking for conversion or mapping: a) network characteristics related to the connec- tion type, such as interface characteristics, switching mode, bit rate, transfer mode, etc., and non-protocol conversion-related characteristics such as numbering plan and special routing; b) network-to-network 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-ISDN signalling system, D-channel signalling to non-ISDN user access signalling systems based on national stan- dards); c) protocols used for the support of those supple- mentary services and service signals which have network-to-network relevance, as in the case, for example, of the closed user group facility; d) signals due to network operation and mainte- nance; e) inband protocol conversion IWFs such as rate adaption, modem pools, and generation of inband tones and announce- ments. 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). Interworking functional must take into account the mapping of protocols (protocol elements) dedicated to the support of OSI net- work 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, S 6). 7.2 Mapping principles 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: a) one-to-one mapping, where the information is transferred across the interface without any loss; b) mapping with degraded information transfer, where parts of information are lost when crossing the interface; c) no meaningful mapping possible, due to the fact that crucial parts of one protocol cannot be represented in the other protocol. In these cases, appropriate actions have to be taken at the interworking point with respect to one or both of the communicating entities. 7.3 Guidelines on the description of mapping functions For further study. 7.4 Functional requirements for lower layer service inter- working (For example, mapping of layer 2 and layer 3 protocols by end systems in support of end-to-end communication). For further study. 7.5 Functional requirements for higher layer service inter- working For further study. 8 General aspects of selection mechanisms for interworking functions 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). Figure 9/I.510, (N), p. When the IWF is not an addressed entity, the following concept for the selection of interworking functions is therefore defined: a) Connection-dependent interworking functions are selected by evaluation of user-network and network-network signal- ling information. Relevant information includes: - bearer capability, - low layer compatibility, - service indication, - routing information (address information, transit network information), - information on supplementary services (facili- ties), if applicable; b) Network-provided communication-dependent inter- working functions are selected by evaluation of user-network and network-network signalling information. Relevant information includes: - service indication, - lower and higher layer compatibility information, - information on supplementary services (facili- ties), if applicable; c) End-system-provided communication-dependent interworking functions, if available, are activated by one of the following approaches: - by evaluation of user-network signalling informa- tion during the call establishment phase (service indication and lower/higher compatibility information), - by evaluation of user-to-user compatibility information during the parameter exchange phase. Note - Examination of these information elements requires further study. Recommendation I.511 ISDN-TO-ISDN LAYER 1 INTERNETWORK INTERFACE (Melbourne, 1988) 1 General The objective of this Recommendation is to define the layer 1 aspects of the ISDN interworking, including reference configuration and interworking functions. Note - For the international interworking between networks based on different digital hierarchies and speech encoding laws, see Recommendation G.802. 2 Reference configuration General reference configuration and logically defined refer- ence 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 specif- ication for the logically different reference points K, M and N. 2.1 Layer 1 reference configuration Figure 1/I.511 shows the layer 1 reference configuration and layer 1 reference point Q. 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. 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 per- formed with one or more pieces of equipment. 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 dif- ferent logical interfaces K, M and N. The digital link of each network should be terminated at Q. 2.2 Physical realizations of reference configuration 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. In every case, reference point Q should appear as the equip- ment interface. The mandatory functions of IT described in S 3 are the same in each application, while the optional functions may be different according to the following cases, if interworking: - with or without transmission sections, - with or without master-slave relation, such as master-slave synchronization and remote maintenance between two network providers. 3 Layer 1 interworking functions Layer 1 interworking functions at Q, which may be performed by the IT, should be classified into mandatory and optional functions. Figure 1/I.511, (N), p. 11 Figure 2/I.511, (N), p. 12 3.1 Mandatory functions Every item related to mandatory functions should always be carried out in order be classified into mandatory and optional functions. 3.1.1 Providing standardized equipment interfaces Reference point Q should be applied to one of the equipment interfaces standardized in the G.700-G.900 Series Recommendations for digital networks, transmission systems and multiplexing equip- ment. Items to be standardized are as follows: 1) Interface bit rate Interface bit rate at Q should be selected from among the hierarchical bit rates defined in Recs. G.702 and G.707. 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. 2) Physical/electrical characteristics Physical/electrical characteristics at Q should conform to the relevant part of G.700-G.900 Series Recommendations. 3) Functional characteristics Functional characteristics at Q should conform to the relevant part of G.700-G.900 Series Recommendations. 4) Time slot assignment 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. Fixed format - Time slots for interworking information channels are pre-assigned in a fixed manner in the interworking frame structure by bilateral negotiation. Variable format - A flexible time slot is allocated to any information channel on a demand assignment basis. 5) Time slot sequence integrity Time slot sequence integrity should be performed. Further- more, it is preferable to perform time slot sequence integrity with 8 kHz integrity. .rs Figure 3/I.511, (N), p. 3.1.2 Providing layer 1 maintenance capability Reference point Q should meet the maintenance requirements defined in the relevant part of the M-Series and N-Series Recommen- dations. Items to be standardized are as follows: 1) Termination of the digital link Termination of the digital link should conform to the relevant part of the M-Series Recommendations. 2) Termination of the digital circuit Termination of the digital circuit should conform to the relevant part of the M-Series Recommendations and is deferred for further study. 3.2 Optional functions 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 rela- tionship between network providers. 3.2.1 Providing interworking between different connection types in layer 1 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. Items to be standardized are as follows: 1) Coding rule conversion i) u-A law coding rule conversion should be per- formed according to Rec. G.802 in the case of speech and 3.1 kHz audio services; ii) Unrestricted 64 kbit/s digital service shall not be subject to network provided conversion. 2) Interconnection among connection types with different layer 1 attributes Rate adaption should be performed according to Recs. I.460, I.461, I.462, I.463 and I.464. 3.2.2 Providing network synchronization clock 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. Recommendation I.515 PARAMETER EXCHANGE FOR ISDN INTERWORKING (Melbourne, 1988) 1 General 1.1 Scope 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-to-end) signalling capability, the exchange of parameters may use either out- or in-band procedures. Parameter exchange may be necessary to establish compatible interworking functions for a variety of applications. Typical exam- ples where parameter exchange takes place include, terminal adap- tion 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 inter- working. Figure 1/I.515 illustrates several voice and data applica- tions, supported by different networks and mechanisms. Parameter exchange may be necessary where interworking between different ter- minals or networks (as per other Recommendations) is required. Note - Where interworking procedures exist, the appropriate references are made herein. Figure 1/I.515, (N), p. 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 con- text of this Recommendation. - bearer capability information Specific information defining the lower layer characteris- tics 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 ter- minal 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 information transfer. - in-band parameter exchange Information exchanged using the same information channel as that used for the user information transfer. 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. Parameter exchange is accomplished via the D-channel and Signalling Systems No. 7; ii) end-to-end, in-band as shown in Figure 3/I.515. iii) Parameter exchange to select IWFs as shown in 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 endpoints, based on characteristics such as protocol, rate adaption scheme and modem type. 2.2 Relationship of parameter exchange to call establish- ment Parameter exchange may occur: i) prior to call establishment (call negotiation). In this case parameter exchange will occur using out-band tech- niques; 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 in-band or out-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 neces- sary for interworking as described in I.510 (between terminals, services and networks) for: a) terminal section (see Recs. I.333, Q.931, Q.932); b) selection of interworking requirements when interworking between ISDN and other dedicated networks is identi- fied (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 inter- working between incompatible terminals is identified or when inter- working of different services is required. 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 estab- lishment procedures. Further study is required. Figure 2/I.515, (N), p. 15 Figure 3/I.515, (N), p. 16 Figure 4/I.515, (N), p. 17 2.2.1.1 Call negotiation types Three types of call negotiation are currently envisaged: - user to network, - network to user, - user to user. The relationship between user-to-user call negotiation and network-to-user call negotiation required further study. 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 nego- tiation to establish compatible terminal and network parameters. 2.2.1.2 Information elements available for call negotiation Three information elements are currently associated with call negotiation (see note): - 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 5/I.515. Figure 5/I.515, (N), p. 2.2.2 Parameter exchange 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 set-up 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. When out-band parameter exchange is used refer to S 3.1.2. When in-band paramaeter exchange is used refer to S 3.2.1. 2.2.3 Parameter exchange 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 Recs. Q.931 and Q. 764. Other protocols are for further study. 3.1.2 After call establishment and prior to information transfer phase Refer to Recs. Q.931 and Q.764. 3.1.3 During information transfer phase Refer to Recs. Q.931 and Q.764. 3.2 In-band parameter exchange 3.2.1 After call establishment and prior to information transfer The following parameter exchange sequence identifies one method of establishment compatibility during interworking between an ISDN and existing networks and between ISDNs: - call establishment phase (e.g. refer to Recs. Q.931 and Q.764); - originating terminal changes from idle condition to busy condition; - connection enters paramters exchange phase; - connection enters information transfer phase. 3.2.1.1 Voice services Refers 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 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-ISDN 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 proto- col to be used by the multifunctional adaptor (MTA) devices. This will allow the terminal equipment (or appropriate network com- ponent), to release the call where compatibility cannot be achieved, or to request the network to provide an appropriate interworking function. It should be noted that it is good practice to design data terminals, for circuit-mode applications, which can automatically answer or originate calls, automatically establish compatibility if possible and, if necessary, to disconnect when connected to an incompatible terminal. Though it is recognized that out-band procedures are prefer- able where applicable (i.e., intra-ISDN situations), for interwork- ing with dedicated networks, in-band parameter exchange procedures may be required. 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 net- work. Appendix II describes one such procedure. An alternative satisfactory method is to use protocol identif- ication (PID) procedure. Appendix I presents an in-band parameter exchange procedure for establishing a common terminal adaption (TA) protocol between communicating TA devices. 3.2.2 During the information transfer phase For further study. 4 Parameter exchange functions Parameters exchanged to support interworking may be divided into the following three categories. These parameters may be exchanged end-to-end 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. 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 proto- col supported. An example is the terminal adaption protocol sup- ported, such as V.110, V.120. 4.3 DTE/DCE configuration parameters 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: - modem type (e.g., V-Series number) - data rate (e.g., 9.6 kbit/s, 56 kbit/s) - synchronization (e.g., synchronous or asynchro- nous) - parity (odd, even or no parity) - transmission mode (e.g., half or full duplex) - number of start/stop bits (e.g., 1 or 2) - terminal clock source (e.g., network provided, network independent) - terminal interface signals (e.g., 106, 108) - sub-channel information. 4.4 Operations and maintenance parameters Operations and maintenance parameters are used to convey/monitor the status of the DTE/DCE at the terminating points. Status monitored may include: - terminal power (ON or OFF) - terminal presence (connected or disconnected) - terminal interface signals status (e.g., 106, 108) - terminal clock source (e.g., network provided, network independent) - loopback status (e.g., ON or OFF) 5 Parameter exchange for selection of IWF When an IWF is involved in a connection, parameters can be exchanged to establish compatibility. 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-stage approach in which the user must provide additional information to complete the interworking connection. Note - For examples of interworking configurations, refer to the appropriate I.500-Series Recommendations. Appendix III details examples of parameter exchange for the selection of IWFs in the case of ISDN-PSTN interworking for data. 5.1 Single stage In a single stage approach, the interworking function is han- dled automatically by the network. In order to ensure compatibility of the parameters the following techniques may be used: i) parameter registration ( service profile ) - the DTE/DCE parameters are registered with the ISDN; ii) parameter negotiation - parameter negotiation may be possible between networks and end-users or between networks or between users to determine parameter compatibility where suit- able signalling exists. The signalling capabilities and parameters required may vary and are for further study. For example, see Appendix I of V.110; iii) default parameter identification - the network provides an interworking function with common parameters. Any DCE must conform to the IWF common parameters; iv) parameter adaption - the interworking function recognizes and adapts to the end-user's parameters. For example, for ISDN-PSTN the interworking function may adapt to the modulation standard of the modem (see Appendix III). 5.2 Two stages In the two-stage 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-to-end connection. 6 Reference See Recommendation I.500. APPENDIX I (to Recommendation I.515) Protocol for identification of terminal adaption protocols I.1 As shown in Figure I-1/I.515 the total in-band parameter exchange consists of two distinct phases. These are: a) Phase 1 - the protocol identification (PID) phase, which occurs at the bearer rate (64 kbit/s); b) Phase 2 - the in-band parameter exchange (IPE) which is part of the rate adaption (RA) protocol used during the call. Both these phases are optional and may or may not be imple- mented depending on the particular situation. 1) Phase 1 - PID: after call establishment PID phase begins. 2) Phase 2 - 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. - The IPE allows parameters to be exchanged between TA devices to ensure end-to-end compatibility before entering the data (information) phase. - In the case of a successful IPE the protocol enters the data (information) phase. - 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. Figure I-1/I.515, (N), p. I.2 Identification procedure 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. The protocol identification is performed during the following three steps after the call is placed by using the normal call establishment procedures: 1) end-to-end synchronization; 2) passing the Protocol Identifier (PI); 3) making a decision regarding the type of TA to use for the call. For the case of a device with a PID and one without a PID which interwork, a timer value (Np\di\dd) should be set in the PID for defaulting to the preferred terminal adaption protocol. Np\di\ddmust 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 Np\di\ddshould be set to allow for long delay connections (e.g. satellites). Refer to Figure I-2/I.515 for the timer sequence diagram of a successful protocol identification procedure. The sequence and acronyms in Figure I-2/I.515 are described in SS I.3 to I.5. Figure I-2/I.515, (N), p. I.3 End-to-end synchronization 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-3/I.515). When the originating end sees at least 32 contiguous sync bytes (57hex) it is in sync and starts sending continuous sync bytes (57hex). When the answering end sees 32 contiguous sync bytes it is in sync. The receivers at each end wait for at least 32 contiguous occurrences (4 ms) of the sync byte to be received without corrup- tion before initiating the protocol. The sequence can then proceed to the next step. The synchronization method described in this section allows for: 1) settling of the physical circuit; 2) notice in the network; 3) positive identification of the fact that TA dev- ices are present at both ends; 4) transmission on restricted 64 kbit/s links and through networks that use bit 8 for signalling; and 5) simple implementation. H.T. [T1.515] _____________________________________________________________________________________ Initialization bytes B1 B2 B3 B4 B5 B6 B7 B8 _____________________________________________________________________________________ Originating end 0 1 0 1 1 1 1 1 (5F in hexadecimal) _____________________________________________________________________________________ Answering end 0 1 0 1 0 1 1 1 { (57 in hexadecimal) } _____________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - B1 is transmitted and received first. Note 2 - B8 is set to 1 for transmission and ignored on reception. FIGURE I-3/I.515 Figure I-3/I.515 (comme tableau) [T1.515], p. I.4 Passing the protocol identifier (PI) 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. The PI is split into two bytes and three identical pairs are sent (refer to Figure I-4/I.515). The PI passing technique described in this section: 1) provides positive identification of the protocol bytes (low and high byte codes); 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); 3) allows all eight bits of the PI to be used even on networks that use bit 8 for signalling; and 4) allows for operation on restricted 64 kbit/s networks and networks that use bit 8 for signalling (i.e. guaran- tees one's density, bit 8 set to 1). I.5 TA decision After the answering end has received 32 contiguous sync-bytes (S I.3), it then sends its PI. The protocols supported by the answering end are coded in the PI byte (see Figure I-5/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. Figure I-4/I.515, (N), p. 22 H.T. [T2.515] _______________________________________________________________ P7 P6 P5 P4 P3 P2 P1 P0 _______________________________________________________________ V.110 V.120 X.30 X.31 res. res. res. res. | ua) _______________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Example: 11000000 supports V.110 and V.120 protocols. Note - Bits marked "res." are set to 0, pending future allocation. a) Use of P0 as an extension bit is for further study. FIGURE I-5/I.515 PI interpretation Figure I-5/I.515 (comme tableau) [T2.515], p. 23 After the answering end has sent its PI, it sends a distinct "idle byte" (see Figure I-6/I.515) continuous and waits for the matching PI from the originating end. H.T. [T3.515] _________________________________________________________________ B1 B2 B3 B4 B5 B6 B7 B8 _________________________________________________________________ 0 1 1 1 1 1 1 1 (7F in hexadecimal) _________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - B1 is transmitted and received first. Note 2 - B8 is set to 1 for transmission and ignored on reception. FIGURE I-6/I.515 Idle byte Figure I-6/I.515 (comme tableau) [T3.515], p. The originating end then sends back its PI with only the bit that corresponds to the desired TA protocol set to 1. If the originating end cannot support any of the answering end's TA protocols, it sends back a null PI byte (Figure I-7/I.515), and then terminates the call using normal call disconnection procedures. H.T. [T4.515] _____________________________________________________________________ P0 P1 P2 P3 P4 P5 P6 P7 _____________________________________________________________________ 0 0 0 0 0 0 0 0 { (00 in hexadecimal) FIGURE I-7/I.515 Null PI byte } _____________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Figure I-7/I.515 (comme tableau) [T4.515], p. The method described in this section: a) supports various CCITT recognized forms of TA schemes; b) allows for future TA schemes; c) limits the proliferation of TA schemes; d) allows the originating end to control the selec- tion of the common TA protocol; and e) provides a positive indication of a failed call. APPENDIX II (to Recommendation I.515) 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 termi- nal adaptor supports the procedures of Recs. 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. II.1 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 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-protocol TA as indicated by the received signals. If compa- tibility is not achieved it would provide a disconnect. 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 dif- ferent TA protocols, an MTA should follow the procedures specified in the individual Recommendations. II.2 MTAs intended to interwork with other MTAs The MTA should initiate transmission, following the connect indication, in accordance with Rec. I.465 (V.120). Note - 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 neces- sary number of retries [this is protocol and implementation dependent - see, for example, Recs. I.463 (V.110) and I.465 (V.120)]. APPENDIX III (to Recommendation I.515) Parameter exchange for selection of IWFs in the case of ISDN-PSTN data interworking III.1 Mechanisms for modem selection - General options 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). There are two general categories of modem selection tech- niques: a) mechanisms which do not require the ISDN user to have prior knowledge of the modem characteristics of the PSTN user; b) mechanisms which may require the ISDN user to have prior knowledge of the modem characteristics of the PSTN user. Note - The preferred methods for modem selection for ISDN-PSTN calls are for further study. III.1.1 Mechanisms which do not require the ISDN user to have prior knowledge of the modem characteristics of the PSTN user III.1.1.1 Use of a multi-standard modem at the IWF The modem in the IWF recognizes and adapts to the end-user 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. III.1.1.2 Negotiation Negotiation between end-user 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. III.1.1.3 Registration The DTE/DCE characteristics of the PSTN user are registered with the ISDN. III.1.2 Mechanisms which may require the ISDN user to have prior knowledge of modem characteristics of the PSTN user III.1.2.1 Default identification Any DTE uses the same default modem characteristics. III.1.2.2 Selection by ISDN user of the modem dynamically Using available parameter exchange mechanisms (i.e. SN, LLC/BC, IPE) the user selects specific TA/modem characteristics at the IWF. III.2 ISDN bearer capabilities for interworking III.2.1 3.1 kHz ISDN bearer capability See Figure III-1/I.515. In the scenario the following cases are considered: - terminal is connected to ISDN access via a modem and uses a 3.1 kHz audio bearer through TA; - terminal selection in ISDN is made by means of multiple subscribers numbers. 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. Figure III-1/I.515, (N), p. III.2.2 64 kbit/s ISDN bearer capability The following modem selection procedures apply to ISDN-PSTN interworking (see Figure III-2/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. 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. Figure III-2/I.515, (N), p. III.3 Options for modem selection 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. III.3.1 ISDN-PSTN calls (bidirectional) III.3.1.1 Option 1 (example of the method detailed in S III.1.1.1) This is a single stage modem selection procedure which relies upon the following system requirements: - data terminals on the ISDN have separate SNs; - 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. For a voice-band 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. 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. III.3.1.2 Option 2 (example of the method detailed in III.1.1.3) This is a single stage modem selection procedure which relies on the following system requirements: - circuit data terminals on ISDN loops have separate SNs; - a call progress indicator that PSTN to ISDN, or ISDN to PSTN interworking has occurred; and - service profiles of destination terminals are available at the ISDN exchange (data vs speech terminals, pre-subscribed modem type). III.3.1.2.1 PSTN-to-ISDN call The terminating ISDN exchange recognizes that: - the call is from the PSTN (from the call progress indicator); - the call is for a data terminal (from service profile); and - the modem type subscribed to (from service pro- file). The terminating exchange will insert the pre-subscribed modem type from the pool. III.3.1.2.2 ISDN-to-PSTN call The ISDN terminal will initiate the callas a 64 kbit/s, rate adapted digital data call for all calls to both ISDN and PSTN des- tinations. On the receipt of the progress indicator (ISDN/PSTN interworking), the local exchange will insert the pre-subscribed modem type in the path. If the calling ISDN terminal knows a priori | that the called terminal in on a PSTN analogue loop, it may indicate in the set-up message the pre-subscribed modem type to be inserted. III.3.2 ISDN-to-PSTN calls III.3.2.1 Option 3 (example of the method detailed in III.1.2.2) For a data call originated by a data terminal on the ISDN, the modem selection is done by using some appropriate information ele- ments in the Q.931 set-up 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-standard modem at the IWF. The appropriate modem is inserted in the end-to-end path. III.3.3 PSTN-to-ISDN calls III.3.3.1 Option 4 (example of the method detailed in III.1.2.2 using subscriber number.) This is a two-stage 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 protocol). Therefore for a PSTN-to-ISDN data call, the PSTN user first dials the address of the appropriate group of modems at the ter- minating 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 pro- gress tones for this case needs further study. III.3.3.2 Option 5 (example of the method detailed in III.1.1.2) This is a single-stage modem selection procedure which relies upon the following system requirements: - circuit data terminals on ISDN loops have separate SNs; - PSTN terminals have suitable signalling capabili- ties to indicate the modem speed/type in response to a request from the terminating exchange; - the ISDN exchange can distinguish whether an incoming call is from the PSTN or the ISDN (using call progress indicator); and - the ISDN exchange maintains a data base on ser- vice profiles of terminals served by the exchange (analog vs digi- tal, and speech vs data in case of digital subscribers). The user must be aware of any special operational require- ments. For a voice-band data call originated by a PSTN terminal, and intended for a digital data terminal on the ISDN, the terminating ISDN exchange will recognize that: - the call is coming from the PSTN; and - the call is intended for a digital data terminal on the ISDN. 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. MONTAGE: RECOMMANDATION I.520 SUR LE RESTE DE CETTE PAGE