THE DRAWINGS CONTAINED IN THIS RECOMMENDATION HAVE BEEN DONE IN AUTOCAD.

Recommendation U.82

INTERNATIONAL TELEX STORE AND FORWARD -

INTERCONNECTION OF TELEX STORE AND FORWARD UNITS

(Malaga-Torremolinos, 1984)

The CCITT,

considering

(a)	the need for telex store and forward services;

(b)	the increasing need to transfer messages of different types and having a variety of formats;

(c)	that the Series F Recommendations define existing telex and new telematic services, that the Series S of Recommendations define control procedures for new telematic services;

(d)	that Recommendations X.60, X.61, X.70, X.71, X.75 and X.121 permit international connection between public data networks;

(e)	that the Series V Recommendations provide the means for data communication over the telephone network;

(f)	that the Series X Recommendations define message handling systems,

unanimously declares the following

1	Scope

1.1	This Recommendation defines the interworking procedures to facilitate the international exchange of messages between computer-based telex store and forward units.

1.2	This Recommendation is one of a series of Recommendations which define international telex store and forward services. These Recommendations are:

-	Recommendation F.72: International telex store and forward - general principles and operational aspects

-	Recommendation U.80: International telex store and forward - access from telex

-	Recommendation U.81: International telex store and forward - delivery to telex

-	Recommendation U.82: International telex store and forward - interconnection of telex store and forward units

1.3	Definitions

The following terms used in this Recommendation have the undermentioned definitions:

1.3.1	store and forward unit (SFU)

Computer equipment with associated storage that accepts messages from telex subscribers for subsequent delivery to specified telex address or addresses. Conversational mode operation is not provided.

1.3.2	network management boundary

The boundary within which the telex store and forward service is provided by one or more telex SFUs under the control of one Administration.

1.3.3	originating SFU

The telex SFU forwarding the telex message.

1.3.4	destination SFU

The telex SFU receiving the telex message.

1.3.5	inter-telex SFU messages (IM)

Messages transferred between telex SFUs to complete the function of message transfer.

1.3.6	message transfer unit (MXU)

The basic element of the inter-telex SFU message transfer procedure.

1.3.7	user message transfer unit (UMXU)

Used to carry the message submitted by a telex subscriber for delivery to a specified address.

1.3.8	service message transfer unit (SMXU)

Used to convey service information about messages.

1.3.9	text transfer (TT)

A type of UMXU used to transfer address information and the subscriber message.

1.3.10	status request (SRQ)

A type of SMXU used to request, from a destination telex SFU, the present status of the message.

1.3.11	status report (SRPT)

A type of SMXU used to report the status of a message and sent only in response to an SRQ.

1.3.12	delivery notification (DN)

A type of SMXU used to provide information on an address or addresses to which a message has been delivered.

1.3.13	non-delivery notification (NDN)

A type of SMXU used to provide information on an address or addresses to which the message has not been delivered.

1.3.14	combined delivery/non-delivery notification (CN)

A type of SMXU used to provide information on whether a message has been delivered or not delivered to a number of addresses.

1.3.15	header

The portion of the MXU which contains the information to service the control need of the calling telex SFU.

1.3.16	message block

The portion of the MXU which contains the information to be transferred between the telex SFUs.

2	Service outline

2.1	The telex SFU service allows a telex subscriber to deposit single or multi-address messages with a telex SFU for subsequent delivery to the specified address or addresses. (The services and facilities to be offered internationally are the subject of Recommendation F.72)

2.2	In the event of a failure to deliver to any address or addresses, a non-delivery notification is issued to the originating telex subscriber. The requirement to send a non-delivery notification is mandatory. Transmission

of non-delivery notifications may occur on a per address or per multi-address basis.

2.3	A delivery notification for successful delivery and/or subscriber initiated status enquiry information may also be issued.

3	International interconnection

3.1	The extension of telex SFU services beyond the management network boundary of an Administration requires co-operation between telex SFUs across international connections.

3.2	In the international interconnection of telex SFUs the responsibility to deliver single and multi-address messages is transferred from the originating Administration to one or a number of destination Administrations.

