4.3.2.1	Interrupt user data field
	Octet 4 and any following octets contain the interrupt user data. This field contains from 1 to 32 octets.
	Note – Some networks require the interrupt user data field to contain an integral number of octets (see § 3 Note).
4.3.3	Interrupt confirmation packet
	Figure 12/X.75 illustrates the format of the interrupt confirmation packet.
		Bits								
		8	7	6	5	4	3	2	1	
	1	General format identifier (see Note)				Logical channel group number				
Octets	2	Logical channel number								
	3	Packet type identifier								
		0	0	1	0	0	1	1	1	
Note – Coded 0001 (modulo 8) or 0010 (modulo 128).
FIGURE 12/X.75
Interrupt confirmation packet format
4.4	Flow control and reset packets
4.4.1	Receive ready (RR) packet
	Figures 13/X.75 and 14/X.75 illustrate the format of receive ready packets in the case of modulo 8 and modulo 128 respectively.
		Bits								
		8	7	6	5	4	3	2	1	
	1	General format identifier 				Logical channel group number				
		0	0	0	1					
Octets	2	Logical channel number								
	3	P(R)			Packet type identifier					
					0	0	0	0	1	
FIGURE 13/X.75
RR packet format (modulo 8)

		Bits								
		8	7	6	5	4	3	2	1	
	1	General format identifier 				Logical channel group number				
Octets	2	Logical channel number								
	3	Packet type identifier								
		0	0	0	0	0	0	0	1	
	4	P(R)							0	
FIGURE 14/X.75
RNR packet format (modulo 128)
4.4.1.1	Packet receive sequence number
	In Figure 13/X.75, bits 8, 7 and 6 of octet 3 are used for indicating the packet receive sequence number P(R). P(R) is binary coded and bit 6 is the low order bit. In Figure 14/X.75, bits 2 through 8 of octet 4 are used for the packet receive sequence number and bit 2 is the low order bit.
4.4.2	Receive not ready (RNR) packet
	Figures 15/X.75 and 16/X.75 illustrate the format of receive not ready packets in the case of modulo 8 and modulo 128 respectively.
		Bits								
		8	7	6	5	4	3	2	1	
	1	General format identifier 				Logical channel group number				
		0	0	0	1					
Octets	2	Logical channel number								
	3				Packet type identifier					
		P(R)			0	0	1	0	1	
FIGURE 15/X.75
RNR packet format (modulo 8)

		Bits								
		8	7	6	5	4	3	2	1	
	1	General format identifier 				Logical channel group number				
		0	0	1	0					
Octets	2	Logical channel number								
	3	Packet type identifier								
		0	0	0	0	0	1	0	1	
	4	P(R)							0	
FIGURE 16/X.75
RNR packet format (modulo 128)
4.4.2.1	Packet receive sequence number
	In Figure 15/X.75, bits 8, 7 and 6 of octet 3 are used for indicating the packet receive sequence number P(R). P(R) is binary coded and bit 6 is the low order bit. In Figure 16/X.75, bits 2 through 8 of octet 4 are used for the packet receive sequence number and bit 2 is the low order bit.
4.4.3	Reset request packet
	Figure 17/X.75 illustrates the format of the reset request packet.
		Bits								
		8	7	6	5	4	3	2	1	
	1	General format identifier (see Note)				Logical channel group number				
Octets	2	Logical channel number								
	3	Packet type identifier								
		0	0	0	1	1	0	1	1	
	4	Resetting cause								
	5	Diagnostic code								
Note – Coded 0001 (modulo 8) or 0010 (modulo 128).
FIGURE 17/X.75
Reset request packet format

4.4.3.1	Resetting cause field
	Octet 4 is the resetting cause field and contains the reason for the reset.
	The coding of the resetting cause field in a reset request packet is given in Table 15/X.75.
	An STE receiving a resetting cause other than that given in Table 15/X.75 will either pass this cause unchanged or change the cause to “Network congestion”.
TABLE 15/X.75
Coding of resetting cause field in reset request packet
	Octet 4
Bits								
Resetting cause	8	7	6	5	4	3	2	1	
 DTE originated	 0	 0	 0	 0	 0	 0	 0	 0	
 DTE originated (see Note 1)	 1	 X	 X	 X	 X	 X	 X	 X	
 Out of order (see Note 2)	 0	 0	 0	 0	 0	 0	 0	 1	
 Remote procedure error	 0	 0	 0	 0	 0	 0	 1	 1	
 Network congestion	 0	 0	 0	 0	 0	 1	 1	 1	
 Remote DTE operational (see Note 2)	 0	 0	 0	 0	 1	 0	 0	 1	
 Network operational (see Note 3)	 0	 0	 0	 0	 1	 1	 1	 1	
 Incompatible destination	 0	 0	 0	 1	 0	 0	 0	 1	
 Network out of order (see Note 2)	 0	 0	 0	 1	 1	 1	 0	 1	
 Note 1 – When bit 8 is set to 1, the bits represented by Xs are those indicated by the remote DTE in the resetting cause field (virtual calls and permanent virtual circuits) or the restarting cause field (permanent virtual circuits) of the X.25 reset or restart request packets.
Note 2 – Applicable to permanent virtual circuits only.
Note 3 – If the STE receives a reset request packet with the cause “Network operational”, it does not necessarily mean that the permanent virtual circuit is operational.
4.4.3.2	Diagnostic code field
	Octet 5 is the diagnostic code field and may contain additional information on the reason for the reset.
	If the associated resetting cause field (octet 4) indicates any valid cause (see Table 15/X.75) except “Network congestion”, the contents of this field will be passed unchanged. If the resetting cause field indicates “Network congestion” and the original reset or restarting request was generates as the result of an event detected other than at the local STE–X/Y interface, then the value of the diagnostic code passed will be as shown in Table 16/X.75.
	The diagnostic codes in reset request packets generated as the result of events detected at the local STE–X/Y interface are listed in Annex E.
