The drawings contained in this Recommendation have been done in Autocad
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 Service
	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
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 facsimile 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 information 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 § 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 communication between Telematic terminals, following the protocols described in this Recommendation, and terminals using optional protocols, is the responsibility of the user of such optional protocols.
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 § A.1 a).
	For additional information regarding the information transfer phase, see § A.1 b).

2.1	Protocol set
	The protocol set applicable to the circuit–switched mode (CS mode) is shown in Figure 1/T.90.

Physical
 connection control	 Virtual connection control 
and information transfer	
 Layer 3	 Q.931	 ISO 8208 
(Note 3)	
 Layer 2	 Q.921	 X.75 LAPB 
(modified) (Note 2)	
 Layer 1	 I.430/I.431 (Note 1)	
 <D–channel>	 <B–channel>	
 Note 1 – See § 2.2.1.
Note 2 – Full–duplex single link procedures are defined as described in § 2.2.3.1. For service definitions and state transition diagrams for the data link layer within the B–channel, see Appendix III.
Note 3 – DTE–DTE conection is specified on the basis of ISO 8208 (September, 1987) as described in § 2.2.5.
The T.70 NL protocol (CSPDN minimum header, T.70 § 3.3) may optionally be supported in addition to the X.25 PLP and used on a per–call–basis. For further information, see Appendix II.
FIGURE 1/T.90
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 interface, 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 following 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./T0803700-89 = 4 cm

2.2.3.2	Implementation rules
	In order to achieve full compatibility between different implementations, the rules below for the implementation of Recommendation X.75 shall be followed.
2.2.3.2.1	General rules
a)	The 1984 version (Red Book) of CCITT Recommendation X.75, § 2, shall be used as the reference specification.
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 transmissions 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)	§ 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 § 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)	§ 2.3.5.3
The DTE and the ISDN are not octet aligned and the last paragraph is therefore not valid.
e)	§ 2.3.5.5
Higher layers should be notified when timer T3 expires (excessive idle state).
f)	§ 2.4.3
Related to the first paragraph, read instead of “next response” “corresponding response”.
g)	§ 2.4.4.1
In the active channel state, the DTE shall transmit contiguous 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)	§ 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, § 2.4.4.5).
In the disconnected phase, it is the calling DTE which may initiate link set up.
i)	§ 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 condition).
j)	§ 2.4.5.9, fifth paragraph
If an RNR is received, the DTE shall not resume I–frame transmission or retransmission.
k)	§ 2.4.5.9, last paragraph
If the transmission attempt variable is equal to N2, the DTE shall enter the disconnected phase.
l)	§ 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)	§ 2.4.7.3, second paragraph
Only the DTE which caused the FRMR condition may try to reset the link.
n)	§ 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)	§ 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 r)].
A value is recommended between 2.5 and 7 seconds. Consideration of a specific value requires further study.
p)	§ 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)	§ 2.4.8.3, second paragraph
T3  60 seconds
T3  30 seconds
r)	§ 2.4.8.4
N2  60 seconds ÷ T1
s)	§ 2.4.8.5
N1 = 2112 + (n × 1024) bits;
n = 0 or 2 or 6 or 14.
t)	§ 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 × T1.
Note 2 – The acknowledgement strategy used by the receiving DTE should be independent of any knowledge about the value of k used by the sending DTE. This can be achieved by either acknowledging 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 p)].
Note 3 – Further study is needed on a mechanism for negotiation 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 service 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 element. 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 element. The HLC IE is used to carry information between the endsystems 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 restricted 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 elements 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:
–	§ 3.2: Differences in DTE/DTE and DTE/DCE operation
–	§ 3.3: Operating over circuit–switched connections
–	§ 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 circuits. See § 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 transport 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, terminals 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
	The use of this protocol identifier for Videotex is for further study.

TABLE 1/T.90
Use of HLC codes by various Telematic terminals
Telematic service
 terminals	 HLC codes		
	Sent from calling terminals 
(Notes 2, 3)	Accepted by receiving terminals
(Note 4)	
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 document 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.
2.2.6	Layer 3 – packet size (NPDU block length)
	The rules for packet size negotiation are given in § 15.2.2.1.1 of ISO 8208. The values for this Recommendation are restricted 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.

Access 
connection control	Virtual connection control 
and information transfer	
Layer 3	Q.931	X.25 PLP	
Layer 2	Q.921	X.75 LAPB	
Layer 1	I.430/I.431 (Note)	
<D–channel>	<B–channel>	
	Note – See § 2.2.1.
FIGURE 3/T.90
3.2	Application rules for B–channel packet–switched mode
3.2.1	Layer 1 – physical layer interface characteristics
	See § 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 service 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 restricted 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 d) through g) of the application rules specified in § 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 protocol, 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 Recommendations
	Because of the structure of the ISDN which makes use of protocol 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 terminating, in the case of an incoming call for both the circuit–switched (CS) and packet–switched (PS) cases, the layer 3 protocol to provide 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.
