ÿWPCL ûÿ2BJ|xÐ ` ÐÐÌÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿH øÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÌÐÐ °°°è ÐÑ Âx„|ü@Ž ÑÐ Å°6Ø'°6Ø'Å Ð Ð H ÐÁHÁI.324 defines the reference point between two interconnected ISDNs to be the NÃÃxÄÄ reference point. This Recommendation (I.520) identifies other Recommendations which should be applied to the NÃÃxÄÄ reference point and clarifies the functions and requirements for interworking at the NÃÃxÄÄ reference point. 3.ÁHÁREQUIRED INFORMATION AND INFORMATION HANDLING ÁHÁFigure 1 illustrates the general configuration for interworking between two ISDNs. The information given in Tables 1, 2 and 3, when required, has to be carried by Signalling System No. 7 (SS No. 7) ISUP and X.75, and is handled at the IWF in one of the following ways: ÁHÁTables 1, 2 and 3 also show the classification of information into the above four categories for circuit mode bearer services, circuit mode supplementary services and packet mode bearer services respectively. ÁHÁAdditional information required specifically for OA&M functions is for further study. ÕOÏ Ð ` Ð Áà@Á©  ©ƒ Áà<ÁAP IX©147©Eƒ OÕÕOÏ Ð ` Ð Áà@Á©  ©ƒ Áà<ÁAP IX©147©Eƒ OÕÐ °èè Ð4.ÂXHÂÓÓÃÃDescription of ISDN©ISDN interworking confiÄÄgÃÃurationsÄÄÆÆ 4.1ÂàHÂÃÃISDN©ISDN interface where circuit mode bearer services are provided byÄÄ ÃÃboth ISDNsÄÄÆÆ ÁàH:ÁFIGURE 2 ƒ ƒ ÁàHNÁƒ 4.1.1ÁHÁÃÃBearer servicesÄÄ ÁHÁIndividual bearer service categories are defined in the I.230©Series of Recommendations. ÁHÁLayer 1 interworking specifications are recommended in I.511. Layers 2 and 3 in the U©plane are passed transparently. 4.1.2ÂðHÂÃÃSupplementary servicesÄÄÆÆ 4.1.2.1Á  ÁÃÃOther than User©to©user signallingÄÄ ÁHÁFor supplementary services other than user©to©user signalling, call control information is transferred via Signalling System No. 7 across the NÃÃxÄÄ reference point. The interface for user information transfer is not different from that of basic bearer services. 4.1.2.2Á  ÁÃÃUser©to©user signalling servicesÄÄ ÁHÁThere are two methods of transferring user©to©user signalling. One is transfer of user©to©user signalling within Q.931 call control messages which have been mapped into Signalling System No. 7 messages and then are conveyed via the Signalling System No. 7 network. The other is transfer of user©to©user signalling within stand alone USER INFO messages (which have been mapped into Signalling System No. 7 messages and then are conveyed via the Signalling System No. 7 network), or optionally may be transferred via packet handlers (PHs) in some ISDNs. In the case where user©to©user signalling is transferred between packet handlers (PHs) in both ISDNs, the X.75 protocol may be applied to the internetwork interface to transfer user©to©user signalling. In the case where user©to©user signalling is transferred via Signalling System No. 7 networks in both ISDNs or at least in one ISDN, the Signalling System No. 7 protocol should be applied to the internetwork interface for user©to©user signalling. 4.1.3ÂðHÂÃÃSignalling System No. 7 for the control of circuit mode services at theÄÄ ÃÃNx reference pointÄÄÆÆ ÁHÁFor the control of circuit mode services in the long term, Signalling System No. 7 with ISUP will be used at the NÃÃxÄÄ reference point. 4.2ÂàHÂÃÃISDN©ISDN Interface where both ISDNs provide X.31 case B based packetÄÄ ÃÃmode bearer servicesÄÄÆÆ ÁHÁThe X.75 protocol is used to transfer X.31 based packet mode services at the NÃÃxÄÄ reference point. Layers 1, 2, and 3 for this interface are specified in X.75. 4.3ÂàHÂÃÃISDN©ISDN Interface where a circuit mode bearer service is provided byÄÄ ÃÃone ISDN to access either a PSPDN or a PH and an X.31 case B packetÄÄ ÃÃmode bearer service provided by another ISDNÄÄÆÆ ÁHÁWith this type of interworking, two different configurations are considered, I and II. In configuration I, interworking between the two ISDNs utilizes X.75 interexchange signalling. ÁàHJÁFIGURE 4ƒ ÁàHNÁƒ ÁàHGÁÃÃConfiguration 1Äă ÁàH=ÁÃÃISDN(cs) Interworking with ISDN(ps)Äă ÃÃNoteÄÄ © The IWF is logically part of the ISDN ÃÃ(cs)ÄÄ. For further detail, see Recommendation X.320. ÁHÁIn configuration II, a circuit switched access to the PH in the ISDN ÃÃ(ps)ÄÄ is provided, and the interworking between the two ISDNs utilizes a Signalling System No. 7 protocol. Ð h ÐÃÃNoteÄÄ © For accessing the PH, the IWF must include access unit (AU) functionality as defined in Recommendation X.31 for the PSPDN. ÁHÁThis interworking arrangement applies for data transmission services. General arrangements are covered in section 6.3 of X.320. There are two possibilities: Ð À ÐÂHHÂi)Âh   ÂX.31 case A interworking with X.31 case B. Case A refers to the situation where a transparent circuit switched access to PSPDN is provided by ISDN. Case B refers to the situation where a packet mode bearer service is provided by an ISDN PH.ÆÆ Ð ` Ð Ð À ÐÂHHÂii)Âð   ÂISDN circuit switched access to ISDN PH (this case may exist if the originating ISDN does not have PH functionality). ÆÆ Ð Ð ÐÁHÁSeveral aspects of interworking for data transmission services as well as its application to other transmission services are for further study. 4.4ÂàHÂÃÃISDN©ISDN interworking via a transit networkÄÄÆÆ ÁHÁISDN©ISDN interworking via a non©ISDN transit network (Figure 5) may be a useful configuration in the short term for extending specific ISDN services on an end©to©end basis. Special transmission, switching and signalling capabilities may have to be deployed in the transit network to ensure that the specific ISDN service is available end©to©end. ÁHÁThe detailed interworking functions and interfaces for this configuration are for further study. ÁàHKÁFIGURE 5ƒ ÁàHOÁƒ ÁàH8ÁÃÃInterworking of two ISDNs via a transit networkÄă 4.5ÁHÁÃÃISDN©ISDN Interface for additional packet mode bearer servicesÄÄ ÁHÁFor packet mode services that are currently under study, out©band call control signalling is used. The same out©band call control is used for circuit mode services. Two alternatives can be considered for this out©band call control: one is enhancement of Signalling System No. 7 and the other is enhancement of the D©Channel protocol. The choice between the two alternatives is for further study. 4.6ÂàHÂÃÃISDN©ISDN Interface where an X.31 case B based packet mode bearerÄÄ ÃÃservice is provided on one ISDN and an additional packet mode bearerÄÄ ÃÃservice is requested on another ISDNÄÄÆÆ ÁHÁTwo alternatives can be considered. One is based on in©band signalling (X.75), and the other is based on out©band signalling (Signalling System No. 7 or D©Channel protocol). The choice between the two alternatives is for further study. 4.7ÁHÁÃÃISDN©ISDN Interface for circuit mode to additional packet modeÄÄ ÁHÁThis section is for further study. ÃÃNote 1ÄÄ © For charging use. ÃÃNote 2ÄÄ © For discrimination of priority call/ordinary call. ÃÃNote 3ÄÄ © These indicators are used to identify (1) international incoming call, (2) available end©to©end signalling system, (3) charged call/noncharged call. ÃÃNote 4ÄÄ © When a satellite circuit is employed for an interworking call at the interworking point, this information is processed at the IWF. If a satellite circuit is not employed for a call, this information is transferred through the IWF transparently. ÃÃNote 5ÄÄ © This information is used only when access charging is necessary. ÃÃNote 6ÄÄ © All ISDNs do not necessarily provide identical services (or connection types). When a change of services occurs at the IWF, the network should send the indication for change of services and may solicit acceptance of change of services to a calling user in certain cases (see section 5.3.1 of this Recommmendation). ÃÃNote 7ÄÄ © There may be cases where the terminal compatibility information is processed (see section 5.4 of this Recommendation). ÃÃNote 8ÄÄ © The information in this category is transferred through the IWF transparently. ÁHÁTable 4 shows the permitted relationship between circuit mode bearer services and various forms of speech processing functionality. These speech processing functions include DSI, LRE and DCM. Depending upon the particular relationship to the circuit mode bearer services, these processing functions are specified as essential, optional, prohibited or functionally disabled. ÁHÁFor a speech, 3.1 kHz audio, or 64 Kbit/s unrestricted call within an ISDN, appropriate network control is required to ensure that the relationship shown within Table 4/I.520 is realized. An example of this control might be routing (to exclude or include a function) or out©band signalling (to disable a function). Further, it is to be noted that a disabling tone (see V.25 and I.530) may beÔ .,Ô used to functionally remove echo control devices on a 3.1 kHz audio bearer service connection. Ð 8 ÐÂHHÂ1)Âh   Âthe Signalling System No. 7 ISUP bearer capability information element, andÆÆ Ð ` Ð Ð À ÐÁHÁ2)Âh   Âthe use of disabling tone (see V.25 and I.530) by terminals, in the case of 3.1 kHz audio bearer service.ÆÆ ÁHÁThe control of speech processing functions (DCM, A/Mu conversion, echo control, etc.) by exchanges is: ÁHÁ1)Âh   Ânot needed when a disabling tone (see V.25 and I.530) is used, in conjunction with the 3.1 kHz audio bearer service by a terminal(s), andÆÆ ÁHÁ2)Âh   Âto be implemented using out©band call processes (currently under study) when needed.ÆÆ ÁHÁThe procedures in the case of alternate speech/64 kbit/s unrestricted bearer service, are for further study. Ð h ÐÃÃNote 1ÄÄ © Although echo control may not be required in ISDN©ISDN interworking for digital telephones (for further study), its inclusion for possible internetworking reasons for the speech bearer service is essential (see also I.530) ÃÃNote 2ÄÄ © The necessity for network or terminal provided echo control in 4©wire end©to©end speech connections is for further study. ÃÃNote 3ÄÄ © For 3.1 kHz audio bearer service, echo control is included in the connection at the time of call setup. It is disabled for the transmission of voice©band data by use of the disabling tone (see V.25 and I.530). ÃÃNote 4ÄÄ © The network may include signal processing techniques provided they are appropriately modified or functionally removed prior to information transfer. ÃÃNote 5ÄÄ © The IWF converting A/Mu laws should also make the necessary bit translation in the bearer capability information element to indicate the law used. ÃÃNote 6ÄÄ © The 64 kbit/s transparent capability will be invoked, subject to the available transmission capacity, by the adjoining exchange over a dedicated out©band signalling system. ÃÃNote 7ÄÄ © The provision of this bearer service using DCM is subject to the ability of the out©band signalling system and the DCM equipment to execute in©call modifications initiated by the adjoining exchange. ÃÃNote 8ÄÄ © The exchange may set up a 64 kbit/s unrestricted bearer path with echo control devices and A/Mu law converters (if necessary) enabled for speech. In any case, the set up of parallel paths for speech and 64 kbit/s unrestricted must be avoided. ÃÃNote 9ÄÄ © Echo control needs to be disabled when continuity check is performed. 5.2ÂàHÂÃÃGeneration of in©band tones and announcements for speech and 3.1 kHzÄÄ ÃÃaudio bearer servicesÄÄÆÆ (ÃÃNoteÄÄ © This function is also necessary for a call within one ISDN, which does not involve network interworking nor internal ISDN interworking.) 5.2.1ÂðHÂÃÃUnsuccessful call deliveryÄÄÆÆ ÁHÁThe point of call failure (i.e., the point at which the connection cannot proceed further) should generate the appropriate out©band clearing message toward the calling exchange. In response to this message, the calling exchange should send the appropriate out©band message to the calling user. However, for speech and 3.1 kHz audio bearer services, the network must be capable of generating the appropriate in©band tones or announcements. In this case, the clearing message should not be sent prior to the completion of the announcements. 5.2.2ÂðHÂÃÃSuccessful call deliveryÄÄÆÆ ÁHÁFor speech and 3.1 kHz audio bearer services, the terminating exchange should generate in©band ring back tone towards the calling user upon successful delivery of the call. 5.3ÁHÁÃÃCall negotiation between ISDNsÄÄ ÁHÁThere are two aspects of call negotiation between ISDNs: service agreement and connection agreement. 5.3.1ÂðHÂÃÃService agreement between ISDNsÄÄÆÆ ÁHÁService agreement between ISDNs is defined as established compatibility between the two networks on a requested service. The service agreement does not necessarily occur on a call©by©call basis, but in a pre©determined way which has been agreed by bilateral negotiation between the two ISDNs. If the service agreement is established, connection agreement then begins between the two ISDNs. ÁHÁIf the service agreement is not established, procedures are for further study, including the following four alternatives. Additionally, the impact of these alternatives on user©to©network protocols or inter©network protocols is for further study. 5.3.2ÁHÁÃÃConnection agreement between ISDNsÄÄ ÁHÁConnection agreement between ISDNs is defined as negotiation on the connection element between the two networks. Connection agreement is required when the connection elements employed in each ISDN are different, even if service agreement exists. (For example, see the appendix of this Recommendation.) The use of call progress indicators for this purpose is for further study. Ô .,ÔŒ A/Mu conversion) or agreed between two ISDNS. 5.4ÁHÁÃÃCompatibility checking between end users of different ISDNsÄÄ ÁHÁ1)Âh   ÂLow Layer Compatibility (LLC)ÆÆ Ð ( ÐÂHHÂÂX  ÂLLC information would normally be used for user©to©user call negotiation and would be passed transparently through the networks. The IWF may, where required, examine and act on LLC information (see I.515, section 2.2.1.3) in the cases where the LLC checking lists (see Q.931) employed by the relevant ISDNs are different.ÆÆ Ð ` Ð ÂHHÂ2)Á   ÁHigh Layer Compatibility (HLC)ÆÆ Ð Ð ÐÂHHÂÂX  ÂThe HLC is to be conveyed transparently and the networks need not operate on it. The examination and action on HLC information by the IWF is for further study, in the case where the HLC checking lists employed by the relevant ISDNs are different.ÆÆ Ð ` Ð ÂHHÂ3)Âh   ÂUser defined Compatibility CheckingÆÆ Ð À ÐÂHHÂÂX  ÂUser defined compatibility checking is the user responsibility. The network does not participate in this compatibility checking.ÆÆ Ð ` Ð 7. References See Recommendation I.500 Ð H Ð1.3ÁHÁConsiderations for terminal designed to operate with restricted 64 kbit/s transfer capability (Figure I©2/I.520) ÁHÁExisting terminals at rates less than 64 kbit/s will require rate adaption to operate with restricted 64 kbit/s transfer capability (see Recommendation I.464).