4.4.4	Reset confirmation packet
	Figure 18/X.75 illustrates the format of the reset confirmation packet.
4.5	Restart packets
4.5.1	Restart request packet
	Figure 19/X.75 illustrates the format of the restart request packet. Bits 4, 3, 2 and 1 of the first octet and all bits of the second octet are set to 0.
TABLE 16/X.75
Diagnostic codes mapping for reset request packet
Decimal value originally generated	 Decimal value passed	
 0	 same	
  1 to 111	 114	
 112 to 127	 same	
 128 to 255	 113	

		Bits								
		8	7	6	5	4	3	2	1	
	1	General format identifier (see Note)				Logical channel group number				
Octets	2	Logical channel number								
	3	Packet type identifier								
		0	0	0	1	1	1	1	1	
Note – Coded 0001 (modulo 8) or 0010 (modulo 128).
FIGURE 18/X.75
Reset confirmation packet format
		Bits								
		8	7	6	5	4	3	2	1	
	1	General format identifier (see Note)				0	0	0	0	
Octets	2	0	0	0	0	0	0	0	0	
	3	Packet type identifier								
		1	1	1	1	1	0	1	1	
	4	Restarting cause								
	5	Diagnostic code								
Note – Coded 0001 (modulo 8) or 0010 (modulo 128).
FIGURE 19/X.75
Restart request packet format

4.5.1.1	Restarting cause field
	Octet 4 is the restarting cause field and contains the reason for the restart.
	The coding of the restarting cause field in the restart request packets is given in Table 17/X.75.
	An STE receiving a restarting cause other than that given in Table 17/X.75 will either pass this cause unchanged or change the cause to “Network congestion”.
TABLE 17/X.75
Coding of restarting cause field in restart request packet
	 Octet 4 Bits								
Restarting cause	8	7	6	5	4	3	2	1	
 Network congestion	 0	 0	 0	 0	 0	 0	 1	 1	
 Network operational	 0	 0	 0	 0	 0	 1	 1	 1	
4.5.1.2	Diagnostic code field
	Octet 5 is the diagnostic code field and may contain additional information on the reason for the restart.
	If the associated restarting cause field (octet 4) indicates any valid cause (see Table 17/X.75) except “Network congestion”, the contents of this field will be passed unchanged in the resulting clear or reset request packet. If the restarting cause field indicates “Network congestion” then the value of the diagnostic code sent in the resulting clear or reset request packet will be as shown in Table 18/X.75.
TABLE 18/X.75
Diagnostic code mapping for restart request packet
Decimal value originally generated	 Decimal value sent	
 0	 same	
  1 to 111	 114	
 112 to 127	 same	
 128 to 255	 113	
	The diagnostic codes in restart request packets generated as the result of events detected at the local STE–X/Y interface are listed in Annex E.
	The bits of the diagnostic code field are all set to 0 when no specific reason for the restart is supplied.

4.5.2	Restart confirmation packet
	Figure 20/X.75 illustrates the format of the restart confirmation packet. Bits 4, 3, 2 and 1 of the first octet and all bits of the second octet are set to 0.
		8	7	6	5	4	3	2	1	
	1	General format identifier (see Note)				0	0	0	0	
Octets	2	0	0	0	0	0	0	0	0	
	3	Packet type identifier								
		1	1	1	1	1	1	1	1	
Note – Coded 0001 (modulo 8) or 0010 (modulo 128).
FIGURE 20/X.75
Restart confirmation packet format
5	Procedures and formats for user facilities and network utilities
5.1	Description of optional user facilities
	Signalling for CCITT specified DTE facilities and those user facilities (see Recommendation X.25) which do not require STE or transit network action is normally contained in the user facility field of X.75 packets. The contents of this field are conveyed transparently through an STE, which may examine and store them, but does not influence the progress of the call as a result.
	Other user facilities which do require STE or transit network action are mapped into X.75 utilities and thus are not present in the X.75 facility field.
5.2	Formats for optional user facilities
	The formats for optional user facilities are described in Recommendation X.25.
5.3	Procedures for network utilities
	The network utility field is a network administrative signalling mechanism in the call request, call connected and clear request packets. The network utility field complements the user facility field and serves to separate user service signalling from network administrative signalling. The request for a service through an optional user facility may, in certain instances, require the use of a network utility.
	There are three categories of network utilities:
–	International Mandatory network utilities: These are the network utilities that must be supported by all international X.75 interworkings. International Mandatory means that every international STE must be capable of actioning the procedures for each network utility so classified. For some international mandatory utilities, not all calls need to signal the utility in the packet. International Mandatory utilities may also be used for national interworkings subject to bilateral agreements.
–	International Optional network utilities: These are the network utilities that may be supported by international X.75 interworkings, subject to bilateral agreements. When an international optional utility has been bilaterally agreed for use, the procedures herein described in this utility are used. International optional utilities may also be used for national interworkings subject to bilateral agreements.
–	National network utilities: These are the network utilities that may only be supported on links between networks in the same country, and are always subject to bilateral agreements.
	The categorization of network utilities is given in Table 19/X.75. Utilities not listed in Table 19/X.75 are for further study and, therefore, no categorization is indicated.