3.3	In the basic service, messages addressed to more than one destination telex SFU management network should be separated at the originating management network.

3.4	The possibility of forwarding messages via transit management networks is for further study.

3.5	In the international interconnection of telex SFUs it is necessary to return delivery/non-delivery status information to the originating telex

SFU. This information is compiled on a per address basis at the destination telex SFU either when the message has been delivered or when no further attempts to deliver will be made to that address.

3.6	The return of delivery and non-delivery information to the originating telex SFU may be on a per address or per message basis.

3.7	When information is issued on a per message basis the originating telex SFU may request interim message delivery status reports by transmitting message status requests.

3.8	Delivery and non-delivery information provided on a per message address basis requires explicit notification to the originating telex SFU.

3.9	Delivery and non-delivery information provided on a per message basis may require only explicit notification of non-deliveries and implicit notification of deliveries.

3.10	The method employed on an international connection between telex SFUs to transfer delivery/non-delivery status information should be the subject of bilateral agreement. Account must be taken of the means by which the interconnection is established and the possible effects on service.

3.11	The storage of messages during the specified period for messages (or addresses) requiring delayed delivery should generally be carried out by the originating telex SFU. In this case the delay indicator is omitted in the corresponding message to the destination telex SFU. When the delay action is not carried out in the originating telex SFU, the appropriate delay indicator should be retained.

4	Message transfer

4.1	International connection between telex SFUs may be achieved by use of the following:

a)	telex network;

b)	packet switched data networks (PSDN);

c)	circuit switched data networks (CSDN);

d)	public switched telephone network (PSTN);

e)	direct circuits (50 baud and medium speed).

4.2	The cooperation of two or more telex SFUs may be required to complete the function of a message transfer. Such cooperation between telex SFUs is achieved by use of an inter-telex SFU message transfer procedure.

4.3	The general structure of an inter-telex SFU message transfer procedure is described in Figure 1/U.82.

Figure 1/U.82 - CCITT 67920

5	Elements of inter-telex SFU message (IM) transfer procedure

5.1	The basic element of the IM transfer procedure is the message transfer unit (MXU). The MXU is classified as either a user MXU (UMXU) or service

MXU (SMXU) allowing easy identification of the function(s) for which cooperation is required.

5.2	UMXUs carry messages submitted by a telex customer for delivery to a specified address or addresses.

5.3	SMXUs do not contain telex customer messages but are used to convey service information about messages. SMXUs of two types have been identified:

a)	notification (delivery and/or non-delivery)

b)	status (enquiry/report)

Use of other SMXU types is for further study.

5.4	Notification SMXUs are issued automatically by the telex SFU. Status SMXUs are generated by the telex SFU as a result of a customer request or in response to a received status SMXU.

5.5	There are 6 types of MXU used to provide a telex SFU interworking capability.

5.5.1	Text transfer (TT)

TT is used to transfer address information and the message as a UMXU.

5.5.2	Status request (SRQ)

SRQ is an SMXU and is used to request from a destination telex SFU the present status of message delivery to:

a)	all addresses

b)	those addresses to which the message has not been delivered

c)	specified addresses.

5.5.3	Status report (SRPT)

SRPT is an SMXU and is only used in response to an SRQ.

5.5.4	Delivery notification (DN)

DN is an SMXU and is used to provide information on an address or addresses to which the message has been delivered.

5.5.5	Non-delivery notification (NDN)

NDN is an SMXU and is used to provide information on an address or addresses to which the message has not been delivered.

5.5.6	Combined delivery/non-delivery notification (CN)

An SMXU used to provide information on whether a message has or has not been delivered to a number of addresses.

5.6	The originating and destination telex SFUs transmit MXUs in accordance with Figure 2/U.82.

Generated by

Originating SFU

Destination SFU

UMXU - TT

SMXU - DN

SMXU - NDN

SMXU - CN

SMXU - SRQ

SMXU - SRPT

FIGURE 2/U.82

Generation of MUXs

6	Methods of interworking

6.1	Administrations may provide telex SFU interworking service by any of three methods. These methods are shown diagrammatically in Figure 3/U.82.

The method of interworking should be agreed bilaterally between Administrations.

