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

  1. 4.    Recommendation I.515
  2.  
  3.  
  4.  
  5. PARAMETER EXCHANGE FOR ISDN INTERWORKING
  6.  
  7.  
  8.  
  9. 1.    General
  10.  
  11.  
  12.  
  13. 1.1    Scope
  14.  
  15.  
  16.  
  17.     The objective of this Recommendation is to provide overall parameter exchange principles and func-
  18. tional descriptions for ISDN interworking. This Recommendation describes the principles for parameter 
  19. exchange mechanisms. It
  20.  
  21. is recognized that depending on the available (end-to-end) signalling capability, the exchange of parame-
  22. ters may use either out- or in-band procedures.
  23.  
  24.  
  25.  
  26.     Parameter exchange may be necessary to establish compatible interworking functions for a variety of 
  27. applications. Typical examples where parameter exchange takes place include, terminal adaption compati-
  28. bility establishment, modem type selection and voice encoding compatibility establishment. This does not 
  29. imply, however, any requirement for an ISDN to support network based modem interworking.
  30.  
  31.  
  32.  
  33.     Figure 1/I.515 illustrates several voice and data applications, supported by different networks and 
  34. mechanisms. Parameter exchange may be necessary where interworking between different terminals or 
  35. networks (as per other Recommendations) is required.
  36.  
  37.  
  38.  
  39. Note - Where interworking procedures exist, the appropriate references are made herein.
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119. M     = MODEM                              IWF = INTERWORKING FUNCTION (May TA(c) = TA WITH 
  120. CODEC                            include: Physical Requirements,                                                 Signalling Require-
  121. ments,                                                 Terminal Adaptation Modulation,                                                 etc.)
  122.  
  123.  
  124.  
  125. FIGURE 1/I.515
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133. Notes to Figure 1/I.515
  134.  
  135.  
  136.  
  137.      1.    IWFs may be located:
  138.  
  139.  
  140.  
  141.     within the network(s),
  142.  
  143.     separate to the network(s),
  144.  
  145.     within the customer's premises.
  146.  
  147.  
  148.  
  149.      2.    The requirement for interworking between terminals may not be inferred     from Figure 1.
  150.  
  151.  
  152.  
  153.      3.    Figure 1/I.515 is not exhaustive.1.2    Definitions and abbreviations
  154.  
  155.  
  156.  
  157.     Use is made of the following terms within this Recommendation. These terms do not necessarily refer to 
  158. any existing protocol structure rather, they define information requirements in the context of this Recommen-
  159. dation.
  160.  
  161.  
  162.  
  163.     -    Bearer capability information
  164.  
  165.  
  166.  
  167.     Specific information defining the lower layer characteristics of the network.
  168.  
  169.  
  170.  
  171.     -    Low layer compatibility information
  172.  
  173.  
  174.  
  175.     Information defining the lower layer characteristics of a TE or TA.
  176.  
  177.  
  178.  
  179.     -    High layer compatibility information
  180.  
  181.  
  182.  
  183.     Information defining the higher layer characteristics of a terminal.
  184.  
  185.  
  186.  
  187.     -    Protocol identifier
  188.  
  189.  
  190.  
  191.     Information defining the specific protocols used by a terminal to support data transfer.
  192.  
  193.  
  194.  
  195.     -    Progress indicator
  196.  
  197.  
  198.  
  199.     Information supplied to indicate to the ISDN terminal that interworking has occurred.
  200.  
  201.  
  202.  
  203.     -    Out-band parameter exchange
  204.  
  205.  
  206.  
  207.     Information exchanged via signalling channels which are not within the channel used for user informa-
  208. tion transfer.
  209.  
  210.  
  211.  
  212.     -    In-band parameter exchange
  213.  
  214.  
  215.  
  216.     Information exchanged using the same information channel as that used for the user information trans-
  217. fer.
  218.  
  219.  
  220.  
  221. 2    Principles
  222.  
  223.  
  224.  
  225. 2.1    Types of parameter exchanges
  226.  
  227.  
  228.  
  229.     Three types of parameter exchange need to be considered:
  230.  
  231.  
  232.  
  233.     i)    end-to-end, out-band as shown in Figure 2/I.515.
  234.  
  235.  
  236.  
  237.         a)    Parameter exchange is accomplished via the D Channel and Signalling System No. 7.
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267. FIGURE 2/I.515
  268.  
  269.  
  270.  
  271. Out-band parameter exchange via D Channel
  272.  
  273.  
  274.  
  275.     ii)    end-to-end, in band as shown in Figure 3/I.515.
  276.  
  277.  
  278.  
  279.         a)    via a transit network
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309. Note - 64 kbit/s connection type is assumed for ISDN
  310.  
  311.  
  312.  
  313.         b)    direct through an extended IDN
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343. Note - The extended IDN shown has 64 kbit/s transmission channel (see I.231), however its signalling system 
  344. is not compatible with that of the ISDN.
  345.  
  346.  
  347.  
  348. FIGURE 3/I.515
  349.  
  350.  
  351.  
  352. In-band parameter exchange
  353.  
  354.  
  355.  
  356.     iii)    Parameter exchange to select IWFs
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386. FIGURE 4/I.515
  387.  
  388.  
  389.  
  390.     The in-band parameter exchange occurs after the establishment of an end-to-end connection and may 
  391. provide for establishment of compatibility between the end points, based on characteristics such as protocol, 
  392. rate adaption scheme and modem type.
  393.  
  394.  
  395.  
  396. 2.2    Relationship of parameter exchange to call establishment
  397.  
  398.  
  399.  
  400.     Parameter exchange may occur:
  401.  
  402.  
  403.  
  404.     i)    prior to Call Establishment (Call Negotiation);
  405.  
  406.  
  407.  
  408.     In this case parameter exchange will occur using out-band techniques.
  409.  
  410.  
  411.  
  412.     ii)    after Call Establishment, prior to information transfer;
  413.  
  414.  
  415.  
  416.     In this case parameter exchange may occur using either in-band or out-band techniques.
  417.  
  418.  
  419.  
  420.     iii)    during the information transfer phase of the call.
  421.  
  422.  
  423.  
  424.     In this case parameter exchange will occur using either out-band or in-band techniques.
  425.  
  426.  
  427.  
  428. 2.2.1    Parameter exchange prior to Call Establishment (Call Negotiation)
  429.  
  430.  
  431.  
  432.     Call Negotiation may be used to satisfy a number of basic call requirements in ISDN. In addition, call 
  433. negotiation may be necessary for interworking as described in I.510 (between terminals, services and net-
  434. works) for:
  435.  
  436.  
  437.  
  438.     a)    Terminal Selection (see I.333, Q.931, Q.932);
  439.  
  440.  
  441.  
  442.     b)    selection of interworking requirements when interworking between ISDN and other dedicated net-
  443. works is identified (e.g. modem type);
  444.  
  445.  
  446.  
  447.     c)    the appropriate selection of network (ISDN or other network)  functions to support the service 
  448. required (e.g., use of call progress indicator);
  449.  
  450.  
  451.  
  452.     d)    the selection of network functions when interworking between incompatible terminals is identified or 
  453. when interworking of different services is required.
  454.  
  455.  
  456.  
  457.     Each of the requirements a) through d) above are necessary during the call establishment phase, there-
  458. fore, call or service negotiation mechanisms should beincluded within basic call establishment procedures. 
  459. Further study is required.
  460.  
  461.  
  462.  
  463. 2.2.1.1    Call Negotiation types
  464.  
  465.  
  466.  
  467.     Three types of Call Negotiation are currently envisaged.
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.     -    Bearer capability (BC);
  510.  
  511.  
  512.  
  513.     -    Low layer compatibility (LLC);
  514.  
  515.  
  516.  
  517.     -    High layer compatibility (HLC).
  518.  
  519.  
  520.  
  521.     The relationship of these information elements to parameter exchange functions is for further study.
  522.  
  523.  
  524.  
  525. Note - BC, LLC, HLC are information elements defined in Recommendation Q.931.
  526.  
  527.  
  528.  
  529. 2.2.1.3    Transfer of information
  530.  
  531.  
  532.  
  533.     The transfer of information associated with Call Negotiation is illustrated in Figure 4/I.515.
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585. Note 1 - The examination of LLC by the network when the IWF is not an addressed entity, is for further study.
  586.  
  587.  
  588.  
  589. Note 2 - The IWF can be distributed (see I.510 for definition of IWF).
  590.  
  591.  
  592.  
  593. Note 3 - When the IWF is on the customer premises, examination of additional information elements to satisfy 
  594. basic call requirements may be appropriate (e.g., sub-address called party ID).
  595.  
  596.  
  597.  
  598. FIGURE 5/I.515
  599.  
  600.  
  601.  
  602. 2.2.2    After call establishment and prior to information transfer phase
  603.  
  604.  
  605.  
  606.     This parameter exchange may be necessary when signalling to allow adequate compatibility checking 
  607. during the call setup phase is not available, or when additional capability checking is required due to charac-
  608. teristics of the terminals which are not defined in call establishment procedures.
  609.  
  610.  
  611.  
  612.     When out-band parameter exchange is used refer to section 3.1.2.
  613.  
  614.  
  615.  
  616.     When in-band parameter exchange is used refer to section 3.2.1.
  617.  
  618.  
  619.  
  620. 2.2.3    During information transfer phase
  621.  
  622.  
  623.  
  624.     This parameter exchange may be necessary when configurations change during the information transfer 
  625. phase (e.g., maintenance, sub-channel information). Detailed aspects are for further study.
  626.  
  627. 3.    Parameter exchange procedures
  628.  
  629.  
  630.  
  631. 3.1    Out-band parameter exchange
  632.  
  633.  
  634.  
  635. 3.1.1    Prior to call establishment
  636.  
  637.  
  638.  
  639.     Refer to Recommendation Q.931 and Q.764. Other protocols are for further study.
  640.  
  641.  
  642.  
  643. 3.1.2    After call establishment prior to information transfer phase
  644.  
  645.  
  646.  
  647.     Refer to Q.931 and Q.764.
  648.  
  649.  
  650.  
  651. 3.1.3    During information transfer phase
  652.  
  653.  
  654.  
  655.     Refer to Q.931 and Q.764.
  656.  
  657.  
  658.  
  659. 3.2    In-band parameter exchange
  660.  
  661.  
  662.  
  663. 3.2.1    After call establishment prior to information transfer
  664.  
  665.  
  666.  
  667.     The following parameter exchange sequence identifies one method of establishing compatibility during 
  668. interworking between an ISDN and existing networks and between ISDNs.
  669.  
  670.  
  671.  
  672.     -    call establishment phase (e.g. refer to Q.931 and Q.764);
  673.  
  674.  
  675.  
  676.     -    originating terminal changes from idle condition to busy         condition;
  677.  
  678.  
  679.  
  680.     -    connection enters parameter exchange phase;
  681.  
  682.  
  683.  
  684.     -    connection enters information transfer phase.
  685.  
  686.  
  687.  
  688. 3.2.1.1    Voice services
  689.  
  690.  
  691.  
  692.     Refer to Recommendation G.725.
  693.  
  694.  
  695.  
  696. 3.2.1.2    Parameter exchange mechanism for terminal adaption protocol     identification
  697.  
  698.  
  699.  
  700.     Some In-band Parameter Exchange (IPE) Procedures are in existence, e.g., Appendix 1 of Recommen-
  701. dation V.110. Two circuit mode terminal adaption procedures are emerging within CCITT (i.e., I.463/V.110 and 
  702. V.120). In many countries, the Terminal Adaptor (TA) design may not be controlled by the administration/
  703. RPOAs so that special forms of terminal adaption may be deployed.  To support multiple forms of terminal 
  704. adaption in a mixed ISDN/non-ISDN network, terminal adaption implementations which support multiple ter-
  705. minal adaption protocols will be required. For use with such implementations, a method is needed for some 
  706. applications to identify the specific terminal adaption protocol to be used by the multifunctional adaptor (MTA) 
  707. devices. This will allow the terminal equipment (or appropriate network component), to release the call where 
  708. compatibility cannot be achieved, or to request the network to provide an appropriate interworking function.
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756. examples, for any given instances of communication, different parameters may be required.
  757.  
  758.  
  759.  
  760. 4.1    Numbering parameters
  761.  
  762.  
  763.  
  764.     -    subscriber number;
  765.  
  766.  
  767.  
  768.     -    sub-address;
  769.  
  770.  
  771.  
  772.     -    terminal selection (see Recommendation I.333).
  773.  
  774.  
  775.  
  776. 4.2    Protocol control parameters
  777.  
  778.  
  779.  
  780.     Protocol control parameters can be used to identify the protocol supported. An example is the terminal 
  781. adaption protocol supported, such as V.110, V.120.
  782.  
  783.  
  784.  
  785. 4.3    DTE/DCE configuration parameters
  786.  
  787.  
  788.  
  789.  
  790.  
  791.     The protocol identification is performed during the following three steps after the call is placed by using the 
  792. normal call establishment procedures:
  793.  
  794. APPENDIX B
  795.  
  796.  
  797.  
  798. TA protocol self identification
  799.  
  800.  
  801.  
  802.  
  803.  
  804.     This appendix discusses guidelines for self-identification procedures that may be used by multi-protocol 
  805. terminal adaptor (MTA) implementations in selecting the protocol to be used on an individual connection. It is 
  806. assumed that the multi-protocol terminal adaptor supports the procedures of I.463(V.110) and I.465 (V.120). 
  807. Where out-band signalling is available 
  808.  
  809. multi-protocol terminal adaptors should function in accordance with the protocol negotiated during call set-up. 
  810. Self-identification procedures are only applicable where such signalling capabilities are not available.
  811.  
  812.  
  813.  
  814. MTAs intended to interwork with Uni-protocol TAs
  815.  
  816.  
  817.  
  818.     The MTA may initiate transmission as if it were a uni-protocol TA conforming to any of the capabilities pro-
  819. vided. The received signals would be examined by the MTA and the MTA should revert to transmission in 
  820. accordance with the procedures of the protocol of the uni-protocol TA as indicated by the received signals. If 
  821. compatibility is not achieved it would provide a disconnect.
  822.  
  823.  
  824.  
  825.     It is noted that there are a range of capabilities that may be implemented in TAs conforming to either I.463 
  826. (V.110) or I.465 (V.120). For distinguishing the capabilities of the different TA protocols, an MTA should follow 
  827. the procedures specified in the individual Recommendations.
  828.  
  829.  
  830.  
  831. MTAs intended to interwork with other MTAs
  832.  
  833.  
  834.  
  835.     The MTA should initiate transmission, following the connect indication, in accordance with Recommenda-
  836. tion I.465 (V.120).
  837.  
  838.  
  839.  
  840. Note - Self identification can be extended to accommodate multiple protocols. It is only necessary to define 
  841. the priority for the use of each protocol and a retry procedure. The general rule would be that an MTA would 
  842. always initiate transmission assuming the protocol of the highest priority supported that has not been tried. 
  843. The MTA would always delay disconnect, when the received signal is not recognized, for a period long 
  844. enough for the necessary number of retries (this is protocol and implementation dependent - see, e.g., I.463 
  845. (V.110) and I.465 (V.120).
  846.  
  847. APPENDIX C
  848.  
  849.  
  850.  
  851. Parameter exchange for selection of IWFs
  852.  
  853. ISDN - PSTN data interworking
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879. Note - The preferred methods for modem selection for ISDN - PSTN calls are for further study.
  880.  
  881.  
  882.  
  883. C.1.1    Mechanisms which do not require the ISDN user to have prior knowledge of the modem characteristics 
  884. of the PSTN user.
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918. C.1.1.3    Registration
  919.  
  920.  
  921.  
  922. The DTE/DCE characteristics of the PSTN user are registered with the ISDN.
  923.  
  924.  
  925.  
  926. C.1.2    Mechanisms which may require the ISDN user to have prior knowledge of modem characteristics of the 
  927. PSTN network user.
  928.  
  929.  
  930.  
  931. C.1.2.1    Default Identification
  932.  
  933.  
  934.  
  935.     Any DTE uses the same default modem characteristics.
  936.  
  937.  
  938.  
  939. C.1.2.2    ISDN user selects the modem dynamically.
  940.  
  941.  
  942.  
  943. Using available parameter exchange mechanisms (i.e. SN, LLC/BC, IPE) the user selects specific TA/
  944. modem characteristics at the IWF.
  945.  
  946.  
  947.  
  948. C.2    ISDN Bearer Capabilities for interworking.
  949.  
  950.  
  951.  
  952. C.2.1    3.1 kHz ISDN Bearer Capability.
  953.  
  954.  
  955.  
  956.  
  957.  
  958.  
  959.  
  960. The IWF may pass parameters (e.g. LLC) to the called user when establishing the ISDN portion 
  961. of the call.
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968.  
  969.  
  970.  
  971. the local exchange will insert the pre-subscribed modem type in the path.
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.     multi-standard modem at the IWF. The appropriate modem is inserted in the end-to-end path.  
  982.  
  983.  
  984.  
  985.  
  986.