InfoMagic Standards 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1988 / ascii / 7_5_03.txt < prev next >

Wrap

Text File | 1991-12-22 | 77.0 KB | 2,599 lines

5i' MONTAGE: FIN DE LA RECOMMANDATION T.71 EN-T | TE DE CETTE PAGE Recommendation T.90 CHARACTERISTICS AND PROTOCOLS FOR TERMINALS FOR TELEMATIC SERVICES IN ISDN (Melbourne, 1988) CONTENTS 1 Scope 1.1 General 1.2 Use of Bearer capabilities 1.3 Protocol architecture 2 ISDN circuit-switched mode (DTE-DTE communication) 2.1 Protocol set 2.2 Application rules for B-channel circuit-switched mode 3 ISDN packet-switched mode (DTE-DCE communication) 3.1 Protocol set 3.2 Application rules for B-channel packet-switched mode 4 Provision of the OSI-NS 4.1 Rationale for considering the OSI Network Ser- vice 4.2 Architecture/Available ISO Standards and CCITT Recommendations 4.3 Requirements for the OSI-NS 5 Additional X.25 optional user facilities 5.1 Categories of additional functionalities 5.2 Functionalities .bp 6 Interactions between the D-channel and B-channel 7 Supplementary services 8 Terminal response time 9 Synchronization 10 Higher layer protocols 10.1 Transport layer Annex A - Procedures for connection establishment, connection release and information transfer Appendix I - Consideration of incoming calls for fac- simile terminals from networks without HLC provision Appendix II - Optional usage of the T.70 NL protocol Appendix III - Service definitions and state transition diagrams for the Data Link layer within the B-channel (CS-mode) Appendix IV - Possible model for telematic endsystems taking into account the D-channel/B-channel coordination function 1 Scope 1.1 General ISDN has been defined to support a wide range of voice and non-voice services, and applications, in the same network based on a multipurpose user-network interface. This Recommendation describes the requirements for Telematic terminals, developed for ISDN application, and connected to an ISDN specified by the Recommendations of the I-Series. This Recommendation covers Teletex, Group 4 facsimile, mixed mode and videotex terminals. Terminal requirements to support other Telematic services are for further study. Terminals developed for the provision of Telematic services in CSPDNs, PSPDNs and PSTNs, using Terminal adaptors to access the ISDN are not covered by this Recommendation. Interworking with existing Telematic terminals connected to CSPDNs, PSPDNs and PSTNs, thereby maintaining the Telematic service integrity, should be possible, but is outside the scope of this Recommendation. 1.2 Use of bearer capability This Recommendation is based on the use of bearer capabilities defined for the ISDN, using B-channels for the information transfer and virtual circuit call control and the D-channel for the call control. The use of both, circuit-switched and packet-switched informa- tion transfer modes is defined. The use of the frame mode information transfer as defined in Recommendation I.122 is for further study. 1.3 Protocol architecture This Recommendation provides the application rules for other CCITT-Recommendations and ISO Standards with particular expansion aiming at the applicability for end-to-end (DTE-DTE) communication through the network as well as DTE-DCE interconnection and the OSI-Network Service. The use of existing protocols for ISDN Telematic terminals different from those described in S 2, e.g. T.70, CSPDN minimum header is optional. The optional implementation of more than one type of protocol, and use of the appropriate protocol on a per-call-basis for commun- ication between Telematic terminals, following the protocols described in this Recommendation, and terminals using optional protocols, is the responsibility of the user of such optional pro- tocols. 2 ISDN circuit-switched mode (DTE-DTE communication) For this mode, the circuit-switched 64 kbit/s unrestricted information transfer capability shall be used. For additional information regarding connection control, see S A.1 | ). For additional information regarding the information transfer phase, see S A.1 | ). 2.1 Protocol set The protocol set applicable to the circuit-switched mode (CS mode) is shown in Figure 1/T.90. Figure 1/T.90 [T1.90] (a traiter comme tableau MEP), p. 2.2 Application rules for B-channel circuit-switched mode 2.2.1 Layer 1 physical layer interface characteristics The physical interface characteristics shall be in accordance with the I-Series Recommendations; I.430 (Basic user-network inter- face, Layer 1 specifications), I.431 (Primary rate user-network interface, Layer 1 specifications). This layer provides full a duplex transmission capability. 2.2.2 Connection control phase Recommendation Q.921 shall apply. 2.2.3 Layer 2 information transfer phase The link layer procedure shall consist of a fully symmetrical HDLC procedure as defined in Recommendation X.75 for single link operation. The use of other protocols (e.g. LAPD) is left for further study. 2.2.3.1 Address procedure The following describes the application of the link addressing procedures of Recommendation X.75. Link addresses (A and B) shall be assigned dynamically on a per-call basis according to the fol- lowing rules: a) the calling terminal shall take address A; b) the called terminal shall take address B; c) commands and responses shall be transferred as shown in Figure 2/T.90; d) A and B addresses are coded as follows: Address 12345678 A 11000000 B 10000000 Note - The terminal will discard all frames received with an address other than A and B. Figure 2/T.90, p. 2.2.3.2 Implementation rules In order to achieve full compatibility between different implementations, the rules below for the implementation of Recom- mendation X.75 shall be followed. 2.2.3.2.1 General rules a) The 1984 version (Red Book ) of CCITT Recommendation X.75, S 2, shall be used as the reference specifi- cation. b) The term "STE" shall be read as "DTE". c) At present the non-extended mode of operation (modulo 8) and the extended mode of operation (modulo 128) are defined and in use. The desire to improve the efficiency of satellite transmis- sions and the evolution towards the use of LAPD (modulo 128 only) in layer 2 of the B-channel is expected to lead to the use of modulo 128 as the common base modulo. However, the use of modulo 8 may be allowed. To facilitate interworking between terminal equipments using modulo 8 and 128 respectively a procedure based on, e.g. a negotiation mechanism using a low layer. Compatibility check between the endpoints should be defined. This is for further study. d) Only the single link procedure (SLP) shall be used. 2.2.3.2.2 Specific rules The following rules refer to the indicated sections and tables of Recommendation X.75. a) Table 1/X.75 I-frames should not be sent with an empty I field N _" 0 and N N1-32 received empty I-frames shall be treated as valid I-frames. b) S 2.3.4.9 Sub-paragraphs 5), 6) and 7) are not valid (shall not result in the sending of an FRMR). Instead the following actions shall be implemented: - Not expected supervisory frames with the F bit set to 1 shall be ignored. - Not expected UA or DM response shall be ignored. - Frames with an invalid N(S) shall be responded to by sending REJ (see S 2.3.5.2.1 of Recommendation X.75). Frames with an FRMR cntrol field shall not be responded by sending of an FRMR. c) Table 7/X.75 Bits W, X, Y and Z set to 0 indicate that no reason for frame rejection is given. d) S 2.3.5.3 The DTE and the ISDN are not octet aligned and the last paragraph is therefore not valid. e) S 2.3.5.5 Higher layers should be notified when timer T3 expires (excessive idle state). f ) S 2.4.3 Related to the first paragraph, read instead of "next response" "corresponding response". g) S 2.4.4.1 In the active channel state, the DTE shall transmit con- tiguous flags independent of the other DTE. The calling DTE shall initiate the link by sending an SABM command with the P-bit set to 1. h) S 2.4.4.4.1 A condition for entering the disconnected phase is also that no unacknowledged DISC command exists, because of collision cases (see Recommendation X.75, S 2.4.4.5). In the disconnected phase, it is the calling DTE which may initiate link set up. i) S 2.4.5.9, fourth paragraph If a RNR is received, the DTE shall remain in the timer recovery condition (because the other DTE is still in the busy con- dition). j ) S 2.4.5.9, fifth paragraph If an RNR is received, the DTE shall not resume I-frame transmission or retransmission. k) S 2.4.5.9, last paragraph If the transmission attempt variable is equal to N2, the DTE shall enter the disconnected phase. l) S 2.4.7.3 In the frame rejection condition, the DTE shall only check the commands and react with an FRMR according to the P-bit. The frame rejection condition is cleared when the DTE receives an SABM, or, receives or transmits a DISC command. m) S 2.4.7.3, second paragraph Only the DTE which caused the FRMR condition may try to reset the link. n) S 2.4.7.3, third paragraph (see Note 1) After N2 attempts to get the other DTE to reset the link, the DTE shall enter the disconnected phase. o) S 2.4.8.1 (see Note 2) The timer T1 shall be started at the end of frame transmission. The value of T1 depends on the data signalling rate, the frame length, the value of N2, and a fixed time representing both T2 and the transmission delay [see item | )]. A value is recommended between 2.5 and 7 seconds. Con- sideration of a specific value requires further study. p) S 2.4.8.2 (see Note 2) T1 > T2 T2 < 1 second Depending on the acknowledgement strategy used, the DTE designer may regard T2 as a design parameter only, in which case the DTE is not obliged to implement a corresponding timer. q) S 2.4.8.3, second paragraph T3 60 seconds T3 _" 30 seconds r) S 2.4.8.4 N2 _" 60 seconds - T1 s) S 2.4.8.5 N1 = 2112 + (n x 1024) bits; n = 0 or 2 or 6 or 14. t) S 2.4.8.6 (see Notes 2,3) k = 7 Note 1 - It is not meaningful to reset the link if the other DTE is not responding for N2 x T1. Note 2 - The acknowledgement strategy used by the receiv- ing DTE should be independent of any knowledge about the value of k used by the sending DTE. This can be achieved by either acknowledg- ing every correctly received I-frame as soon as possible or by implementing an acknowledgement timer, i.e., a T2 timer as defined above [see item | )]. Note 3 - Further study is needed on a mechanism for nego- tiation of k. 2.2.4 Layer 3 - connection control phase Recommendation Q.931 shall apply. All encodings should be derived from the relevant section in Q.931. Three information elements (IEs) are of particular interest to terminals accessing Telematic services. See Annexes B and M of Recommendation Q.931 for further information. - Bearer capability (BC) information element. The BE IE is used to carry information of interest to the bearer ser- vice providing network. The BE IE is required to be generated by the calling side, and must be examined by the called side. - Low layer compatibility (LLC) information ele- ment. The LLC IE is used to carry information about protocols at and below the network layer of interest only to the two endsystems. The LLC IE shall be generated by the calling side, and should be examined, if present, by the called side. - High layer compatibility (HLC) information ele- ment. The HLC IE is used to carry information between the endsys- tems related to protocols above the network layer. The HLC IE shall be generated by the calling side, and should be examined, if present, by the called side. Fields in bearer capability (BC), low layer compatibility (LLC), and high layer compatibility (HLC) information elements (IE) to be conveyed at the S/T reference point of the user-network interface during the call establishment phase, shall be set to the values defined below. 2.2.4.1 Bearer capability (BC) a) Mandatory fields, to be set to the fixed values (the value to be set is given in parentheses following each field description): - Coding standard - octet 3 (CCITT standardized coding, as defined below). - Information transfer capability - octet 3 (unrestricted digital information, see Note). - Transfer mode - octet 4 (circuit mode). - Information transfer rate - octet 4 (64 kbit/s). b) Fields not required in the default case (these may be explicitly encoded): - Structure - octet 4a. - Configuration - octet 4a. - Establishment - octet 4a. - Symmetry - octet 4a. c) Fields to be omitted due to no necessity: - All other fields. Note - The selection whether to use unrestricted or res- tricted information transfer capability is out of the scope of this Recommendation. 2.2.4.2 Low layer compatibility (LLC) The LLC IE shall be encoded as follows: a) Fields to be set to fixed values (the value to be set is given in parentheses following each field description). Details of coding points and the relevant encodings are for further study. 2.2.4.3 High layer compatibility (HLC) The HLC IE shall be encoded as follows: a) Fields to be set to fixed values (the value to be set is given in parentheses following each field description). - Coding standard - octet 3 (CCITT standardized coding, as defined below). - Interpretation - octet 3 (first high layer characteristics identification to be used in the call). - Presentation method of protocol profile - octet 3 (high layer protocol profile). b) Fields with variable content: - High layer characteristics identification - octet 4 (e.g., Facsimile Group 4, Teletex). To maximize the usefulness of HLC checking: 1) the calling telematic terminal shall select the HLC element according to the type of document to be tranferred; 2) the called terminal holds a list of HLC ele- ments describing its receiving capabilities. It will accept an HLC element corresponding to any one of these. This scheme is illustrated in Table 1/T.90. 2.2.5 Layer 3 - virtual connection control and information transfer ISO 8208 (1987) shall apply. Note - This protocol, based on the l984 version of Recommendation X.25, is partially expanded in order to include DTE-DTE application. In particular, the following sections of ISO 8208 are referred: - S 3.2: Differences in DTE/DTE and DTE/DCE opera- tion - S 3.3: Operating over circuit-switched connec- tions - S 4.5: Determining "DTE" or "DCE" characteristics In addition, the following points should be noted when using this protocol. a) Calling DTE shall send a RESTART REQUEST packet, begin the restart procedure, and establish virtual cir- cuits. See S 3.3 of ISO 8208. b) The qualifier bit in data packets should always be set to "0". c) The delivery confirmation bits in all packets should be set to "0". d) Normal X.25 reset procedures will apply. e) Each control block or data block of the tran- sport layer shall be carried in a complete data packet sequence. f ) The terminal should not send a DTE REJECT packet. g) In case of Group 4 facsimile and Teletex, termi- nals shall use a specific protocol identifier within CALL REQUEST/INCOMING CALL packets. This identifier is represented by the first octet of the call user data field (remaining octets, if any should be ignored) as shown below: bit 87654321 octet 00000010 octet 00000010 The use of this protocol identifier for Videotex is for further study. H.T. [T2.90] TABLE 1/T.90 Use of HLC codes by various Telematic terminals _____________________________________________________________________________ HLC codes { { Telematic service terminals _____________________________________________________________________________ Teletex basic Basic Teletex Basic Teletex _____________________________________________________________________________ Teletex mixed mode { Basic Teletex Mixed mode (Note 1) } Basic Teletex Mixed mode _____________________________________________________________________________ Group 4 facsimile class 1 Group 4 facsimile Group 4 facsimile _____________________________________________________________________________ Group 4 facsimile class 2 Group 4 facsimile { Group 4 facsimile Mixed mode Basic Teletex } _____________________________________________________________________________ Group 4 facsimile class 3 { Group 4 facsimile Mixed mode Basic Teletex (Note 1) } { Group 4 facsimile Mixed mode Basic Teletex } _____________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - In case that the calling terminal is Teletex, Mixed mode or group 4 facsimile class 3, only one element shall be sent depending on originating document type. Note 2 - For multi-service telematic terminals sending more than one document in the same call, the HLC shall indicate the maximum requirement for that call. For example, when sending a Teletex and a Mixed mode document, the Mixed mode HLC element shall be sent. Note 3 - When the calling terminal only wishes to receive a docu- ment from a called terminal (polling), it shall know in advance the type of document it expects to receive in order to send the appropriate HLC element. Note 4 - Appendix I provides additional information in order to cater for cases where calls for facsimile equipment are incoming from networks not able to convey HLC information. Tableau 1/T.90 [T2.90], p. 2.2.6 Layer 3 - packet size (NPDU block length) The rules for packet size negotiation are given in S 15.2.2.1.1 of ISO 8208. The values for this Recommendation are res- tricted to 256, 512, 1024 and 2048 octets. 3 ISDN packet switched mode (DTE-DCE communication) 3.1 Protocol set The protocol set applicable to the packet-switched mode (PS mode) is shown in Figure 3/T.90. Figure 3/T.90 [T3.90] (a traiter comme tableau MEP), p. 3.2 Application rules for B-channel packet-switched mode 3.2.1 Layer 1 - physical layer interface characteristics See S 2.2.1. 3.2.2 Layer 2 - link layer procedure Recommendation X.31 shall apply, so that the applied protocols are as follows: - Connection control is to be achieved using Recommendation Q.921 in the D-channel. - Virtual connection control and information transfer is to be achieved using Recommendation X.25 LAPB in the B-channel. 3.2.3 Layer 3 - network layer procedure Recommendation X.31 shall apply, so that protocols to be applied and application rules are as follows. 3.2.3.1 Connection control phase Recommendation Q.931 and the packet layer protocol of Recommendation X.25 shall apply. Fields in the bearer capability (BC) information element (IE) to be conveyed at the S/T reference point of the user-network interface during the call establishment phase, shall be set to the values defined below. Recommendation Q.931 shall apply. All encodings should be derived from the relevant paragraph in Q.931. - Bearer capability (BC) information element. The BC IE is used to carry information of interest to the bearer ser- vice providing network. The BC IE is required to be generated by the calling side, and must be examined by the called side. 3.2.3.1.1 Bearer capability (BC) a) Mandatory fields, to be set to the fixed values (the value to be set is given in parentheses following each field description): - Coding standard - octet 3 (CCITT standardized coding as defined below). - Information transfer capability - octet 3 (unrestricted digital information - Note). - Transfer mode - octet 4 (packet mode). - User information layer 1 protocol - octet 5 (CCITT standardized rate adaption Recommendation X.31 HDLC flag stuffing). - User information layer 2 protocol - octet 6 (CCITT Recommendation X.25, link level). - User information layer 3 protocol - octet 7 (CCITT Recommendation X.25, packet layer). b) Fields not required in the default case (these may be explicitly encoded): - Structure - octet 4a. - Configuration - octet 4a. - Establishment - octet 4a. - Symmetry - octet 4a. c) Fields to be omitted due to no necessity: - All other fields. Note - The selection whether to use unrestricted or res- tricted information transfer capability is out of the scope of this Recommendation. The high layer compatibility information element (HLC) is not used in PS mode. The use of the HLC in future evolutions of the ISDN packet mode service is for further study. The low layer compatibility information element (LLC) is not used in PS mode. The use of the LLC in future evolutions of the ISDN packet mode service is for further study. 3.2.3.2 Virtual connection control and information transfer Recommendation X.25 packet layer protocol applies. Item b) and items | ) through | ) of the application rules specified in S 2.2.5 apply. 4 Provision of the OSI network service (OSI NS) 4.1 Rationale for considering the OSI NS The evolution and realization of the bearer services and teleservices in the ISDN environment and the recognized protocol base within the CCITT directs - as far as the network layer of the communication archichecture is concerned - to the use of the OSI NS. In order to lay the grounds for the integrity of the services under these conditions, the application rules for the network layer protocol (see Note) need to be defined correctly. Note - In the ISDN circuit-switched mode, support of the OSI NS is provided entirely by the B-channel X.25 packet layer proto- col, and is available once the ISDN call has been connected by other means. The provision of the OSI NS is for further study. 4.2 Architecture/available ISO Standards and CCITT Recom- mendations Because of the structure of the ISDN which makes use of proto- col stacks different for connection control and information transfer, the OSI NS may be provided in different ways. The approach using the network layer protocol in the B-channel is based in principle on - CCITT Recommendation X.213; - OSI 8208; - OSI 8878. The use of the D-channel (Recommendation Q.931) or the relevant protocols defined for future packet oriented information transfer modes (see Recommendation I.122) for the provision of the OSI NS is for further study. 4.3 Requirements for the OSI NS To balance the expenditure for the development of Telematic terminals under the consideration of the OSI NS, the requirements may be limited to the necessary minimum. This can be obtained by providing the capability of terminat- ing, in the case of an incoming call for both the circuit-switched (CS) and packet-switched (PS) cases, the layer 3 protocol to pro- vide the obligatory functions of the OSI NS only, and in at least a minimum way, in order to appear to the calling terminal to be an OSI terminal at layer 3. In the case of an outgoing call, calling terminals can initiate an OSI communication, as long as all the relevant facilities are supported, if necessary at any time. 4.3.1 Minimum requirements for the OSI NS Table 2/T.90 shows the list of the X.25 PLP optional user facilities which are proposed for the use in relation to the OSI NS in this Recommendation. H.T. [T4.90] TABLE 2/T.90 X.25 PLP optional user facilities __________________________________________________________________________________________________________________ { Optional user facility | ua) } { Used for support of an incoming call | ub) } { Used for support of an outgoing call } __________________________________________________________________________________________________________________ 13.13 | uc) Throughput call negotiation Yes Optional | ud) __________________________________________________________________________________________________________________ 13.16 | uc) Fast select Yes Optional | ud) __________________________________________________________________________________________________________________ 13.28 | uc) { Transit delay selection and indication (TDSAI) } Yes Optional | ud) __________________________________________________________________________________________________________________ 14.1 | uc) Calling address extension Yes Optional | ud) __________________________________________________________________________________________________________________ 14.2 | uc) Called address extension Yes Optional | ud) __________________________________________________________________________________________________________________ 14.3 | uc) { Minimum throughput class negotiation } Yes Optional | ud) __________________________________________________________________________________________________________________ 14.4 | uc) { End-to-end transit delay negotiation (EETDN) } Yes Optional | ud) __________________________________________________________________________________________________________________ 14.5 | uc) Expedited data negotiation Yes Optional | ud) __________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a) As the D-bit is always set to 0 in the circuit-mode case, the receipt confirmation selection requirement is satisfied for this case. b) To fulfill at least the minimum functionality of the OSI NS (clarification found if necessary in S 4.3.2). c) Refers to the relevant section in ISO 8208. d) May optionally be invoked for a Telematic communication. These must be supported if initiating a communication with an OSI termi- nal. Tableau 2/T.90 [T4.90], p. 4.3.2 Minimum functionality when receiving a call from a system using the OSI NS The following text represents a possible way to achieve the minimum functionality when receiving a call from a system using the OSI NS. (Refer to both ISO 8878 and ISO 8208.) 13.13 Throughput class negotiation : When replying to INCOMING CALL/CALL REQUEST, a throughput class facility request need not be made in the CALL ACCEPTED packet. If a throughput class facility request was not made in the CALL ACCEPTED packet, then this would mean that the throughput classes applying to the call would be those that have been indicated in the INCOMING CALL/CALL REQUEST packet. 13.16 Fast selection shall be supported for the full OSI NS (full 128 octets of NS-user data available). The receipt of a CALL REQUEST packet which does not have the value "02" in the first octet of the call user data field would be considered an error [connection rejection - reason unspecified (permanent con- dition)] by a Telematic terminal which only supports a minimum functionality (see Note). Receipt of a CALL REQUEST packet which does have the value "02" in the first octet of the call user data field indicates Telematic service operating according to Recommendation T.70 (layer 4 only). 13.28 Transit delay selection and indication (TDSAI): This must be accepted when received. However, if the reply to be coded in the "cumulative transit delay subfield" of the EETDN facility is "unknown" (i.e., FF hexadecimal) then the value in the TDSAI field could be ignored. 14.1 Calling address extension facility | This must be accepted when receiving a call. 14.2 Called address extension facility | This must be accepted when receiving a call. 14.3 Minimum throughput class negotiation | if a terminal reacts to the appearance of a throughput class facility request in the INCOMING CALL packet by not sending a throughput class facility request in the CALL ACCEPTED packet, then the minimum throughput class negotiation facility could be ignored. 14.4 End-to-end transit delay notification (EETDN) | When replying this could contain the value "unknown" (i.e., FF hexadecimal). 14.5 Expedited data negotiation | This is used to negotiate the non-use of expedited data (must be used in the CALL ACCEPTED packet). Note - The use of the value "02" in the ISDN circuit-switched mode is questioned, as there is already coding to indicate Telematic services in the HLC information element. 5 Additional X.25 optional user facilities In addition to the facilities mentioned in S 4 that should be supported by Telematic terminals in order to comply with the OSI NS, additional facilities/functionalities must be supported as a consequence of: - the use of Recommendation X.25 PLP for the pro- vision of the OSI NS (this protocol allows layer 3 multiplexing and flow control); - the provision of various Recommendation X.25 ori- ginated user facilities; - the provision of various service oriented user facilities by some networks (i.e., additional facilities) or by all networks (i.e., essential facilities) as defined by Recommendation X.2. There is no need for the provision of the additional service oriented user facilities in the circuit-switched case. The X.25 originated user facilities may be used in the circuit-switched case. 5.1 Categories of additional functionalities | (see Note) - X.25 originated user facilities 13.1 On-line facility registration 13.12 Flow control parameter negotiation - Service oriented user facilities (network based) 13.14 Closed user groups (CUG) selection 13.14 CUG with outgoing access selection 13.18 Reverse charging 13.21 Network user identification 13.22 Charging information 13.23 RPOA selection 13.26 Called line address modified notification 13.27 Call redirection notification Note - D-bit modification is not supported. 5.2 Functionalities - X.25 originated user facilities 1) On-line facility registration The use of this facility shall be restricted to the modifi- cation of the range of logical channels. For the default values, Telematic terminals support a single two-way logical channel (i.e., LTC=HTC=1, LIC=HIC=0, LOC=HOC=0). 2) Flow control parameter negotiation Packet size and window size parameters may be negotiated. They should use only default values: 2048 octets for the packet size, seven for the window size. When the parameter negotiation is indicated in an INCOMING CALL packet, they shall respond properly in the CALL ACCEPTED packet. Note - Since the maximum TPDU length is 2048 octets, and segmentation should also be avoided, the maximum default length of layers 3 and 2 should be larger than 2048 octets. - Service oriented user facilities (network based) 1) Closed user group selection (Essential in Recommendation X.2) and CUG with outgoing access selection (Addi- tional in Recommendation X.2) (13.14). These facilities may optionally be requested from Telematic terminals (i.e., outgoing call only). CUG information received in an INCOMING CALL packet may be ignored. 2) Reverse charging (13.18) This facility may be supported by some networks, and applied on a per call basis, the possibility of requesting reverse charging in outgoing calls is optional for Telematic terminals, but they must be able to properly handle and respond to the incoming call at the called side. (As a default, calls should be rejected.) 3) Network user identification (13.21) This facility may be applied by networks on a per call basis, following subscription made by prior arrangement for the agreed period of time. 4) Charging information (13.22) This facility may be provided by some networks on a per call basis, following subscription made by prior arrangement for the agreed period of time. The information may be handled or pro- cessed normally. As a minimum requirement, it may be ignored. 5) RPOA selection (13.23) This facility may be provided by some networks on a per call basis, following subscription made by prior arrangement for the agreed period of time. As a minimum requirement, it may be ignored. 6) Called line address modified notification (13.26) This facility may be provided by some networks on a per call basis, without any particular user request. This information may be processed normally. As a minimum requirement, it may be ignored. 7) Call redirection notification (13.27) This facility may be provided by some networks on a per call basis, without any particular user request. This information may be processed normally. As a minimum requirement, it may be ignored. 6 Interactions between the D-channel and B-channel Communication between the D-channel and B-channel is not syn- chronized in relation to each other by the ISDN and therefore information exchange via these channels can be accomplished independently and simultaneously. As a consequence of this, mes- sages sent in the D-channel and B-channel in a distinct relation- ship to each other may be received in a different order. In order to achieve an orderly operation of the protocols in all Telematic installations it is necessary to have an additional procedure satisfying the respective requirements. This model, architecture, and primitives of this additional procedure is left for further study. One possible approach is described in Appendix IV. 7 Supplementary services For application and description see Recommendations F.161, F.200, I.241 and I.25x Series (depending on the type of supplemen- tary service). 8 Terminal response time (For further study.) 9 Synchronization One of the characteristics of ISDN is that there is no end-to-end signalling about activation of the protocol instances. An instance of the data link protocol should only send its first frame when the peer entity is ready to receive it. To achieve this adequately, the following procedure shall be used. The sender and receiver follow the sequence: 1) Send "1"-bits until notified of B-channel estab- lishment. 2) Activate the receiver. 3) Send flags. 4) Wait until the first flag arrives from the peer. 5) Consider the peer as active and start communica- tion. The sequence diagram describing the operation of sender and receiver is shown in Figure 4/T.90. 10 Higher layer protocols The basic requirements of the Group 4 facsimile service are described in S 1.2.2 of Recommendation F.161. The basic require- ments of the Teletex service are described in S 1.2.2 of Recommendation F.200. 10.1 Transport layer The rules given in S 5.3.2 of Recommendation T.70 regarding transport protocol data unit (TPDU) block length are adopted in principle but with the additional provision that the negotiation mechanism is mandatory (e.g., for more efficient communication via satellite links). Figure 4/T.90, p. ANNEX A (to Recommendation T.90) Procedures for connection establishment, connection release and information transfer Procedures shown below are not the requirements to the termi- nals for Telematic services, but for reference only. A.1 B-channel circuit-switched mode a) Connection control phase Figure A-1/T.90, p. b) Information transfer phase Figure A-2/T.90, p. A.2 Packet-switched mode See relevant signal procedures described in Recommendation X.31. APPENDIX I (to Recommendation T.90) Consideration of incoming calls for facsimile terminals from networks without HLC provision I.1 In order to cater for the case where calls are incoming from networks not able to convey HLC information (e.g., PSTN, switched 64 kbit/s networks) it must be possible for a G4/G3 termi- nal to accept calls in some cases without the explicit provision of an HLC field. In this case, the directory (E.164) number must be the over-riding determinant of whether the terminal responds (pro- vided the BC matches). This may involve subscription to "multiple subscriber number" (MSN) supplementary service. I.2 The three distinct cases likely to occur are: i) incoming calls from PSTN; ii) incoming calls from switched 64 kbit/s network (not ISDN); iii) incoming calls from ISDN. It is recommended that the following criteria should be used by the terminal to determine whether, and in what mode it should answer the call: i) Incoming calls from PSTN In this case, the G3/G4 machine should answer the call in G3 mode (including modem and codec functions) if the following cri- teria are fulfilled: a) Called ISDN number (E.164) matches number allo- cated to terminal; b) BC = 3.1 kHz audio or speech; c) Call progress indicator (in Q.931 SETUP) = non-ISDN source; d) HLC = not present; e) Subaddress = not present. ii) Incoming call from switched 64 kbit/s network (not ISDN) In this case, the G3/G4 machine should answer the call in G4 mode (no modem or codec functions) if the following criteria are fulfilled: a) Called ISDN number matches number allocated to terminal; b) BC = 64 kbit/s; c) Call progress indicator = non-ISDN source; (Note ) - It may not always be possible to determine whether source is ISDN or 64 kbit/s switched); d) HLC = not present; e) Subaddress = not present. iii) Incoming call from ISDN In this case, the G3/G4 machine must answer the call in G4 mode if the following criteria are fulfilled: a) Called ISDN number matches number allocated to terminal; b) BC = 64 kbit/s; c) Call progress indicator [not valid]; d) HLC = G4 Teleservice; e) Subaddress = if present, this must match termi- nal subaddress. I.3 HLC to be used when polling or sending A G3/G4 terminal attempting a G4 call across the ISDN for either polling or sending will send HLC = G4 Fax. A G3/G4 terminal reattempting a call in G3 mode, following failure with appropriate cause in G4 mode, will establish a 3.1 kHz audio BS with no HLC. I.4 HLC to be used by terminal adaptor supporting G3 machines on ISDN a) Called ISDN number matches allocated to the ter- minal adaptor; b) BC = 3.1 kHz audio or speech; c) Call progress indicator = non-ISDN source (from PSTN) = [Not valid]; d) HLC = G3 Teleservice (from ISDN); e) Subaddress = if present this must match terminal subaddress. APPENDIX II (to Recommendation T.90) Optional usage of T.70 NL protocol II.1 Information transfer phase The T.70 NL option being used by calling DTE and supported by the called DTE. The network layer shall for the call control phase be as defined in S 2.2.4. The information transfer phase shall be imple- mented as defined in Recommendation T.70, S 3.3.3. Figure II-1/T.90, p. II.2 Information transfer phase The T.70 NL option being proposed by the calling DTE but not supported by the called DTE. Figure II-2/T.90, p. APPENDIX III (to Recommendation T.90) Service definitions and state transition diagrams for the data link layer within the B-channel (CS-mode) This Appendix contains the result of experience of several implementations of the prescribed link layer for telematic ser- vices. This description has been found to be useful in some Administrations for support of conformance testing. Additional work may be needed in the area of ISDN management and maintenance, however, no clear set of requirements is available at this time. The support of the management and maintenance work is left for further study. In addition, depending on the further work on the link layer, particularly related to the base modulus for I-frames, some editing may be required (e.g., SABM may become SABME). Note - Reference to the appropriate paragraph of T.70 or an additional explanation is needed. III.1 Service definitions III.1.1 Physical service used by HDLC Figure III-1/T.90, p. III.1.2 Data link service (HDLC) III.1.2.1 Data link connection establishment Figure III-2/T.90, p. Figure III-3/T.90, p. III.1.2.2 Data link transfer phase Figure III-4/T.90, p. III.1.2.3 Data link release Figure III-5/T.90, p. Figure III-6/T.90, p. III.1.2.4 Data link resetting Figure III-7/T.90, p. Figure III-8/T.90, p. Figure III-9/T.90, p. Figure III-10/T.90, p. III.2 State transition disgrams HDLC III.2.1 The relation between the diagrams The following diagrams describe the HDLC procedure as one functional unit. The first page comprises the whole protocol and the following pages give the details to specific states. III.2.2 Abbreviations ABM Asynchronous Balanced Mode ADM Asynchronous Disconnected Mode R:xxx Receive xxx (Command or Response) R:Cxxx Receive A Commmand R:Rxxx Receive A Response S:xxx send xxx F Final bit P Poll bit XXX Not this condition RC Redrive Counter RCB Redrive Counter Busy IC I-Frame counter Vs\du Variable for sequence updating III.3 Summary of frame definitions III.3.1 Invalid frames - frames not properly bounded by flags, - frames containing addresses other than A or B, - frames with Frame Check Sequence (FCS) error, - frames containing less than 32 bits between flags. III.3.2 Valid frames III.3.2.1 Not expected frames NEF, not expected frames (for the receiver) which lead to a frame reject condition (excluding frames with an FRMR control field). - a command or response control field that is undefined or not implemented, Type W - a frame with an information field which is not permitted or supersivory or unnumbered frame with incorrect length, Type X - an I-frame with an information field which exceeds the maximum established length, Type Y - a frame with an invalid N (R), Type Z III.3.2.2 Expected frames - frames which must lead to a reaction (in accor- dance to the Recommendation) on the receiving station, - frames which must be ignored only in determined states on the receiving station. Figure III.11/T.90, p. Figure III.12/T.90, p. Figure III.13/T.90, p. Figure III.14/T.90, p. Figure III.15/T.90, p. Figure III.16/T.90, p. APPENDIX IV (to Recommendation T.90) Possible model for telematic endsystems taking into account the D-channel/B-channel coordination function Figure IV-1/T.90 [T5.90] (a traiter comme tableau MEP), p. There are various ways of specifying the layer 3 covering the coordination function. In principle, the layer 3 can either be specified as a monolith or as a set of individual modules. The structuring into the three modules: - Layer 3 D-channel - Layer 3 B-channel and - Layer 3 D-/B-channel coordination. is obvious, as the first two modules are almost ready-made, avail- able thus leaving the coordination module to be specified from the functionality point of view. The implementation itself is in the responsibility of the manufacturer.