The following paragraphs describe operational procedures and are included for explanatory purposes.

Figure 3/U.82 - CCITT 76250

6.1.1	Method 1

6.1.1.1	TT is issued by the originating unit.

6.1.1.2	When the destination unit has completed call processing, CN is returned to the originating unit.

6.1.1.3	It may only be necessary to transmit NDN instead of CN since deliveries are implicit (see S 3.9).

6.1.1.4	No SRQ or SRPT MXUs are issued.

6.1.2	Method 2

6.1.2.1	TT is issued by the originating unit.

6.1.2.2	NDN and DN MXUs are issued by the destination unit on a per address basis at the time the destination unit has completed processing for that address.

6.1.2.3	No SRQ or SRPT MXUs are issued.

6.1.3	Method 3

6.1.3.1	TT is issued by the originating unit.

6.1.3.2	SRQ MXUs are issued by the originating unit at the time of a customer demand.

6.1.3.3	SRPT MXUs are issued by the destination unit in response to SRQ MXUs.

6.1.3.4	When the destination unit has completed call processing CN is returned to the originating unit.

6.1.3.5	It may only be necessary to transmit NDN instead of CN since deliveries are implicit (see S 3.9).

6.1.4	The preferred operation is method 3. The generation of UMXU-TT, SMXU-CN, SMXU-SRQ and SMXU-SRPT is considered mandatory. The generation of SMXU-DN and SMXU-NDN is optional.

7	Message transfer unit (MXU) formation

7.1	An MXU is composed of a header and a message block.

7.1.1	Header

7.1.1.1	The header refers to the portion of an MXU which contains information to serve the control need of the calling telex SFU.

7.1.1.2	For an UMXU the header is constructed by the originating telex SFU at the time a customer telex message is deposited with that unit, while in the case of an SMXU the header is created when the service message is generated.

7.1.1.3	Changing, adding to, or deleting from header information during the passage of an MXU through the telex SFU is for further study.

7.1.2	Message block

7.1.2.1	The message block contains that information that is to be transferred between telex SFUs and which is the reason the MXU has been generated.

7.1.2.2	The message block in an UMXU contains the text which is the customer message to be transferred from the originating telex subscriber to the specified address or addresses.

7.1.2.3	The customer message is inserted in the message block of an UMXU when a message deposited in a telex SFU is to be transmitted via another telex SFU. The message block is passed through the telex SFU and subsequent telex SFU(s) transparently.

7.1.2.4	The message block of an SMXU contains the service information which is inserted when the service message is generated. This information may or may not be passed transparently through the telex SFU to the message originating customer. The exact use of this information is a national matter and is outside the scope of this Recommendation.

7.1.2.5	Service information required for insertion into the message block of a notification SMXU is stored at the telex SFU and is continually updated until it is automatically released to the originating telex SFU.

7.1.2.6	The information stored at the telex SFU may also be released in its interim form to the originating telex SFU as a status report SMXU.

7.1.2.7	The status report SMXU is an interim version of the resultant notification SMXU.

8	Message transfer unit (MXU) structure

8.1	MXUs may be of two classes: UMXU or SMXU.

8.1.1	SMXUs of two types have been identified:

a)	notification (delivery and/or non-delivery)

b)	status (enquiry/report)

8.2	User MXU

Text transfer

Header:	MXU type identifier

Message identity

Destination telex SFU identity

Message code indicator

Delivery address	ü

Expected answerback	ý	Notes 1 and 4

Attention information	÷

Delay indication

Message block:	Subscriber text

8.3	Service MXU

a)	delivery notification

Header:	MXU type identifier

Message identity (originator)

Destination telex SFU identity

Message code indicator

Transit identities, (Note 2)

Message block:	Status	ü

Called address	÷

Received answerback	ý	Note 1

Date/time of last attempt	÷

(delivery date/time)	÷

Chargeable duration

b)	non-delivery notification

Header:	MXU type identifier

Message identity (originator)

Destination telex identity

Message code indicator

Transit identities (Note 2)

Message block:	Status	ü

Called address	÷

Answerback, if received	ý	Note 1

Date/time of last attempt	÷

Reason