TABLE 19/X.75
Categorization of network utilities
International mandatory network utilities	 Section	
 Transit network identification	 5.3.1 	
 Call identifier	 5.3.2 	
 Throughput class indication	 5.3.3 	
 Window size indication	 5.3.4 	
 Packet size indication	 5.3.5 	
 Fast select indication	 5.3.6 	
 Closed user group indication	 5.3.7 	
 Closed user group with outgoing access indication	 5.3.8 	
 Called line address modified notification	 5.3.10	
 Transit delay indication	 5.3.13	
 International optional network utilities		
 Reverse charging indication	 5.3.9 	
 Clearing network identification code	 5.3.11	
 Transit delay selection	 5.3.14	
 Tariffs	 5.3.15	
 Network user identification	 5.3.16	
 Utility marker	 5.3.18	
 National network utilities		
 RPOA selection	 5.3.17	
	Several network utilities include the identification of a given network, If the given network is a public data network, it is identified by the first four digits (DNIC) of the international data number. However, if the given network is ISDN, it is identified by a four–digit field, the ISDN Network Identification Code (INIC), composed of:
			0 + E.164 Country Code + National Network Digit(s)
where the number of National Network Digits depends on the size of E.164 Country Code, for a given country. National Network Digit(s) may be any value(s) agreed by the Administration within the given country. In order to identify additional ISDNs, some countries may also use the four–digit format composed of:
			9 + E.164 Country Code + National Network Digit(s)
For national utilities, inclusion of E.164 country code is optional.
	Alternate ways of ISDN network identification are for further study.
5.3.1	Transit network identification (International Mandatory)
	The transit network identification is a network utility used to name a transit network controlling a portion of the (perhaps partially established) virtual circuit. A transit network is identified by its DNIC or INIC as specified in § 5.3 above.

	A transit network identification is always present in the call request packet for each transit network controlling the virtual circuit up to this point of call set–up. When more than one transit network is identified, the order of identification in the network utility field identical to the order of traversal of transit networks following the path being established from the calling DTE to the destination network.
	A transit network identification is always present for each transit network in the call connected packet, or the clear request packet issued as a direct response to the call request packet. The transit network identification utility is not present in a clear request packet issued either after receipt of the corresponding call connected packet or after transmission of the corresponding call request or call connected packets. When there is more than one transit network, the identification order in the network utility field is identical to the order of transversal of transit networks following the path established from the calling to called DTE.
5.3.2	Call identifier (International Mandatory)
	The call identifier is a network utility which is always present in the call request packet. The call identifier parameter is established by the originating network and is an identifying name for each virtual circuit established. The call identifier when used in conjunction with the calling DTE address, uniquely identifies the virtual call. The uniqueness is only guaranteed over a period of time. The duration of this time is for further study.
	The use of the call identifier in the call connected packet is for further study. The call identifier is not present in the clear request packet.
	Note – The definition of the content of the call identifier, and further specification of the associated signalling mechanisms, require further study. Pending such further study, the content of a call identifier may or may not be significant for a given call, this is under the responsibility of the originating network. However, it is for further study whether a transit network can create a significant call identifier, in the case it would receive a call identifier which is not significant. When the call identifier is not significant, it would be coded as zero by the originating network.
5.3.3	Throughput class indication (International Mandatory)
	The throughput class indication is a network utility that can be used by any STE for specifying the throughput classes applying to that call.
	The STE associated with the virtual call originating network may request in the throughput class indication utility of the call request packet the throughput class values selected at the calling DTE/DCE interface. Any transit STE may also request throughout class values in the throughput class indication utility of the call request packet. If particular throughput classes are not explicitly requested, the STE is assumed to request the default throughput class values agreed between both Administrations.
	Any STE, including the STEs associated with the virtual call originating and destination network, may reduce but must not raise the throughput class values requested for the call. In reducing the throughput class values, different criteria can be envisaged by the STE. The STE should consider the packet sizes, the window sizes and the throughput classes that it can support at a given time. The STE may also consider the STE resources available and the throughput classes requested for that call. The STEs associated with the virtual call originating and destination networks may also consider the flow control parameters used at the DTE/DCE interface.
	Taking the above considerations into account, the throughput class any STE reduces down to may vary per individual call and may be higher or lower than or equal to the default throughput class values agreed between both Administrations.
	When the called DTE has accepted the call, the STE associated with the virtual call destination network may confirm in the throughput class indication utility of the call connected packet the throughput class values that finally apply to the virtual call following the negotiation with the called DTE. Any transit STE may also confirm throughput class values in the throughput class indication utility of the call connected packet. The STE should not alter the throughput class values received in a call connected packet.
	If particular throughput classes are not explicitly confirmed, STE–Y is assumed to confirm the lesser of the default throughput class values agreed between both Administrations and the throughput class value requested originally. If an STE detects that an explicitly confirmed throughput class value finally applying to the call is higher than the one requested, it should clear the call with an indication of “Network congestion”.
	The throughput class indication utility should not be present in the clear request packet. No indication of throughput classes should be present in the user facility field of the call request, call connected and clear request packets.
