home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD2.mdf / ccitt / 1992 / i / i520.asc < prev    next >
Text File  |  1993-06-28  |  15KB  |  671 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.     I.324 defines the reference point between two interconnected ISDNs to be the Nx reference point. 
  42. This Recommendation (I.520) identifies other Recommendations which should be applied to the Nx ref-
  43. erence point and clarifies the functions and requirements for interworking at the Nx reference point.
  44.  
  45.  
  46.  
  47. 3.    REQUIRED INFORMATION AND INFORMATION HANDLING
  48.  
  49.  
  50.  
  51.     Figure 1 illustrates the general configuration for interworking between two ISDNs. The information 
  52. given in Tables 1, 2 and 3, when required, has to be carried by Signalling System No. 7 (SS No. 7) 
  53. ISUP and X.75, and is handled at the IWF in one of the following ways:
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.     Tables 1, 2 and 3 also show the classification of information into the above four categories for circuit 
  68. mode bearer services, circuit mode supplementary services and packet mode bearer services respec-
  69. tively.
  70.  
  71.  
  72.  
  73.     Additional information required specifically for OA&M functions is for further study.
  74.  
  75.  
  76.  
  77. 4.    Description of ISDN-ISDN interworking configurations
  78.  
  79.  
  80.  
  81. 4.1    ISDN-ISDN interface where circuit mode bearer services are provided by both ISDNs
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97. FIGURE 2                                 
  98.  
  99.  
  100.  
  101.  
  102.  
  103. 4.1.1    Bearer services
  104.  
  105.  
  106.  
  107.     Individual bearer service categories are defined in the I.230-Series of Recommendations.
  108.  
  109.  
  110.  
  111.     Layer 1 interworking specifications are recommended in I.511. Layers 2 and 3 in the U-plane 
  112. are passed transparently.
  113.  
  114.  
  115.  
  116. 4.1.2    Supplementary services
  117.  
  118.  
  119.  
  120. 4.1.2.1    Other than User-to-user signalling
  121.  
  122.  
  123.  
  124.     For supplementary services other than user-to-user signalling, call control information is trans-
  125. ferred via Signalling System No. 7 across the Nx reference point. The interface for user information 
  126. transfer is not different from that of basic bearer services.
  127.  
  128.  
  129.  
  130. 4.1.2.2    User-to-user signalling services
  131.  
  132.  
  133.  
  134.     There are two methods of transferring user-to-user signalling. One is transfer of user-to-user 
  135. signalling within Q.931 call control messages which have been mapped into Signalling System No. 
  136. 7 messages and then are conveyed via the Signalling System No. 7 network. The other is transfer 
  137. of user-to-user signalling within stand alone USER INFO messages (which have been mapped into 
  138. Signalling System No. 7 messages and then are conveyed via the Signalling System No. 7 net-
  139. work), or optionally may be transferred via packet handlers (PHs) in some ISDNs. In the case 
  140. where user-to-user signalling is transferred between packet handlers (PHs) in both ISDNs, the 
  141. X.75 protocol may be applied to the internetwork interface to transfer user-to-user signalling. In the 
  142. case where user-to-user signalling is transferred via Signalling System No. 7 networks in both 
  143. ISDNs or at least in one ISDN, the Signalling System No. 7 protocol should be applied to the inter-
  144. network interface for user-to-user signalling.
  145.  
  146.  
  147.  
  148. 4.1.3    Signalling System No. 7 for the control of circuit mode services at the Nx reference point
  149.  
  150.  
  151.  
  152.     For the control of circuit mode services in the long term, Signalling System No. 7 with ISUP will 
  153. be used at the Nx reference point.
  154.  
  155. 4.2    ISDN-ISDN Interface where both ISDNs provide X.31 case B based packet mode bearer ser-
  156. vices
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.     The X.75 protocol is used to transfer X.31 based packet mode services at the Nx reference 
  191. point. Layers 1, 2, and 3 for this interface are specified in X.75.
  192.  
  193.  
  194.  
  195. 4.3    ISDN-ISDN Interface where a circuit mode bearer service is provided by one ISDN to access 
  196. either a PSPDN or a PH and an X.31 case B packet mode bearer service provided by another 
  197. ISDN
  198.  
  199.  
  200.  
  201.     With this type of interworking, two different configurations are considered, I and II. In configura-
  202. tion I, interworking between the two ISDNs utilizes X.75 interexchange signalling.
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216. FIGURE 4
  217.  
  218.  
  219.  
  220. Configuration 1
  221.  
  222. ISDN(cs) Interworking with ISDN(ps)
  223.  
  224.  
  225.  
  226. Note - The IWF is logically part of the ISDN (cs). For further detail, see Recommendation X.320.
  227.  
  228.  
  229.  
  230.     In configuration II, a circuit switched access to the PH in the ISDN (ps) is provided, and the interwork-
  231. ing between the two ISDNs utilizes a Signalling System No. 7 protocol.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261. Note - For accessing the PH, the IWF must include access unit (AU) functionality as defined in Recom-
  262. mendation X.31 for the PSPDN.
  263.  
  264.  
  265.  
  266.     This interworking arrangement applies for data transmission services. General arrangements are 
  267. covered in section 6.3 of X.320. There are two possibilities:
  268.  
  269.  
  270.  
  271. i)X.31 case A interworking with X.31 case B. Case A refers to the situation where a transparent cir-
  272. cuit switched access to PSPDN  is provided by ISDN. Case B refers to the situation where a 
  273. packet mode bearer service is provided by an ISDN PH.
  274.  
  275.  
  276.  
  277. ii)ISDN circuit switched access to ISDN PH (this case may exist if the originating ISDN does not 
  278. have PH functionality). 
  279.  
  280.     Several aspects of interworking for data transmission services as well as its application to other 
  281. transmission services are for further study.
  282.  
  283.  
  284.  
  285. 4.4    ISDN-ISDN interworking via a transit network
  286.  
  287.  
  288.  
  289.     ISDN-ISDN interworking via a non-ISDN transit network (Figure 5) may be a useful configuration in 
  290. the short term for extending specific ISDN services on an end-to-end basis. Special transmission, 
  291. switching and signalling capabilities may have to be deployed in the transit network to ensure that the 
  292. specific ISDN service is available end-to-end.
  293.  
  294.  
  295.  
  296.     The detailed interworking functions and interfaces for this configuration are for further study.
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318. FIGURE 5
  319.  
  320.  
  321.  
  322. Interworking of two ISDNs via a transit network
  323.  
  324.  
  325.  
  326. 4.5    ISDN-ISDN Interface for additional packet mode bearer services
  327.  
  328.  
  329.  
  330.     For packet mode services that are currently under study, out-band call control signalling is used. The 
  331. same out-band call control is used for circuit mode services. Two alternatives can be considered for this 
  332. out-band call control: one is enhancement of Signalling System No. 7 and the other is enhancement of 
  333. the D-Channel protocol. The choice between the two alternatives is for further study.
  334.  
  335.  
  336.  
  337. 4.6    ISDN-ISDN Interface where an X.31 case B based packet mode bearer service is provided on one 
  338. ISDN and an additional packet mode bearer service is requested on another ISDN
  339.  
  340.  
  341.  
  342.     Two alternatives can be considered. One is based on in-band   signalling (X.75), and the other is 
  343. based on out-band signalling (Signalling System No. 7 or D-Channel protocol). The choice between the 
  344. two alternatives is for further study.
  345.  
  346. 4.7    ISDN-ISDN Interface for circuit mode to additional packet mode
  347.  
  348.  
  349.  
  350.     This section is for further study.
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364. Note 1 - For charging use.
  365.  
  366.  
  367.  
  368. Note 2 - For discrimination of priority call/ordinary call.
  369.  
  370.  
  371.  
  372. Note 3 - These indicators are used to identify (1) international incoming call, (2) available end-to-end 
  373. signalling system, (3) charged call/noncharged call.
  374.  
  375.  
  376.  
  377. Note 4 - When a satellite circuit is employed for an interworking call at the interworking point, this 
  378. information is processed at the IWF. If a satellite circuit is not employed for a call, this information is 
  379. transferred through the IWF transparently.
  380.  
  381.  
  382.  
  383. Note 5 - This information is used only when access charging is necessary.
  384.  
  385.  
  386.  
  387. Note 6 - All ISDNs do not necessarily provide identical services (or connection types). When a change 
  388. of services occurs at the IWF, the network should send the indication for change of services and may 
  389. solicit acceptance of change of services to a calling user in certain cases (see section 5.3.1 of this 
  390. Recommmendation).
  391.  
  392.  
  393.  
  394. Note 7 - There may be cases where the terminal compatibility information is processed (see section 
  395. 5.4 of this Recommendation).
  396.  
  397.  
  398.  
  399. Note 8 - The information in this category is transferred through the IWF transparently.
  400.  
  401.  
  402.  
  403.     Table 4 shows the permitted relationship between circuit mode bearer services and various forms 
  404. of speech processing functionality. These speech processing functions include DSI, LRE and DCM. 
  405. Depending upon the particular relationship to the circuit mode bearer services, these processing func-
  406. tions are specified as essential, optional, prohibited or functionally disabled.
  407.  
  408.  
  409.  
  410.     For a speech, 3.1 kHz audio, or 64 Kbit/s unrestricted call within an ISDN, appropriate network 
  411. control is required to ensure that the relationship shown within Table 4/I.520 is realized. An example of 
  412. this control might be routing (to exclude or include a function) or out-band signalling (to disable a func-
  413. tion). Further, it is to be noted that a disabling tone (see V.25 and I.530)  may beused to functionally 
  414. remove echo control devices on a 3.1 kHz audio bearer service connection.
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426. 1)the Signalling System No. 7 ISUP bearer capability information element, and
  427.  
  428.  
  429.  
  430.     2)    the use of disabling tone (see V.25 and I.530) by terminals, in the case of 3.1 kHz audio 
  431. bearer service.
  432.  
  433.  
  434.  
  435.     The control of speech processing functions (DCM, A/Mu conversion, echo control, etc.) by exchanges is:  
  436.  
  437.  
  438.  
  439.     1)    not needed when a disabling tone (see V.25 and I.530) is used, in conjunction with the 3.1 kHz 
  440. audio bearer service by a terminal(s), and
  441.  
  442.  
  443.  
  444.     2)    to be implemented using out-band call processes (currently under study) when needed.
  445.  
  446.  
  447.  
  448.     The procedures in the case of alternate speech/64 kbit/s unrestricted bearer service, are for further study.
  449.  
  450.  
  451.  
  452.  
  453.  
  454. Note 1 - Although echo control may not be required in ISDN-ISDN interworking for digital telephones (for fur-
  455. ther study), its inclusion for possible internetworking reasons for the speech bearer service is essential (see 
  456. also I.530)
  457.  
  458.  
  459.  
  460. Note 2 - The necessity for network or terminal provided echo control in 4-wire end-to-end speech connec-
  461. tions is for further study.
  462.  
  463.  
  464.  
  465. Note 3 - For 3.1 kHz audio bearer service, echo control is included in the connection at the time of call setup. 
  466. It is disabled for the transmission of voice-band data by use of the disabling tone (see V.25 and I.530).
  467.  
  468.  
  469.  
  470. Note 4 - The network may include signal processing techniques provided they are appropriately modified or 
  471. functionally removed prior to information transfer.
  472.  
  473.  
  474.  
  475. Note 5 - The IWF converting A/Mu laws should also make the necessary bit translation in the bearer capabil-
  476. ity information element to indicate the law used.
  477.  
  478.  
  479.  
  480. Note 6 - The 64 kbit/s transparent capability will be invoked, subject to the available transmission capacity, 
  481. by the adjoining exchange over a dedicated   out-band signalling system.
  482.  
  483.  
  484.  
  485. Note 7 - The provision of this bearer service using DCM is subject to the ability of the out-band signalling sys-
  486. tem and the DCM equipment to execute      in-call modifications initiated by the adjoining exchange.
  487.  
  488.  
  489.  
  490. Note 8 - The exchange may set up a 64 kbit/s unrestricted bearer path with echo control devices and A/Mu 
  491. law converters (if necessary) enabled for speech. In any case, the set up of parallel paths for speech and 64 
  492. kbit/s unrestricted must be avoided.
  493.  
  494.  
  495.  
  496. Note 9 - Echo control needs to be disabled when continuity check is performed.
  497.  
  498.  
  499.  
  500. 5.2    Generation of in-band tones and announcements for speech and 3.1 kHz audio bearer services
  501.  
  502.  
  503.  
  504. (Note - This function is also necessary for a call within one ISDN, which does not involve network interwork-
  505. ing nor internal ISDN interworking.)
  506.  
  507.  
  508.  
  509. 5.2.1    Unsuccessful call delivery
  510.  
  511.  
  512.  
  513.     The point of call failure (i.e., the point at which the connection cannot proceed further) should generate 
  514. the appropriate out-band clearing message toward the calling exchange. In response to this message, the 
  515. calling   exchange should send the appropriate out-band message to the calling user.  However, for speech 
  516. and 3.1 kHz audio bearer services, the network must be capable of generating the appropriate in-band tones 
  517. or announcements. In this case, the clearing message should not be sent prior to the completion of the 
  518. announcements.
  519.  
  520.  
  521.  
  522. 5.2.2    Successful call delivery
  523.  
  524.  
  525.  
  526.     For speech and 3.1 kHz audio bearer services, the terminating exchange should generate in-band ring 
  527. back tone towards the calling user upon successful delivery of the call.
  528.  
  529.  
  530.  
  531. 5.3    Call negotiation between ISDNs
  532.  
  533.  
  534.  
  535.     There are two aspects of call negotiation between ISDNs: service agreement and connection agreement.
  536.  
  537.  
  538.  
  539. 5.3.1    Service agreement between ISDNs
  540.  
  541.  
  542.  
  543.     Service agreement between ISDNs is defined as established compatibility between the two networks on 
  544. a requested service. The service agreement does not necessarily occur on a call-by-call basis, but in a pre-
  545. determined way which has been agreed by bilateral negotiation between the two ISDNs. If the service agree-
  546. ment is established, connection agreement then begins between the two ISDNs.
  547.  
  548.  
  549.  
  550.     If the service agreement is not established, procedures are for further study, including the following four 
  551. alternatives. Additionally, the impact of these alternatives on user-to-network protocols or inter-network pro-
  552. tocols is for further study.
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574. 5.3.2    Connection agreement between ISDNs
  575.  
  576.  
  577.  
  578.     Connection agreement between ISDNs is defined as negotiation on the connection element 
  579. between the two networks. Connection agreement is required when the connection elements 
  580. employed in each ISDN are different, even if service agreement exists. (For example, see the 
  581. appendix of this Recommendation.) The use of call progress indicators for this purpose is for fur-
  582. ther study.
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598. A/Mu conversion) or agreed between two ISDNS.
  599.  
  600.  
  601.  
  602. 5.4    Compatibility checking between end users of different ISDNs
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.     1)    Low Layer Compatibility (LLC)
  611.  
  612.  
  613.  
  614. LLC information would normally be used for user-to-user call negotiation and would 
  615. be passed transparently through the networks. The IWF may, where required, exam-
  616. ine and act on LLC information (see I.515, section 2.2.1.3) in the cases where the 
  617. LLC checking lists (see Q.931) employed by the relevant ISDNs are different.
  618.  
  619.  
  620.  
  621. 2)    High Layer Compatibility (HLC)
  622.  
  623.  
  624.  
  625. The HLC is to be conveyed transparently and the networks need not operate on it. 
  626. The examination and action on HLC information by the IWF is for further study, in the 
  627. case where the HLC checking lists employed by the relevant ISDNs are different.
  628.  
  629.  
  630.  
  631. 3)User defined Compatibility Checking
  632.  
  633.  
  634.  
  635. User defined compatibility checking is the user responsibility. The network does not 
  636. participate in this compatibility checking.
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658. 7. References
  659.  
  660.  
  661.  
  662. See Recommendation I.500
  663.  
  664. 1.3    Considerations for terminal designed to operate with restricted      64 kbit/s transfer capability (Fig-
  665. ure I-2/I.520)
  666.  
  667.  
  668.  
  669.     Existing terminals at rates less than 64 kbit/s will require rate adaption to operate with restricted 64 
  670. kbit/s transfer capability (see         Recommendation I.464).
  671.