c)	combined delivery/non-delivery notification

Header:	MXU type identifier

Message identity (originator)

Destination telex SFU identity

Message code indicator

Transit identities (Note 2)

Message block:	Status

Called address	ü

Answerback, if received	÷

Date/time of last attempt	ý	Notes 1 and 3

Reason	÷

Chargeable duration

d)	status request

Header:	MXU type identifier

Message identity (originator)

Destination telex SFU identity

Message code indicator

Message block:	either	i)	request status report on all message addresses associated with message

or	ii)	request status report on addresses to which message has not been delivered

or	iii)	request status report on specified address(es) (Note 5)

e)	status report

Header:	MXU type identifier

Message identity (originator)

Destination telex SFU identity

Message code indicator

Transit identities (Note 2)

Message block:	Status	ü

Called address	÷

Answerback, if received	÷

Date/time of last attempt	ý	Note 1

Reason	÷

Chargeable duration

Note 1 - This information may be repeated on a per address basis.

Note 2 - The use of transit identities is for further study.

Note 3 - Reason and chargeable duration are mutually exclusive.

Note 4 - In the absence of any field, the field should be indicated by an end of field delimiter. See Annex A and Appendix I.

Note 5 - This message block contains the specified delivery addresses.

8.4	Table 1/U.82 summarizes the MXU structure.

TABLE 1/U.82

Message transfer unit structure

Type

UMXU

SMXU

Text transfer (TT)

Delivery notification (DN)

Non-delive

ry notification (NDN)

Combined delivery/ non-delivery notification (CN)

Status request (SRQ)

Status report (SRPT)

Type identity

Type identity

Type identity

Type identity

Type identity

Type identity

Message identity (Note 1)

Message identity (Note 1)

Message identity (Note 1)

Message identity (Note 1)

Message identity (Note 1)

Message identity (Note 1)

Destinatio n SFU identity (Note 6)

Destinatio

n SFU identity (Note 6)

Destinatio

n SFU identity (Note 6)

Destinatio

n SFU identity (Note 6)

Destinatio

n SFU identity (Note 6)

Destinatio

n SFU identity (Note 6)

Message code indicator

Message code indicator

Message code indicator

Message code indicator

Message code indicator

Message code indicator

Header

Transit identities

Transit identities

Transit identities

.

Transit identities

Delivery address (Note 2)

.

Expected answerback (Notes 2, 7)

.

Attention informatio

n (Notes 2, 7)

.

Delay indication (Notes 2, 7)

TABLE 1/U.82 (continued)

Type

UMXU

SMXU

Text transfer (TT)

Delivery notification (DN)

Non-delive

ry notification (NDN)

Combined delivery/ non-delivery notification (CN)

Status request (SRQ)

Status report (SRPT)

Status

Status

Status

Status

Called address

Called address

Called address

Called address

Received answerback

Answerback if received

Answerback if received

Answerback if received

Message block (Note 5)

Subscriber text

Date and time Last attempt

Date and time Last attempt

Date and time Last attempt

Date and time Last attempt

Reason .

Reason (Note 3)

Reason (Note 3)

Chargeable duration (Note 3)

Chargeable duration (Note 3)

Chargeable duration (Note 3)

Request type

Specified address (Notes 2, 4)

Note 1 - Message identity contains originating country reference; originating SFU reference; message serial number; date/time. These items may be repeated on a per address basis.

Note 2 - These items may be repeated on a per address basis.

Note 3 - Reason and chargeable duration are mutually exclusive.

Note 4 - This field is only present when it is necessary to specify delivery address.

Note 5 - Message block fields in notification and status report SMXUs are repeated on a per address basis.

Note 6 - The destination telex SFU identity is the identity of the unit to which the responsibility to deliver is, or has been, devolved. This will be the called or calling telex SFU identity depending on the type of message transfer.

Note 7 - These fields are optional.

9	MXU information fields

9.1	Type Identity

Types of MXU are identified by a type code of two numeric characters. The first character identifies the type and the second the function as described in Table 2/U.82. The identification of further types of MXU is for further study.

TABLE 2/U.82

MXU type identity

Type

MXU description

Function

Type identity