5.3.4	Window size indication (International Mandatory)
	The window size indication is a network utility that can be used by any STE for negotiating the window sizes on a specified logical channel at the STE X/Y interface for each direction of transmission.
	When using the window size indication utility in the call request packet, STE–X requests particular window sizes to be used at the STE X/Y interface for that call.
	If particular window sizes are not explicitly requested, STE–X is assumed to request the default values for that call, that is either the standard value of 2 or other values agreed between both Administrations.
	When using the window size indication utility in the call connected packet, STE–Y confirms the window sizes finally applying at the STE X/Y interface to that call.
	If particular window sizes are not explicitly confirmed, STE–Y is assumed to confirm the default values as finally applying to that call.
	Each finally applying value should be in the range from the value requested by STE–X or assumed as a default value to the standard value of 2 (both inclusive). If an STE detects that a value finally applying to that call is out of this range, it should clear the call with an indication of “Network congestion”.
	In altering the window size values, different criteria can be envisaged by the STE. The STE should consider the packet sizes, window sizes and the throughput classes that it can support at a given time. The STE may also consider the STE resources available and the throughput classes requested for that call. The STEs associated with the virtual call originating and destination networks may also consider the flow control parameters used at the DTE/DCE interface.
	The window size indication utility should not be present in the clear request packet.
	No indication of window sizes should be present in the user facility field of the call request, call connected and clear request packets.
5.3.5	Packet size indication (International Mandatory)
	The packet size indication is a network utility that can be used by any STE for negotiating the maximum data field length of data packets on a specified logical channel at the STE X/Y interface for each direction of data transmission.
	When using the packet size indication utility in the call request packet, STE–X requests the maximum data field lengths to be used at the STE X/Y interface for that call.
	If particular data field lengths are not explicitly requested, STE–X is assumed to request default values for that call, that is either the standard value of 128 octets or other values agreed between both Administrations.
	When using the packet size indication utility in the call connected packet, STE–Y confirms the data field lengths finally applying at the STE X/Y interface for that call.
	If particular data field lengths are not explicitly confirmed, STE–Y is assumed to confirm the default values as finally applying to that call.
	Each finally applying value should be in the range from the value requested by STE–X or assumed as a default value to the standard value of 128 octets (both inclusive). If an STE detects that a value finally applying to that call is out of this range, it should clear the call with an indication of “Network congestion”.
	In altering the data field length values, different criteria can be envisaged by the STE. The STE should consider the packet sizes, the window sizes and the throughput classes that it can support at a given time. The STE may also consider the STE resources available and the throughput classes requested for that call. The STEs associated with the virtual call originating and destination networks may also consider the flow control parameters used at the DTE/DCE interface.
	The packet size indication utility should not be present in the clear request packet.
	No indication of packet sizes should be present in the user facility field of the call request, call connected and clear request packets.
5.3.6	Fast select indication (International Mandatory)
	The fast select indication is a network utility used for indicating that the fast select user facility applies to that call.
	When using the fast select indication utility in the call request packet, the STE indicates that the fast select facility applies to that call, with the corresponding packet formats as described in § 4.
	When restriction on response is indicated in such a call request packet, the corresponding STE is permitted to issue as a direct response to this packet a clear request packet with a clear user data field of up to 128 octets, and is not authorized to send a call connected packet.
	When no restriction on response is indicated in such a call request packet, the corresponding STE is permitted to issue as a direct response to this packet a call connected packet with a called user data field of up to 128 octets or at any time a clear request packet with a clear user data field of up to 128 octets. If the call is connected, the originating STE is authorized to transmit a clear request packet with a clear user data field of up to 128 octets.
	No indication of fast select should be present in the user facility field of the call request, call connected and clear request packets.
	The fast select indication utility should not be present in the call connected and clear request packets.
	All other procedures of a call in which the fast select facility has been indicated are the same as those of a virtual call.
5.3.7	Closed user group indication (International Mandatory)
	The closed user group indication is a network utility used for enabling the establishment of virtual calls by DTEs which are members of international closed user groups.
	When using the closed user group indication utility in the call request packet, the STE indicates that the international virtual call is requested on the basis of valid international closed user group membership. The network of the calling DTE supplies the relevant international interlock code.
	The STE should not alter the closed user group indication received in a call request packet.
	Only one of the closed user group indication and the closed user group with outgoing access indication utilities may be present in a call request packet.
	No indication of closed user group should be present in the user facility field of the call request, call connected and clear request packets.
	The closed user group indication utility should not be present in the call connected and clear request packets.
5.3.8	Closed user group with outgoing access indication (International Mandatory)
	The closed user group with outgoing access indication is a network utility used for enabling the establishment of virtual calls by DTEs which are members of international closed user groups.
	When using the closed user group with outgoing access indication utility in the call request packet, the STE indicates that the international virtual call is requested on the basis of valid international closed user group membership. In addition the STE signals an associated outgoing access capability. The network of the calling DTE supplies the relevant international interlock code.
	The STE should not alter the closed user group with outgoing access indication received in a call request packet.
	Only one of the closed user group indication and the closed user group with outgoing access indication utilities may be present in a call request packet.
	No indication of closed user group with outgoing access should be present in the user facility field of the call request call connected and clear request packets.
	The closed user group with outgoing access utility should not be present in the call connected and clear request packets.
5.3.9	Reverse charging indication (International Optional)
	The reverse charging indication is a network utility used for enabling virtual calls to be established internationally, when the reverse charging facility applies.
	When using the reverse charging indication utility in the call request packet, STE–X indicates a request for reverse charging to apply to the call.
	In the absence of the reverse charging indication utility, STE–X is assumed not to request reverse charging for that call.
	The reverse charging indication utility should not be present in the call connected and the clear request packets.
	No indication of reverse charging should be present in the user facility field of the call request, call connected and clear request packets.
5.3.10	Called line address modified notification (International Mandatory)
	The called line address modified notification is a network utility used for indicating the reasons for the called address in the packet being different from that specified in the call request packet.
	The following reasons can be indicated with the use of the called line address modified notification utility:
i)	call distribution within a hunt group;
ii)	call redirection due to originally called DTE out of order;
iii)	call redirection due to originally called DTE busy;
iv)	call redirection due to prior request from the originally called DTE for systematic call redirection;
v)	called DTE originated;
vi)	call deflection by the originally called DTE.
	Both the call distribution within a hunt group and the call redirection are limited to the network of the DTE originally called.
	The called line address modified notification utility will be present in call connected packets where the called DTE address is different from that specified in the call request packets. It will also be present in the clear request packet where the call is cleared by a different DTE from the one orignally called as a direct response to call request packet.
	The called line address modified notification utility should not be present in the call request packet as well as the clear request packet sent after the call is connected.
	No indication of called line address modified notification should be present in the user facility field of the call request, call connected and clear request packets.
5.3.11	Clearing network identification code (International Optional)
	The clearing network identification code is a network utility providing additional information on the origin of the clear request packet and is present only in the clear request packet issued after the call is connected.
	The network originating the clear request is identified by the DNIC or INIC of that network as specified in § 5.3 above.
	An STE receiving a clearing network identification code will pass this code unchanged whenever applicable.
5.3.12	Traffic class indication (for further study)
	The traffic class utility indicates a service category for the virtual circuit being established. The traffic class signals service information (e.g., terminal, facsimile, maintenance) necessary for administering the call. Though their use is beyond the scope of this Recommendation, traffic class may have routing, tariff and other implications. The need for and definition of traffic classes are for further study.
5.3.13	Transit delay indication (International Mandatory)
	The transit delay indication is a network utility that signals the accumulated expected nominal transit delay of a virtual circuit. It is included in the call request packet and call connected packet when a calling DTE has requested a transit delay in the transit delay selection and indication facility. The STE in the originating network will signal a value dependent on the characteristics of the originating network and on the characteristics of the outgoing link (e.g., link speed, satellite or cable).
	Any outgoing STE in a transit network will add to the value received in the transit delay indication utility a value that depends on the characteristics of the network and the outgoing link.
	The transit delay is defined as t3c in Recommendation X.135, and is expressed in terms of a mean value. However, the detailed determination of the value is considered as a national matter. If the resulting value of the transit delay exceeds the maximum value that can be signalled in the utility parameter field, all bits of the utility parameter field will be set to “1”.
	The STE will signal the final value of the accumulated expected nominal transit delay transparently in the call connected packet.
	For an interim period, when not all networks have yet implemented the transit delay signalling, an STE will not send the transit delay indication utility to a network that does not support it. This STE will signal, towards its own network, all 1's in the transit delay indication utility parameter field of the call connected packet.
	No indication of transit delay selection and indication should be present in the user facility field of the call request, call connected and clear request packets.
5.3.14	Transit delay selection (International Optional)
	The transit delay selection utility is a network utility that signals the transit delay requested by the calling DTE in the transit delay selection and indication facility. This utility will be signalled transparently from the originating network to the destination network in the call request packet. This utility may be used in conjunction with the transit delay indication utility for routing purposes.
	The transit delay selection utility should not be present in call connected or clear request packets.
	No indication of transit delay selection and indication should be present in the user facility field of the call request, call connected and clear request packets.
5.3.15	Tariffs (International Optional)
	The tariffs utility is a network utility that is used to pass information from one network to one or more other networks participating in the call for the purpose of implementing billing, accounting, or tariff arrangements that may exist among the respective Administrations.
	The tariffs utility may appear in the call request, call connected, and clear request packets. If this utility appears in the call request packet, the information it contains relates to the originating interface or network. If this utility appears in the call connected or clear request packet, the information it contains relates to the ultimate destination interface or network. The utility may appear in a clear request packet only if that packet is initiated by the destination DTE or DCE, in direct response to the call request.
	The content of this utility is determined by the originating or destination network and does not depend on information passed to the network by a DTE.
	Even if this utility is supported on the STE X/Y interface, it may not be present in a packet for a given virtual call if there is no need to exchange tariff–related information with that packet.
	No more than one instance of this utility may appear in a packet.
5.3.16	Network user identification (NUI) (International Optional)
	The network user identification utility is a network utility used to provide supplementary network user identification for billing, security or network management purposes.
	The utility may be present in the call request packet. No indication of network user identification should be present in the user facility field of any packet.
	Note – Whether the utility may be present in the call connected packet is for further study.
	This utility provides a mechanism for distinguishing a standardized CCITT default format from a format not constrained by this Recommendation.
	A network may support some or all format options of this utility.
	A network receiving this utility determines whether it is the network responsible for verifying the value. If it is not the network responsible for verifying the value, the network forwards the utility to the next network. It is for further study whether a network may forward this utility to the next network if the NUI value has been verified.
	The originating network (STE), in formulating the value/content of this utility, may make use of DTE/DCE interface subscription options, network default assumptions, and/or values passed by the DTE on a per–call basis.
5.3.17	RPOA selection (National)
	RPOA selection is a network utility that may be used to name a RPOA transit network within the originating country through which a call is to be routed. In the case of international calls, this utility may indicate an international RPOA in the originating country.
	This utility can be used to carry a RPOA transit network DNIC or INIC (see § 5.3 above) specified by the calling DTE. When more than one transit network is specified by the calling DTE, a sequence of RPOA selection utilities may be present in the call request packet. In this case, the order of identification of transit networks by the RPOA selection utilities is identical to the order specified by the calling DTE.
	A network receiving a call request packet containing one or more RPOA selection utilities will route to the next requested network, removing the RPOA selection utility that names the next requested network. If it is not possible to route to the next requested network, the receiving network will clear the call.
	The RPOA selection utility should not be present in the call connected and clear request packets. No indication of the RPOA selection should be present in the user facility field of the call request packet.