TABLE 2/T.90
X.25 PLP optional user facilities
Optional user facility a)	Used for support 
of an incoming 
call b)	Used for support
of an outgoing 
call	
 13.13 c)	 Throughput call negotiation	 Yes	 Optional d)	
 13.16 c)	 Fast select	 Yes	 Optional d)	
 13.28 c)	 Transit delay selection and indication (TDSAI)	 Yes	 Optional d)	
 14.1 c)	 Calling address extension	 Yes	 Optional d)	
 14.2 c)	 Called address extension	 Yes	 Optional d)	
 14.3 c)	 Minimum throughput class negotiation	 Yes	 Optional d)	
 14.4 c)	 End–to–end transit delay negotiation (EETDN)	 Yes	 Optional d)	
 14.5 c)	 Expedited data negotiation	 Yes	 Optional d)	
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 § 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 terminal.
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 condition)] 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 § 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 provision of the OSI NS (this protocol allows layer 3 multiplexing and flow control);
–	the provision of various Recommendation X.25 originated 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 modification 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 (Additional 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 processed 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 synchronized 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, messages sent in the D–channel and B–channel in a distinct relationship 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 supplementary 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 establishment.
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 communication.
	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 § 1.2.2 of Recommendation F.161. The basic requirements of the Teletex service are described in § 1.2.2 of Recommendation F.200.
10.1	Transport layer
	The rules given in § 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).

Fig. 4/T.90./T0803470-89 = 15 cm

ANNEX A
(to Recommendation T.90)
Procedures for connection establishment,
connection release and information transfer
	Procedures shown below are not the requirements to the terminals for Telematic services, but for reference only.
A.1	B–channel circuit–switched mode
a)	Connection control phase
Fig. A–1/T.90./T0803480-89 = 15 cm

b)	Information transfer phase
Fig. A–2/T.90./T0803490-89 = 15 cm

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 terminal 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 (provided 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 criteria are fulfilled:
a)	Called ISDN number (E.164) matches number allocated 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 terminal 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 terminal 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 § 2.2.4. The information transfer phase shall be implemented as defined in Recommendation T.70, § 3.3.3.
Fig. II–1/T.90./T0803500-89 = 6 cm

II.2	Information transfer phase
	The T.70 NL option being proposed by the calling DTE but not supported by the called DTE.
Fig. II–2/T.90./T0803510-89 = 7 cm

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 services. 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
Fig. III–1/T.90./T0803520-89 = 6 cm

III.1.2	Data link service (HDLC)
III.1.2.1	Data link connection establishment
Fig. III–2/T.90./T0803530-89 = 6 cm

Fig. III–3/T.90./T0803540-89 = 6 cm

III.1.2.2	Data link transfer phase
Fig. III–4/T.90./T0803550-89 = 6 cm

III.1.2.3	Data link release
Fig. III–5/T.90./T0803560-89 = 6 cm

Fig. III–6/T.90./T0803570-89 = 6 cm

III.1.2.4	Data link resetting
Fig. III–7/T.90./T0803580-89 = 6 cm

Fig. III–8/T.90./T0803590-89 = 6 cm

Fig. III–9/T.90./T0803600-89 = 6 cm

Fig. III–10/T.90./T0803610-89 = 6 cm

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
Vsu	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 accordance to the Recommendation) on the receiving station,
–	frames which must be ignored only in determined states on the receiving station.

Fig. III–11/T.90./T0803620-89 = 25 cm

Fig. III–12/T.90./T0803630-89 = 25 cm

Fig. III–13/T.90./T0803640-89 = 25 cm

Fig. III–14/T.90./T0803650-89 = 25 cm

Fig. III–15/T.90./T0803660-89 = 25 cm

Fig. III–16/T.90./T0803670-89 = 25 cm

APPENDIX IV
(to Recommendation T.90)
Possible model for telematic endsystems taking into account
the D–channel/B–channel coordination function

Layers 4 to 7	 Telematic protocols layers 4 to 7	
	 D–/B–channel coordination function	
Layer 3	Q.931	X.25 PLP 
plus
application rules	
Layer 2	Q.921	 X.75 LAPB 
plus
application rules	
Layer 1	 I.430/I.431	
 <D–channel>	 <B–channel>	
 Note – D–channel signalling functions of concern to the terminal–user–interface but not supported by the layer 4–7 services are to be handled separately from these services.
FIGURE IV–1/T.90
 Model for telematic endsystems taking into account the
D–channel/B–channel coordination function
	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, available thus leaving the coordination module to be specified from the functionality point of view. The implementation itself is in the responsibility of the manufacturer.