1st digit

2nd digit

0

User message transfer

Text transfer

0

1

Delivery

1

1

1

Notification

Non-delivery

1

2

Combined delivery/non-del ivery

1

3

2

Status

Request

2

1

Report

2

2

Note - 1st digit is the first digit to be transmitted.

9.2	Message identity

9.2.1	The message identity should consist of four fields as shown in Table 3/U.82.

TABLE 3/U.82

Field

Content

Originating country reference

F.69 country code

Originating telex SFU reference

4-character numeric code

Message serial number

Serial number issued to the subscriber in the format specified in Recommendation U.80

Date and time

Date and time of message submission issued to the customer in the format specified in Recommendation U.80

9.3	Destination telex SFU identity

9.3.1	The destination telex SFU identity should consist of two fields as shown in Table 4/U.82:

TABLE 4/U.82

Field

Content

Destination country reference

F.69 country code

Destination telex SFU identity

4-character numeric code

9.4	Delivery address(es), expected answerback(s), attention information, and delay indication

9.4.1	The delivery address(es), expected answerback(s), attention information, and delay indication should be in the format specified in Recommendation U.80. Expected answerback, attention information and delay indication are optional fields.

9.5	Message code indicator

9.5.1	This field indicates the format in which the message text is transmitted.

The message code is indicated by a single numeric character; the following values have been assigned:

International Telegraph Alphabet No. 2 (ITA2)	0

International Alphabet No. 5 (IA5)	1

Recommendation S.61 (Teletex)	2

Additional values of message code are for further study.

9.6	Delivery information

9.6.1	The delivery information should conform to the format and content specified in Recommendation U.81.

9.7	Non-delivery notification

9.7.1	The non-delivery information should conform to the format and content specified in Recommendation U.81.

9.8	Combined delivery and non-delivery information

9.8.1	The combined delivery and non-delivery information should conform to the format and content specified in Recommendation U.81.

9.9	Status request information

9.9.1	The status request information should conform to the content and format specified in Recommendation U.80.

9.10	status report information

9.10.1	The status report information should conform to the content and format specified in Recommendation U.81.

9.11	Status

9.11.1	The status field should indicate whether or not the message has been delivered to a specified address.

The status is indicated by a single numeric character; the following values have been assigned:

Delivered	0

Non-delivery	1

Additional values of status are for further study.

9.12	Request type

9.12.1	The request type indicates whether a status request is required for all addresses, those to which the message has not been delivered or for those specified addresses included in the SRQ message block. See S 8.3 d).

The following values have been assigned:

Request on all addresses	0

Request non-delivery reports only	1

Request report on specified address(es)	2

9.13	Transit identities

9.13.1	The transit identity field is reserved for future use and may be required for administrative purposes.

The content and format of the field is for further study.

10	Principles of procedures and coding of inter-telex SFU messages

10.1	Use of the telex network

10.1.1	The principles for message transfers are illustrated graphically in Figures 4/U.82 to 8/U.82.

10.1.2	Call set-up should use normal telex call procedures.

10.1.3	Operation will normally be half duplex. Exceptionally, responses to MXU headers may be transmitted whilst operating in full duplex mode. The capability to operate full duplex is subject to bilateral agreement.

10.1.4	Inter-telex SFU messages should be distinguished from telex subscriber access messages by an interworking service request identifier (IRQ) which will be acknowledged by a service acknowledgement signal (IACK).

10.1.5	For link control purposes a preamble should precede the message header. This should consist of a character sequence as a block identity, a 3 alpha character circuit identity and a 3 numeric character serial reference.

10.1.6	The numeric character serial reference should increment sequentially and cyclically for each block transferred. No action is required by an SFU when the numbers received are not sequential, but this may be used nationally by Administrations to indicate possible fault conditions.

10.1.7	An end of message signal should be sent by the originating telex SFU which should be acknowledged by a message block acknowledgement signal from the destination telex SFU. The acknowledgement signal should be a character sequence similar to the preamble detailed in S 10.1.5 indicating the circuit on which the message was originally transmitted and the serial reference.

10.1.8	If the originating telex SFU does not receive both acknowledgement signals the original whole message (header and text) should be retransmitted.