5.3.18	Utility marker (International Optional)
	The utility marker is used to separate international and national X.75 utilities, as defined under § 5.3 from non–X.75 utilities that may be agreed bilaterally by the Administrations.
5.4	Formats for network utilities
5.4.1	General
	The network utility field is present in all call request and call connected packets, and may be present in clear request packets, exchanged between STEs.
	The utility field contains a number of utility elements. Each utility element consists of a utility code followed by a utility parameter.
	If multiple instances of a utility parameter are required in the utility field, such as the RPOA selection or transit network identification, this information will be presented in multiple utility elements with an identical utility code.
	The utility codes are divided into four classes, by the use of bits 7 and 8, in order to specify utility parameters consisting of 1, 2, 3 or a variable number of octets. The general class coding is shown in Table 20/X.75.
TABLE 20/X.75
General class coding for network utility field
	Utility code field 
Bits									
	 8	 7	 6	 5	 4	 3	 2	 1		
Class A	 0	 0	 X	 X	 X	 X	 X	 X	 for single octet parameter field	
 Class B	 0	 1	 X	 X	 X	 X	 X	 X	 for double octet parameter field	
 Class C	 1	 0	 X	 X	 X	 X	 X	 X	 for triple octet parameter field	
 Class D	 1	 1	 X	 X	 X	 X	 X	 X	 for variable length parameter field	
Note – A bit which is indicated as X may be set to either 0 or 1 as discussed in the text.

	For class D, the octet following the utility code indicates the length, in octets, of the utility parameter. The utility parameter length is binary encoded and bit 1 is the low order bit. The maximum length of utility parameter field for class D cannot exceed 61 octets due to the maximum length of the network utility field.
	The utility code field is binary coded and, without extension, provides for a maximum of 64 utility codes for classes A, B and C and 63 utility codes for class D giving a total of 255 utility codes (see Figure 21/X.75).
	Utility code 11111111 is reserved for extension of the utility code. The octet following this octet indicates an extended utility code having the format A, B, C or D as defined in Figure 21/X.75. Repetition of utility code 11111111 is permitted and thus additional extensions result.
	The specific coding of the utility parameter field is dependent on the utility being requested.

	Class A 

Bits										Class C 

Bits								
	 8	 7	 6	 5	 4	 3	 2	 1			8	7	6	5	4	3	2	1	
 0	 0	 0	 X	 X	 X	 X	 X	 X		 0	 1	 0	 X	 X	 X	 X	 X	 X	
 1	Utility parameter field									1									
										2	Utility parameter field								
										3									

	Class B 

Bits										Class D 

Bits								
	 8	 7	 6	 5	 4	 3	 2	 1			8	7	6	5	4	3	2	1	
 0	 0	 1	 X	 X	 X	 X	 X	 X		0	1	1	X	X	X	X	X	X	
1										1	Utility parameter length								
2	Utility parameter field									2									
										62 (max.)	Utility parameter field								
FIGURE 21/X.75
Utility code general formats
5.4.2	Coding of utility code field
	The coding of the utility code field is given in Table 21/X.75.
	Utility codings are the same for call request, call connected and clear request packets.
TABLE 21/X.75
Coding of the utility code field
	Packet types in which it may be used			Utility code  Bits								
Utility	 Call request	 Call connected	 Clear request	 8	 7	 6	 5	 4	 3	 2	 1	
 Transit network identification	 X	 X	 X (See Note 1)	 0	 1	 0	 0	 0	 0	 0	 1	
 Call identifier	 X	 (See Note 2)		1	 0	 0	 0	 0	 0	 0	 1	
 Throughput class indication	 X	 X		0	 0	 0	 0	 0	 0	 1	 0	
 Window size indication	 X	 X		0	 1	 0	 0	 0	 0	 1	 1	
 Packet size indication	 X	 X		0	 1	 0	 0	 0	 0	 1	 0	
 Fast select and/or reverse charging indication	 X			0	 0	 0	 0	 0	 0	 0	 1	
 Closed user group indication	 X			1	 1	 0	 0	 0	 0	 1	 1	
 Closed user group with outgoing access indication	 X			1	 1	 0	 0	 0	 1	 1	 1	
 Called line address modified notification		X	 X (See Note 1)	 0	 0	 0	 0	 1	 0	 0	 0	
 Clearing network identification code			X (See Note 3)	 0	 1	 0	 0	 1	 0	 1	 0	
 Traffic class indication	 (See Note 4)			 0	 0	 0	 0	 0	 0	 1	 1	
 Transit delay indication	 X	 X		0	 1	 0	 0	 1	 0	 0	 1	
 Transit delay selection	 X			0	 1	 0	 0	 1	 0	 1	 1	
 Tariffs	 X	 X	 X (See Note 1)	 0	 0	 0	 0	 0	 1	 1	 1	
 NUI	 X	 (See Note 2)		1	 1	 0	 0	 0	 1	 1	 0	
 RPOA selection	 X			0	 1	 0	 0	 0	 1	 0	 0	
 Utility marker	 X	 X	 X	 0	 0	 0	 0	 0	 0	 0	 0	
 Note 1 – It is present in the clear request packet issued as a direct response to the call request packet.
Note 2 – The use of the utility in the call connected packet is for further study.
Note 3 – It is present only in the clear request packet issued after the call is connected.
Note 4 – The procedure is for further study.

5.4.3	Coding of utility parameter field
5.4.3.1	Coding of transit network identification utility parameter
	Each of the four digits is coded in a semi–octet in binary coded decimal with bit 5 or 1 being the low order bit of the digit. The high order digit is coded into bits 8 to 5 of the first octet of the parameter.
5.4.3.2	Coding of the call identifier utility parameter
	The call identifier consists of 24 bits of binary data.
5.4.3.3	Coding of throughput class indication utility parameter
	The throughput class for transmission from the calling STE is indicated in bits 4, 3, 2 and 1. The throughput class for transmission from the called STE is indicated in bits 8, 7, 6 and 5.
	The four bits indicating each throughput class are binary coded and correspond to throughput classes as indicated in Table 22/X.75.
TABLE 22/X.75
Coding of throughput classes
Bit:	4	3	2	1		
 or					 Throughput class (bit/s)	
 Bit:	 8	 7	 6	 5		
	 0	 0	 0	 0	 Reserved	
	 0	 0	 0	 1	 Reserved	
	 0	 0	 1	 0	 Reserved	
	 0	 0	 1	 1	    75	
	 0	 1	 0	 0	   150	
	 0	 1	 0	 1	   300	
	 0	 1	 1	 0	   600	
	 0	 1	 1	 1	  1 200	
	 1	 0	 0	 0	  2 400	
	 1	 0	 0	 1	  4 800	
	 1	 0	 1	 0	  9 600	
	 1	 0	 1	 1	 19 200	
	 1	 1	 0	 0	 48 000	
	 1	 1	 0	 1	 64 000	
	 1	 1	 1	 0	 Reserved	
	 1	 1	 1	 1	 Reserved	
5.4.3.4	Coding of window size indication utility parameter
	The window size for the direction of transmission from the called STE is indicated in bits 7 to 1 of the first octet. The window size for the direction of transmission from the calling STE is indicated in bits 7 to 1 of the second octet. Bit 1 is the least significant bit. Bit 8 of each octet is unassigned and set to 0. Each window size value is binary encoded.
	The range of window size values allowed at the STE X/Y interface is subject to a bilateral agreement between Administrations. Window sizes of 8 to 127 are only valid for calls which employ extended numbering.
5.4.3.5	Coding of packet size indication utility parameter
	The maximum user data field length for the direction of transmission from the called STE is indicated in bits 4 to 1 of the first octet. The maximum user data field length for the direction of transmission from the calling STE is indicated in bits 4 to 1 of the second octet. Bits 8 to 5 of both octets are unassigned and set to 0.
	The four bits indicating each maximum user data field length are binary encoded and express the logarithm to base 2 of the maximum number of octets of the data field of data packets. Bit 1 is the least significant bit.
	The maximum user data field length values allowed at the STE X/Y interface are subject to a bilateral agreement between Administrations; however all Administrations will allow 128 octets.
5.4.3.6	Coding of fast select and/or reverse charging indication utility parameter
	Bit:		8	7	6	5	4	3	2	1
	Code:	X	Y	U	U	U	U	U	Z
	U = Unassigned and set to 0,
	X = 0 and Y = 0 or 1 for fast select not requested,
	X = 1 and Y = 0 for fast select requested with no restriction on response,
	X = 1 and Y = 1 for fast select requested with restriction on response,
	Z = 0 for reverse charging not requested, and
	Z = 1 for reverse charging requested.
5.4.3.7	Coding of closed user group code and closed user group code with outgoing access
5.4.3.7.1	Utility parameter length
	Bit:		 8	 7	 6	 5	 4	 3	 2	 1
	Code: 	0	 0	 0	 0	 0	 1	 0	 0
5.4.3.7.2	Utility parameter
	The international interlock code is contained in the utility parameter field and consists of four octets.
	The first two octets of the international interlock code consist of the four digits of DNIC or INIC as specified in § 5.3 above. Each digit is coded in a semi–octet in binary coded decimal with bit 5 or 1 being the low order bit of the digit. The high order digit is coded into bits 8 to 5 of the first octet of the parameter.
	The remaining two octets contain the remaining 16 bits of the international interlock code, encoded with bit 8 of the third parameter octet as the high order bit.
5.4.3.8	Coding of called line address modified notification utility parameter
	Bits:	8	7	6	5	4	3	2	1
		0	0	0	0	0	1	1	1	Call distribution within a hunt group
		0	0	0	0	0	0	0	1	Call redirection due to originally called DTE, busy
		0	0	0	0	1	0	0	1	Call redirection due to originally called DTE out of order
		0	0	0	0	1	1	1	1	Call redirection due to prior request from originally called DTE for systematic call redirection
		1	0	X	X	X	X	X	X	Called DTE originated (see Note 1)
		1	1	X	X	X	X	X	X	Called deflection by the originally called DTE (see Note 2)
	Note 1 – Each X may be independently set to 0 or 1 by the called DTE and is passed transparently.
	Note 2 – The Xs are those set by the originally called DTE in the call forwarding selection facility.
5.4.3.9	Coding of clearing network identification code parameter
	Each of the four digits of the DNIC or INIC of the clearing network are contained in the utility parameter field which consists of two octets. Each digit is coded in a semi–octet in binary coded decimal with bit 5 or 1 being the low order bit of the digit. The high order digit is coded into bits 8 to 5 of the first octet of the parameter.
5.4.3.10	Coding of traffic class indication utility parameter
	The coding of the traffic class parameter is for further study.