10.1.9	Follow-on messages should be indicated by the receipt of a new message header. See Figure 6/U.82.

10.1.10	It should be possible for either telex SFU to interrupt an incoming transmission by using an interrupt transmission signal.

10.1.11	After the reception of the last block acknowledgement, an end of transmission signal should be transmitted by the originating unit before normal telex clearing procedures.

10.1.12	When the receiving telex SFU cannot offer the interworking service or when the telex SFU cannot accept message text transfers, because of storage limitations or failure conditions, the service signal NC followed by a clear signal should be transmitted.

10.1.13	When service signals are to be transmitted by the destination telex SFU to an originating SFU that is itself transmitting, the destination SFU

shall transmit an interrupt transmission signal (see Table 5/U.82) until received transmission ceases. This shall be subject to an overall timeout of 20 seconds. The service signal shall then be transmitted following transmission of a mark signal for 3 seconds.

10.1.14	All information should be coded in accordance with ITA2.

10.1.15	The action to be taken in the event of abnormal conditions during the message transfer stage should be the subject of bilateral agreement. Standardization of this action is for further study.

10.1.16	Table 5/U.82 shows the coding for interworking signals.

10.1.17	The field delimiter for all fields in an MXU should be combination No. 26 (+). This should be preceded by combination No. 30 (F/S) when necessary. The delimiters within the fields specified in S 9.4 should be in accordance with Recommendation U.80.

10.1.18	Examples of field coding and content of MXUs when using the telex network are shown in Appendix I.

Figure 4/U.82 - ccitt 76260

Figure 5/U.82 - CCITT 72890

Figure 6/U.82 - CCITT 72900

Figure 7/U.82 - CCITT 72910

Figure 8/U.82 - CCITT 72920

TABLE 5/U.82

Interworking signals

Description

Coding ITA2

IRQ

Combination No. 29; combination No. 26; combination No. 3;

combination No. 19; combination No. 6 (ZCSF)

IACK

Combination No. 29 followed by combination No. 9, combination No. 7, combination No. 1 (IGA)

Block identity

Combination No. 26; combination No. 3; combination No. 13;

combination No. 19 (ZCMS)

Circuit identity

3 alpha characters

Serial reference

3 numeric characters

End of message block

4 combinations No. 14 (NNNN)

Block acknowledgement

Combination No. 26; combination No. 3; combination No. 1;

combination No. 11 (ZCAK). See S 10.1.6

End of transmission

4 combinations No. 26 (ZZZZ)

Interrupt transmission

Continuous combinations No. 20 until received transmission ceases (TTTTTT...)

10.2	Use of direct circuits for asynchronous transmission

10.2.1	The direct circuit should be used in a half duplex mode to allow for acknowledgements of the information transmitted. The data transmission rate to be used on the international circuit should be agreed bilaterally.

10.2.2	The procedures and coding when using direct circuits for interconnection between telex SFUs should be identical to those in the case of use of the telex network but without the call set-up and call clearing phases. Thus, the procedures commence with the transmission of the IRQ signal.

10.2.3	The characters may be coded in either ITA2 or IA5. The coding should be fixed on a direct circuit basis and the code used should be agreed bilaterally.

10.2.4	Where circuits are used in a bothway mode the telex call collision procedures should be agreed bilaterally.

10.2.5	Call collision should be detected by checking the response to the service request signal (IRQ). In cases where the response is a service request signal from the other unit a call collision situation is indicated.

10.2.6	On circuits used for bothway transmission bilateral agreement will be required to determine usage in each direction to minimize the occurrence of call collisions.

10.2.7	Examples of field coding and content of MXUs when using asynchronous circuits are shown in Appendix I.

10.3	Use of public switched data networks

10.3.1	Asynchronous circuit switched data networks

10.3.1.1	These procedures apply to data networks operating for Recommendation X.1 user classes of service 1 and 2. The data transmission rate to be used should be agreed bilaterally.

10.3.1.2	Call connections between telex SFUs should be established in accordance with Recommendation X.70.

10.3.1.3	Telex SFU addresses used to establish the connection should conform to Recommendation X.121.

10.3.1.4	Calling and called line identifications may be requested to verify correct connection.

10.3.1.5	Following establishment of a connection between telex SFUs, MXUs should be transferred in accordance with the procedures described in S 10.1 for the telex network.

10.3.1.6	Coding should be in IA5 or ITA2 or the character set defined in Recommendation S.61 with the message code indicator set accordingly. The coding used on a connection between any 2 telex SFUs should be agreed bilaterally and should not be negotiable on a per call basis.

10.3.1.7	Access to the interworking service may be restricted by means of closed user group characters.

10.3.1.8	Character conversion between ITA2 and IA5 should be carried out by each telex SFU in accordance with Recommendation S.18 and between ITA2 and Recommendation S.61 in accordance with Recommendation S.60.

10.3.1.9	Administrations may, following call set-up, operate in accordance with S 10.3.2. This method of operating is a matter for further study.

10.3.2	Synchronous data networks

10.3.2.1	The procedures described in this section apply to calls established between telex SFUs over data networks operating for Recommendation X.1 user classes 3 to 11. The data transmission rate to be used on the international circuit should be agreed bilaterally.

10.3.2.2	The procedures may also apply to user classes 1 and 2 after call set-up (see S 10.3.1).

10.3.2.3	The call set-up and transport procedures should be generally in accordance with Recommendation S.70 with the following qualifications:

i)	the network layer should be Recommendation X.75 for PSDNs and Recommendation X.71 for CSDNs;

ii)	a special class of traffic signal may be used on CSDNs;

iii)	a special traffic class indication may be used on PSDNs.

10.3.2.4	Control procedures for the transfer of messages between telex SFUs should be based on Recommendation S.62, CCITT Yellow Book, 1980.

10.3.2.5	The preferred operation for the basic telex SFU interconnection should be the TWA session mode. The TWA mode is preferable when status reports are requested from the distant telex SFU. The use of the OWC session mode may also be used and should be the subject of bilateral agreement.

10.3.2.6	Telex SFUs may also operate in a TWS session mode in order to increase the speed of interchange when messages are required in both directions. The principle of operating in the TWS session mode should be agreed bilaterally.

10.3.2.7	The MXU should be transferred in session and document elements of procedure.

10.3.2.8	The UMXU should be transferred as a control document containing the header, including delivery address(es), expected answerback, attention information and delay indication, in the control text together with an associated normal document containing the message block.

10.3.2.9	The UMXU document structure is shown in Figure 9/U.82.

10.3.2.10	The absence of the document identifier shall indicate the normal document.

10.3.2.11	The UMXU control document shall be transmitted first followed immediately by the normal document.

10.3.2.12	The SMXU should be transferred as a control document.

10.3.2.13	The SMXU structure is shown in Figure 10/U.82.

10.3.2.14	Any number of control and normal documents may be transferred during a session. Figure 11/U.82 shows an example of a document transfer session.

Figure 9/U.82 - CCITT Pas de numéro de référence

Figure 10/U.82 - CCITT Pas de numéro de référence

Figure 11/U.82 - CCITT Pas de numéro de référence

10.3.2.15	Page boundaries may be transmitted by the originating SFU in a text transfer MXU in the message block. These check points will be recognized by the destination SFU for error recovery purposes and may also be included in the message output to the telex subscriber by the insertion of 10 line feeds (ITA2 combination No. 28).

10.3.2.16	When the message block text has no page boundary, error recovery procedures may be based on Annex G of Recommendation S.62.

10.3.2.17	Any one MXU should normally be transferred during a single session. If a session is interrupted it may be possible to continue the transfer using CDC after setting up a new session.

10.3.2.18	The basic telex SFU interworking connection should only use those PGIs and PIs defined as mandatory in Tables 9/S.62 and 10/S.62.

10.3.2.19	The use of other PGIs and PIs defined in Recommendation S.62 is for further study.

10.3.2.20	Delivery address, expected answerback and attention information should be transferred in a control document immediately following establishment of document level procedures.

10.3.2.21	MXU message blocks should be transferred in normal and control documents as a sequence of characters coded as defined by the message code indicator. Examples of the control text in the control document are shown in Annex A.