5.4.3.11	Coding of transit delay indication utility parameter
	This parameter is two octets. Transit delay is expressed provisionally in milliseconds, binary coded, with bit 8 of octet 1 being the high order bit and bit 1 of octet 2 being the low order bit.
5.4.3.12	Coding of the transit delay selection utility parameter
	This parameter is two octets. Transit delay is expressed provisionally in milliseconds, binary coded, with bit 8 of octet 1 being the high order bit and bit 1 of octet 2 being the low order bit.
5.4.3.13	Coding of the tariffs utility parameter
	The one octet parameter field consists of two subfields of 5 bits and 3 bits respectively:
	Bit:		8	7	6	5	4	3	2	1
	Code:	P	P	P	P	P	U	U	U
	The interpretation of the first subfield which is called Primary tariff subfield is specified by Tables 23/X.75 and 24/X.75:
TABLE 23/X.75
Coding of primary tariff subfield
PPPPP 
87654	 Primary tariff subfield	
 00000	 Subclass code 0 	
 00001	 Subclass code 1 	
.	.	
.	.	
.	.	
 11110	 Subclass code 30	
 11111	 Subclass code 31	
TABLE 24/X.75
Interpretation of primary subclass codes
Primary subclass code(s)	 Interface	
 0	 X.25	
 1	 Switched access X.28	
 2	 Dedicated access X.28	
 3	 X.32	
 4	 X.75	
 5–15	 [Reserved] (Note)	
 16–30	 Reserved for national use	
 31	 Unspecified or non–standard	
 Note – It is for further study whether a portion of the reserved range will be used to specify access interfaces associated with ISDN service.

	The three bits of the second subfield (UUU) are used to designate a secondary, network–specific subclass code that has billing, accounting, or tariff significance. The origination/destination network can optionally use this subfield to specify one of up to seven subclass codes, with a significance set by the network providing the tariff class code value. If this secondary subfield is not utilized, it should be zero filled.
5.4.3.14	Coding of network user identification utility parameter
	The octet following the utility code field indicates the length, in octets, of the utility parameter field. The next octet (the first octet of the parameter field) has one of two alternative formats:
a)	CCITT Standardized Default Format:
Bit:	8	7	6	5	4	3	2	1
1	1	V	R	N	F	V	E
Where V, R, NF, VE, and the remaining octets of parameter field for this case are specified below.
b)	Format Not Constrainted by This Recommendation:
Bit:	8	7	6	5	4	3	2	1
Y	Y	X	X	X	X	X	X
	Where YY = 00, 01, or 10. Neither XXXXXX nor the remaining octets of the parameter field in this case are constrained by this Recommendation.
	For the CCITT standardized default format (case a) above), all of the following apply:
V Bit:	6
0	NUI Value Unverified
1	(Reserved for “NUI Value Verified”)
	The use and coding of the R bit is for further study. Until this use is specified, this bit value is always to be set to 0.
	The format option used for the NUI code proper is encoded in the NF bits:
NF Bits:	4	3
0	0	First Subfield Conforms to ISO 7812/CCITT E.118
0	1	No Constraints on Following Octets
1	0	Subfield Format: No Content Constraints
1	1	[Reserved]
	The verifying entity is encoded in the VE bits:
VE Bits:	2	1
0	0	Originating Network
0	1	Destination Network
1	0	First Transit Network (Note)
1	1	Other/Not Specified
	Note – The use of international transit networks as verifying entities is for further study.
	If NF = 01, the remaining octets of the parameter field are not constrained by this Recommendation. If NF = 00 or NF = 10, the remaining octets of the parameter field contain the NUI code proper and are divided into m subfields (m greater or equal to 1) and each subfield is defined as follows:

	Bits								
	 8	 7	 6	 5	 4	 3	 2	 1	
 I	Type				 0	 0	 0	0	
 I + 1	Subfield length								
I + 2 I + J									
	.							.	
	.	Subfield information						.	
	.							.	
I + J									
 where I is the number of the initial octet of the subfield and (J – 1) is the number of octets of information in the subfield. The type semi–octet specifies the encoding format for the information of the subfield, as follows:

 Bits					
 8	 7	 6	 5		
1	 1	 0	 1	 BCD semi–octet	
 1	 1	 0	 0	 IA5 (T50) with bit 8 = 0	
 1	 1	 1	 0	 Reserved for national use	
 1	 1	 1	 1		
Other				 For future definition	
Bits 4 through 1 of the first octet of each subfield are set to 0. Other values for this semi–octet are reserved for future use.
Subfield length is the number of semi–octets of information in the subfield, and is encoded in binary.
Note 1 – For Type = 1100 (IA5), subfield length must be an even value. For Type = 1101 (BCD), subfield length may be an even or odd value, although an integral number of octets will be assured by inserting zeros in bits 4, 3, 2 and 1 of the last octet of the subfield when necessary.
Note 2 – The need for a maximum value for the length of this utility parameter field, and the value of such a maximum, are for further study.
5.4.3.15	Coding of RPOA selection utility
	The parameter field contains the DNIC or INIC (see § 5.3 above) for a requested RPOA transit network and is in the form of four decimal digits.
	Each digit is coded in a semi–octet in binary coded decimal with bit 5 or 1 being the low order bit of the digit. The high order digit is coded into bits 8 to 5 of the first octet of the parameter.
5.4.3.16	Coding of the utility marker utility parameter
	Bit: 		8	 7	 6	 5	 4	 3	 2	 1
	Code: 	0	 0	 0	 0	 0	 0	 0	 0