10.3.2.22	The control document content may serve two purposes:

a)	to provide management information that may be used for accounting, statistics, etc.

b)	to provide subscriber information.

To achieve b) the information should be in a format suitable for forwarding directly to the customer.

10.3.2.23	The use of the control document to provide subscriber information is a national matter.

10.3.2.24	The parameter values should be coded in accordance with the rules defined in Recommendation S.62. Thus, sequences of graphic characters will be coded using the character repertoire defined in Recommendation S.61.

10.3.2.25	The assignment of coding to the various parameter values relevant to the mandatory PGIs and PIs defined in Recommendation S.62 is shown below:

10.3.2.25.1	Terminal identifier of the called terminal

A sequence of graphic characters as defined in Recommendation U.81.

10.3.2.25.2	Terminal identifier of the calling terminal

A sequence of graphic characters as defined in Recommendation U.81.

10.3.2.25.3	Date and time

A sequence of graphic characters in the format defined in Recommendation U.81. The values should indicate the time of transmission of the relevant command except for command document continue (CDC) where the date and time will be those in the command document start (CDS) of the first attempt to transmit the document.

10.3.2.25.4	Service identifier

Bit 3 of the first octet should be set to 1 with all other bits set to 0 to indicate the telex SFU interworking service.

All other codings are for further study.

10.3.2.25.5	All other mandatory parameters

In accordance with Recommendation S.62.

10.3.2.26	Assignment of coding for the identifiers contained in the control text of the control document is as follows:

10.3.2.26.1	MXU type identity

This parameter is a binary coded field of fixed length of one octet identifying the MXU type as given in Table 6/U.82.

The hexadecimal representation of these octets is in accordance with Table 2/U.82.

All other binary values are reserved for future standardization.

TABLE 6/U.82

MXU type

Bit: 8 7 6 5 4 3 2 1

Text transfer (TT)

Bit: 0 0 0 0 0 0 0 1

Delivery notification (DN)

Bit: 0 0 0 1 0 0 0 1

Non-delivery notification (NDN)

Bit: 0 0 0 1 0 0 1 0

Combined delivery/non-delivery notification (CN)

Bit: 0 0 0 1 0 0 1 1

Status request (SRQ)

Bit: 0 0 1 0 0 0 0 1

Status report (SRPT)

Bit: 0 0 1 0 0 0 1 0

10.3.2.26.2	Message identity

A sequence of graphic characters as defined in S 8.

10.3.2.26.3	Destination telex SFU identity

A sequence of graphic characters as defined in S 8.

10.3.2.26.4	Transit identities

The use of this parameter is for further study.

10.3.2.26.5	Message code indicator

A binary encoded field of fixed length of one octet as in Table 7/U.82.

All other binary values are reserved for future standardization.

TABLE 7/U.82

Bit: 8 7 6 5 4 3 2 1

ITA No. 2

Bit: 0 0 0 0 0 0 0 0

IA No. 5

Bit: 0 0 0 0 0 0 0 1

S.61

Bit: 0 0 0 0 0 0 1 0

10.3.2.27	Service Interworking Identifier

10.3.2.27.1	Coding of the interworking identifier is for further study.

10.3.2.28	A formal definition of telex SFU MXUs and the field coding is shown in Annex A.

10.4	Use of the public switched telephone network

10.4.1	Connection between SFUs should be automatically established using normal telephone procedures.

10.4.2	Following call establishment the procedures should be as defined in S 10.3 for PSDNs but using the data transfer phase of Recommendation X.25.

10.4.3	The normal mode of operation should be full duplex at 2400 bit/s using LAPX or level 2 of Recommendation X.75.

10.4.4	Exceptionally Administrations may agree bilaterally to operate using half duplex and/or at speeds other than 2400 bit/s.

10.5	Use of medium speed direct synchronous circuit

10.5.1	The procedures should be as defined in S 10.3.2 for PSDNs but using the call set-up phase.

10.5.2	The normal mode of operation should be full duplex using LAPX or level 2 of Recommendation X.75.

10.5.3	Links between telex SFUs can be used for multiple session and bothway working by means of a number of logical channels.