The drawings contained in this Recommendation have been done in Autocad
Recommendation X.301
DESCRIPTION OF THE GENERAL ARRANGEMENTS FOR CALL CONTROL WITHIN A
SUBNETWORK AND BETWEEN SUBNETWORKS FOR THE PROVISION OF DATA
TRANSMISSION SERVICES
(Formerly Part of Recommendation X.300, Malaga–Torremolinos, 1984;
amended at Melbourne, 1988)
	The CCITT,
considering
	(a)	that Recommendation X.1 defines the international user classes of service in public data networks and ISDN;
	(b)	that Recommendation X.2 defines the international user services and facilities in PDNs and ISDN;
	(c)	that Recommendation X.10 defines the different categories fo access of data terminal equipment (DTE) to the different data transmission services provided by public data networks (PDNs) and ISDN;
	(d)	that Recommendation X.96 defines call progress signals including those used in conjunction with international user facilities;
	(e)	that Recommendations X.20, X.20 bis, X.21, X.21 bis, X.25, X.28, X.29, X.32, X.351 and X.352 already specify the detailed procedures applicable to different types of DTE/DCE interfaces on PDNs and that Recommendations X.30, X.31, I.420 and I.421 specify detailed procedures applicable for access to ISDN;
	(f)	that Recommendations X.61, X.70, X.71 and X.75 already specify the detailed procedures applicable to call control between two PDNs on the same type and that Recommendation X.75 can also be applied for interworking between different PDNs and for interworking involving ISDN;
	(g)	that PDNs and ISDNs may be used to support CCITT recommended services (in particular, Telematic services);
	(h)	that Recommendation X.200 specifies the reference model of open systems interconnection for CCITT Applications;
	(i)	that Recommendation X.213 defines the connection–mode network service (NS) of open systems interconnection for CCITT Applications;
	(j)	that Recommendations X.130, X.131, X.134, X.135, X.136, X.137 and X.140 define the quality of service parameters and values required for public data transmission services;
	(k)	that Recommendation X.300 defines the general principles for interworking between public networks and between public networks and other networks for the provision of data transmission services;
	(l)	that Recommendation X.302 describes the general arrangements for internal network utilities within subnetwork and intermediate utilities between subnetworks for the provision of data transmission services;
	(m)	that interworking with common channel signalling network (CCSN) needs to be considered, in view of the requirements for transferring operational information between Administrations;
	(n)	the need that DTEs can communicate through different networks, and through different interworking conditions between networks;
	(o)	the need for arrangements for interworking between public networks and between public networks and other public networks for the provision of data transmission services;
	(p)	the need, in particular:
–	for certain user facitilities and network utilities for communication through the national networks between the internationally designed data terminal equipment interface protocols and international inter–exchange control and signalling procedures;
–	for certain internationally defined network utilities for international operation of public networks;
–	for compatibility and uniformity in the principle for realization of international user facilities and network utilities in public networks;
unanimously recommend
	that arrangements for call control interworking between public networks and between public networks and other networks, and that the necessary elements:
–	for realization of interworking between different networks providing data transmission service, and
–	for realization of international user facilities and network utilities for data transmission services,
be in accordance with the principles and procedures specified in this Recommendation.
CONTENTS
0	Introduction
1	Scope and field of application
2	References
3	Definitions
4	Abbreviations
5	General aspects of call control
5.1	Model applicable to internetwork arrangements
5.2	Classification of internetwork signals
5.3	General principles concerning internetwork signals
6	Transfer of addressing information
6.1	General
6.2	Transfer of X.121 calling address
6.3	Transfer of E.164 calling address
6.4	Transfer of X.121 called address
6.5	Transfer of E.164 called address
6.6	Format of X.121 addresses
6.7	Coding of E.164 addresses
6.8	Transfer of address information additional to Recommendation X.121 and E.164
7.	Arrangements for user facilities
7.1	Facilities related to the quality of service (QOS) for the call
7.2	Facilities related to the charging conditions applying to the call
7.3	Facilities related to the specific routing conditions requested by the user of the call
7.4	Facilities related to protection mechanisms requested by the user of the call
7.5	Facilities to convey user data in addition to the normal data flow in the data transfer phase
7.6	Other facilities
8.	Arrangements for Call Progress Signals
8.1	Call progress signals during call establishment
8.2	Clearing call progress signals during data transfer
8.3	Reset call progress signals during data transfer
8.4	Internetwork arrangements involving call progress signals defined in Recommendations X.96 and Q.931.
8.5	Internetwork arrangements involving call progress signals defined in Recommendations X.96 and Q.699
8.6	Internetwork arrangements involving call progress signals defined in Recommendations Q.931 and Q.699.
Appendix I	–	Protocol elements of different networks used for the facilities and arrangements described in this Recommendation.
Appendix II	–	Arrangements to support the OSI Network Service.
0	Introduction
	This Recommendtion is one of a set of Recommendations produced to facilitate consideration of interworking between networks. It is related to Recommendation X.300, which defines the general principles for interworking between public networks, and between public networks and other networks for the provision of data transmission services. Recommendation X.300 indicates, in particular, how collections of physical equipment can be considered as “subnetworks” for consideration of interworking situations.
	This Recommendation describes general arrangements for call control within and between subnetworks for the provision of data transmission services. Only those arrangements are described that may (also) have significance for end users of a call. Facilities that are not visible to end users of a call are the subject of other Recommendations (e.g. those arrangements described in Recommendation X.302).
1	Scope and field of application
	The purpose of this Recommendation is to describe detailed internetwork arrangements for call control applicable to interworking at the OSI network layer, including some of the arrangements necessary to provide support for the capability of the OSI connection–mode NS.
	These arrangements are not applicable to interworking involving communication capability as described in section 7.2 of Recommendation X.300.
	It is for further study whether or not any of these arrangements are also applicable to other types of interworking, for example interworking by port access as described in Recommendation X.300.
	Arrangements that are solely used for internal or internetwork operation, and which are not visible for end–users, are not described in this Recommendation. For such arrangements see Recommendation X.302.
2	References
E.164/I.331		The numbering plan for the ISDN era,
I.230–Series		Bearer services supported by an ISDN,
I.250–Series		Supplementary services supported by an ISDN,
I.420			Basic user–network interface,
I.421			Primary rate user–network interface,
Q.699			Interworking between ISDN user–network of interface protocol and signalling system No. 7 ISDN user part.
Q.931/I.451		ISDN user–network interface layer 3 specification,
X.1			International user classes of service in public data networks (PDNs) and ISDNs,
X.2			International data transmission services and optional user facilities in PDNs and ISDNs,
X.10			Categories of access for data terminal equipment (DTE) to public data transmission services,
X.20			Interface between data terminal equipment (DTE) and Data Circuit–terminating Equipment (DCE) for star–stop transmission services on PDNs,
X.20 bis			Use on PDNs of DTE which is designed for interfacing to asynchronous duplex V–Series modems,
X.21			Interface between data terminal equipment (DTE) and Data Circuit–Terminating Equipment (DCE) for synchronous operation on PDNs,
X.21 bis			Use on PDNs of DTE which is designed for interfacing to synchronous V–Series modems,
X.22			Multiplex DTE/DCE interface for user classes 3–6,
X.25			Interface between data terminal equipment (DTE) and data Circuit–terminating equipment (DCE) for terminals operating in the packet–mode and connected to public data networks by dedicated circuit,
X.28			DTE/DCE interface for a start–stop mode DTE accessing the packet assembly/disassembly (PAD) facility in a PDN situated in the same country,
X.29			Procedures for the exchange of control information and user data between PAD facility and packet–mode DTE or another PAD,
X.30/I.461		Support of X.21, X.21 bis and X.20 bis based data terminal equipment (DTEs) by an integrated services digital network (ISDN),
X.31/I.462		Support of packet–mode terminal equipment by an ISDN,
X.32			Interface between data terminal equipment (DTE) and data circuit–terminating equipment (DCE) for terminals operating in the packet–mode and accessing a packet–switched public data network through a public switched telephone network or an integrated services digital network or a circuit–switched public data network.
X.61			Signalling System No. 7 – Data user part,
X.70			Terminal and transit control signalling system for start–stop services on internatinal circuits between anisochronous data networks,
X.71			Decentralized terminal and transit control signalling system on international circuits between synchronous data networks,
X.75			Packet–switched signalling system between public networks providing data transmission services,
X.80			Interworking of inter–exchange signalling systems for circuit–switched data services,
X.96			Call progress signals in PDNs,
X.110			Routing principles for international public data services through switched PDNs of the same type,
X.121			International numbering plan for public data networks,
X.130			Provisional objectives for call set–up and clear–down times in public synchronous data networks (circuit switching),
X.131			Provisional objectives for grade of service in international data communications over circuit–switched PDNs,
X.134			Portion boundaries and packet layer reference events: basis for defining packet–switched performance paramenters,
X.135			Speed of service (delay and throughput) performance values for public data networks when providing international packet–switched service,
X.136			Accuracy and dependability performance values for public data networks when providing international packet–switched service,
X.137			Availability performance values for public data networks when providing international packet–switched service,
X.140			General quality of service parameters for communication via PDNs,
X.180			Administrative arrangements for international closed user groups (CUGs),
X.200			Reference model for open systems interconnection for CCITT Applications,
X.213			Network Service Definition for Open Systems Interconnection for CCITT Applications,
X.300			General principles and arrangements for interworking between public networks, and between public networks and other networks for the provision of data transmission services,
X.302			Description of the general arrangements for internal network utilities within a subnetwork and between subnetworks for the provision of data transmission services,
X.351			Special requirements to be met for packet assembly/disassembly (PAD) facilities located at or in association with coastal earth stations in the maritime satellite service,
X.352			Interworking between packet–switched public data networks and the maritime satellite data transmission system.
3	Definitions
	This Recommendation makes use of the following terms defined in Recommendation X.300:
a)	Transmission capability
b)	Communication capability
c)	Data transmission service
This Recommendation makes use of the following terms defined in Recommendation X.135:
a)	Transit delay
This Recommendation makes use of the following terms defined in Recommendation X.140:
a)	User information transfer rate
This Recommendation makes use of the following terms defined in Fascicle X.1:
a)	Optional user facility
4	Abbreviations
BCUGB		Bilateral closed user group
BCUGOA	Bilateral closed user group with outgoing access
CC			Country code
CSPDN		Circuit–switched public data network
CTD		Cumulative transit delay
CUG		Closed user group
DCC		Data country code
DCE		Data circuit–terminating equipment
DNIC		Data network identification code
DSE			Data switching exchange
DTE		Data terminating equipment
EETDN		End–to–end transit delay negotiation
FS			Further study
IA			Incoming access
IC			Interlock code
ICB			Incoming calls barred
ICCM		Interworking by call control mapping
IDSE		International data switching exchange
IPA			Interworking by port access
ISDN		Integrated services digital network
IWF			Interworking function
MATD		Maximum acceptable transit delay
MSS		Maritime satellite service
NA			Not applicable
NAE		Network address extension
NAPI/TOA	Numbering and addressing plan indicator/Type of address (equivalent to NPI/TOA used in X.25)
NC			Network connection
NDC		National destination code
NPI/TOA	Numbering plan indicator/TOA (equivalent to NAPI/TOA used in Rec. Q.931)
NS			Network service (pertaining to OSI)
NTN		Network terminal number
NUI			Network user identification
OA			Outgoing access
OCB		Outgoing calls barred
OSI			Open systems interconnection
PSDN		Packet–switched data network
PSPDN		Packet–switched public data network
PSTN		Public–switched telephone network
QOS		Quality of service
QRP			QOS reference point
RPOA		Recognized private operating agency
SN			Subscriber number
TDI			Transit delay indication
TDS			Transit delay selection
TDSAI		Transit delay selection and indication
TOA		Type of address
TTD		Target transit delay
5	General aspects of call control
	The internetwork arrangements described in this section relate to the general aspects of call control.
5.1	Model applicable to internetwork arrangements
	The internetwork arrangements for call control are established according to the model illustrated in Figures 5–1 and 5–2/X.301.
Fig. 5–1/X.301/T0705490-88 = 7 cm

Fig. 5–2/X.301/T0705500-88 = 7 cm

5.2	Classification of internetwork signals
	Recommendations dealing with internetwork signalling systems describe various signals that can be classified as follows:
5.2.1	Internetwork data link control signals
	Data link control signals (e.g., availability of physical circuit(s)) are related to the particularly considered data link and therefore are normally confined within the two ends of the link itself. Thus, these signals do not normally pass across the interworking function.
	An exception to this may be when, for example, a large number of data links in a network are unavailable or faulty, so as to prejudge routing of the calls from an interconnected network. In this case, appropriate operational signals may be generated towards the interconnected network to the extent allowed by the signalling arrangements provided in the interconnected network.
	Note 1 – A given data link may convey signalling data and/or user data.
	Note 2 – Between two packet switching networks, Recommendation X.75 indicates that a given data link may employ several physical circuits.
5.2.2	Internetwork call control signals
	This type of signal includes all signals that convey between two networks the appropriate data and control information for a given call. These signals are essentially related to:
–	call estabishment,
–	data transfer,
–	call release.
	Note 1 – Some signals are essential for call establishment, for example: DTE addresses, indications for user facilities whenever required, and call progress signals. These signals are subject to general descriptions in the relevant Recommendations (for example, DTE addresses in Recommendation X.121, call progress signals in Recommendation X.96). Also, the way to convey these signals between two networks is described in the Recommendations dealing with the internetwork signalling systems.
	Note 2 – Some internetwork signalling systems specify that all call control signals employ a unique data link; this is the case in the signalling system defined in Recommendation X.75. Some other inter–network signalling systems specify that the call control signals employ more than one data link; this is the case in the common channel signalling system, where both a signalling channel and a data channel are used for the same call.

5.2.3	Internetwork operation signals
	This type of signal would consist of all signals that are not directly related to the control of a specific data link or a specifc call between two networks; these operation signals would provide the necessary general information for a satisfactory operation of the internetwork connections such as:
–	system availability,
–	circuit efficiency,
–	congestion or failure conditions, etc.
	Note 1 – The transmission of some internetwork operation signals may cause a network to modify general rules applying to the network operation, such as: change in routing scheme, control of data flow when applicable, clearing of some calls, etc.
	Note 2 – The transmission of such internetwork operation signals does not prevent networks from processing some of these signals used for internetwork operation. In particular, a network may wish to note the exact circumstances of a call clearing related to a remote network failure, in order to take necessary actions as soon as possible (change in routing scheme, etc.).
5.3	General principles concerning internetwork signals
	This section describes some general principles that could be used as a basic for the interworking between different types of networks.
5.3.1	Basic status of a data link
	On every data link established in a network, the data link control signals should provide both ends with the capability of controlling at any time the status of the link. In particular, each end should be able to know whether or not the data link is fully operational; in the case the data link is not fully operational whether or not it is still available for additional data transmission signals related to existing call(s), signals related to new call(s); also whether or not existing call(s) should be cleared (or reset), due to that data link problem.
	Note 1 – Following that principle, provision should be made within the appropriate internetwork signalling Recommendations, so that each network could be aware of the status of the links in an interconnected network whenever required.
5.3.2	Call request and call confirmation phases
	The establishment of a call between two subscribers should consist of two consecutive phases:
–	first a CALL REQUEST phase, when:
–	a call is requested by a subscriber, with specific parameters,
–	this call request is processed and routed through the network(s), unless it cannot be accepted by the network(s),
–	the call request is indicated to the called subscriber;
–	then a CALL CONFIRMATION phase, when:
–	a call acceptance is reported by the called subscriber, unless this subscriber does not acept the call,
–	final arrangements are made through the network(s) for that call,
–	the call establishment is confirmed to the calling subscriber.
	Note 1 – During each one of those two phases, the various actions are not necessarily carried on separately. For example, network equipment may process some call request signals received from a subscriber, before further parameters for the call request are transmitted by that subscriber.
	Note 2 – Currently, the establishment of a call through certain combinations of networks necessitates more than the two phases mentioned in this section; for example, when accessing a packet switching network from a circuit switched network, the complete establishment of the switched access is usually required before the virtual call can be requested. Following the principle indicated in this section, provision should be made within the appropriate internetwork signalling Recommendations, for the establishment of direct calls between both end users whenever it is possible. Consequently, provision should also be made within the numbering plan so that a subscriber line could be directly and uniquely identified from any network.
	Note 3 – The way to accept and route a call through different networks may depend not only on the called DTE address, but also on parameters or facilities defined for that call. Following the principle indicated in this section, in the case where some parameters or facilities may require negociation during the call establishment:
–	the calling DTE can only indicate its specific requirements for the call when it requests the call,
–	the called DTE can only modify the call characteristics when it accepts the call.
5.3.3	Data transfer phase
	Different types of networks may provide different functionalities in this phase, e.g. transfer capabilities of continuous bit streams, transfer of blocks of data, and features like flow control, sequencing, error notification, reset services, receipt confirmation and expedited data transfer.
5.3.4	Call clearing phase
	Any network or user involved in a call should have the possibility to clear immediately that call.
	At the time a call is cleared, any network involved in the call would immediately stop transmitting user data for the call, and report the call clearing to the adjacent networks, unless they are already informed of that clearing. The clearing signal should then be transmitted with all necessary details, i.e., cause and diagnostic codes.
	As soon as a call clearing is locally completed any resource used for that call can be re–used by the network for other calls.
	Note 1 – Following that principle, the receipt of a clear confirmation does not necessarily mean that the end user was already informed of the clearing, and confirmed it.
	Note 2 – The call clearing principle indicated in this section does not prevent both users from exchanging end–to–end information about the clearing of the call, if they wish to do so at the end of data transfer (example: invitation to clear data packet in Recommendation X.29).
	Note 3 – In some cases of clearing collisions, for example when both a DTE and a network initiate the Call Clearing Phase simultaneously, parameter information provided by the DTE may be lost.
	For the purpose of this Recommendation, a DTE that initiates the Call Clearing Phase is labeled “Clearing DTE”. A DTE that does not initiate the Call Clearing Phase, but is informed of this phase by the network, is labeled “Cleared DTE”.
6	Transfer of addressing information
	The internetwork arrangements described in this section provide the capability to transfer all elements of addressing information for the provision of data transmission services. This comprises addressing information defined in Recommendation E.164, Recommendation X.121 and any additional addressing information defined at the Network Layer of OSI. Table 6–1/X.301 lists the optional user facilities relating to addressing information described in this section.
TABLE 6–1/X.301
Optional user facilities relating to the transfer of addressing informations

Optional user facility	
Period	
Applies per 	Applies to circuit switched data
 transmission service			Applies to packet switched data
 transmission service			
	of time	 call	
PTSN	
CSPDN	
ISDN	
ISDN	
PSPDN	
MSS	
Calling line identification	 X			X					
Calling line identification	 X	 X 
(Note)		 X	FS				
Network address extension (NAE)/
sub–address		

X				

X	

X	

X	
Note – This facility cannot be used unless the corresponding facility has been agreed for a period of time.
6.1	General
	For the provision of data transmission services, different numbering plans are considered. These are the Recommendation X.121 numbering plan and the Recommendation E.164 numbering plan. Currently Recommendation X.121 is used by PDNs and Recommendation E.164 is used by the telephony network ISDN Recommendation E.164 will be used by ISDNs. Because of this, this section will refer to networks that make use of X.121 numbering as an X.121 domain (PDNs) and networks that make use of E.164 as an E.164 domain (ISDNs).
	For interworking between X.121 domains and E.164 domains some indication is needed in the protocol of the numbering plan of the address present in the address protocol element(s). This indication can take the form of an escape associated directly with the address or a protocol element indication separate from the address protocol element. This latter method will be referred to as a Numbering Plan Indicator/Type of Address (NPI/TOA) in which case the domains can be considered as one combined domain. The actual value of the escape in PDNs and ISDNs is defined in X.121 and E.166. The form of the NPI/TOA depends on the actual network access protocol used.
	It should be noted that no indication of address type or numbering plan is needed if the call is contained solely within one numbering plan domain. Some networks may require the indication to be present at all cases.
	The model shown in Figure 6–1/X.301 is used to describe internetwork arrangements for the treatement of address information conveyance.
	In the figure the following cases terms are used:
a)	international data number: DNIC + NTN or DCC + NN, as defined in Recommendation X.121;
b)	international X.121 format: case a), or Escape + other international number, as defined in Recommendation X.121;
c)	X.121 formats: Prefix (if any) + case b), or other national format;
d)	E.164 international number: CC + N(S)N, as defined in Recommendation E.164;
e)	international E.164 format: case d) or Escape + other international number;
f)	E.164 format: prefix (if any) + case e), or other national format;
g)	combined domain address: the domain is determined by NPI/TOA.
6.2	Transfer of X.121 calling address
	This section describes arrangements for the transfer of calling address information defined in Recommendation X.121 through PDNs and ISDNs. Such information is referred to in this section as the “X.121 calling address”. In this section, it is assumed that the originating network is a PDN (X.121 domain).
6.2.1	Transfer during call request phase
	The X.121 calling address shall be provided by the originating PDN. In some cases this will occur automatically, and in others it will be provided only when requested by the destination PDN (see § 6.1.4). The originating PDN is responsible for the accuracy of the X.121 calling address when it is provided.
	However, the following particular situations occur:
6.2.1.1	In some cases of interworking with an E.164 domain, a method of indicating that the calling address is an X.121 address must be employed. This shall be done either by using a standardized escape digit to indicate an X.121 address follows or by some form of NPI/TOA indicating the calling address is an X.121 address.
6.2.1.2	In some cases, even where the transfer of the X.121 calling address is technically possible, there may be administrative reasons why the identity of the calling user, and therefore the X.121 calling address related to it, cannot be passed over an international boundary. In such a case, the identification of the originating network shall be provided instead of the X.121 calling address.

Fig./T0705510-88

Note – This Figure is a functional domain diagram and is not intended to imply a real internetwork implementation.

			 Case	
Direction	Form of address	Extent of validity	Term	
A to B	NTN	Network	c)	
A to B	P1 + NTN	Network	c)	
A to B	DNIC + NTN	Internetwork	a)	
A to B	P2 + DNIC + NTN	Internetwork	c)	
A to B	[NPI/TOA] + NTN	Network	g)	
A to B	[NPI/TOA] + DNIC + NTN	Internetwork	g)	
C to D	SN	Network	f)	
C to D	P3 + SN	Network	f)	
C to D	CC + N(S)N	Internetwork	d)	
C to D	P4 + CC + N(S)N	Internetwork	f)	
C to D	[NPI/TOA] + SN	Network	g)	
C to D	[NPI/TOA] + CC + N(S)N	Internetwork	g)	
A to C	E1 + CC + N(S)N	Internetwork escape to
Recommendation E.164	b)	
A to C	P5 + E1 + CC + N(S)N	Internetwork escape to
Recommendation E.164	c)	
A to C	[NPI/TOA] + CC + N(S)N	Internetwork	g)	
C to A	E2 + DNIC + NTN	Internetwork escape to
Recommendation X.121	e)	
C to A	P6 + E2 + DNIC + NTN	Internetwork escape to
Recommendation X.121	f)	
C to A	[NPI/TOA] + DNIC + NTN	Internetwork	g)	
FIGURE 6–1/X.301
Address forms for the Call Establishment Phase
Notes associated with Figure 6–1/X.301:
Note 1 – Refer to § 6.6 for more details on an X.121 address.
Note 2 – Refer to § 6.7 for more details on an E.164 address.
Note 3 – Prefixes are indicated by P. P1, P2, P3 and P4 are distinct decimal digits. P5 may or may not be equal to P2. P6 may or may not be equal to P4. The use and form of the prefix is a national matter. Prefixes are not passed over internetwork gateways.
Note 4 – DNIC can also be replaced by DCC as appropriate.
Note 5 – The form of the NPI/TOA depends on the actual network access protocol used.
Note 6 – E1 and E2 indicate escape digits internationally standardized that function as an indication that the digits behind the escape are from a different numbering plan. Prefixes may or may not preceed the escape digit.
Note 7 – For protocol elements used, see Appendix I to this Recommendation.
6.2.1.3	Networks other than PDNs and ISDNs, whenever they are used in conjunction with the PDN for offering data transmission services, should, if possible, provide for the transfer of an X.121 calling address. However, this transfer is not technically possible through some current networks; for example, for a call passing through a PSTN, into a PDN, the telephone network is not always able to indicate the X.121 calling address to the data network. In such a case, information transferred through the PDN instead of the X.121 calling address is for further study.
6.2.1.4	In the circuit switched service in CSPDNs, the X.121 calling address can be transferred as the calling line identification. It is transferred to the called DTE only if the called DTE subscribers to the calling line identification facility (see § 6.1.4).
6.2.1.5	In packet switched service in PSPDNs, ISDNs, and in the circuit–switched data transmission service in ISDNs, the X.121 calling address is transferred to the called DTE in the address field (appropriate to the relevant protocol) signalled to the called DTE (see Appendix I to this Recommendation).
6.2.2	Transfer during call confirmation phase
	Provided the route for the call is selected during the call request phase, the X.121 calling address does not need to be transferred back through the PDNs and ISDNs during the call confirmation phase.
6.2.3	Transfer during other phases of the call
	The X.121 calling address may not need to be transferred through the PDNs during any other phase of the call.
6.2.4	Calling line identification
6.2.4.1	General
	Calling line identification is an optional user facility, standardized for circuit–switched data transmission services on a CSPDN, that enables a user to be informed of the identity of the calling user for incoming calls. When provided the facility applies to all incoming calls.
	Calling line identification is an optional user facility assigned to the user for an agreed contractual period.
	The calling line identity is the X.121 data number of the calling user. For international calls, the identity is the complete X.121 international data number including the DNIC or DCC component as applicable.
	Note – The implications of a possible combination of calling line identification and the bilateral closed user group facility are for further study.
	Information indicating that a user has the calling line identification facility is stored at the exchange to which the user is connected. The identity sent to the called user is originating under control of the exchange to which the calling user is connected.
	Facility registration is controlled by the Administration or Recognized Private Operating Agency (RPOA).

6.2.4.2	Call establishment procedure
	The procedure for a call to a user having the calling line identification facility varies depending on whether the calling line identity is included in the initial call control information received by the destination exchange at call establishment.
a)	In the case where the calling line identity is included in the call control information received by the destination exchange, this identity is sent to the called user in accordance with the applicable DTE/DCE interface protocol.
b)	In the case where the calling line identity is not included in the call control information received by the destination exchange, it sends a request for identification towards the originating exchange.
i)	In the case where the originating network does provide the calling line identification facility, the originating exchange responds with the calling line which is forwarded by the destination exchange to the called user in accordance with the applicable DTE/DCE interface protocol.
ii)	In the case where he originating network does not provide the calling line identification facility, the originating exchange responds with the originating network identity (see Recommendation X.302). In this case, the identification sent by the destination exchange to the called user is in accordance with the applicable DTE/DCE interface protocol.
	The destination exchange must not connect through until the identity has been completely sent to the called user. Also, in the case where decentralized signalling is used, transit exchanges have to delay through–connection in certain situations until a possible identification has been completed in accordance with the applicable interexchange signalling procedures (see Recommendations X.70 and X.71).
6.3	Transfer of E.164 calling address
	This section describes arrangements for the transfer of calling address information defined in Recommendation E.164.
6.3.1	Transfer during call request phase
	The E.164 calling address shall be provided by the originating E.164 network for data–mode calls, when calling line identification is provided. The originating E.164 network is responsible for validating the E.164 calling address, when provided. In the case where the calling address is conveyed transparent for the E.164 network (e.g. part access), such validation, if any, will be done outside the E.164 network.
	However, the following particular situations occur:
6.3.1.1	In case of interworking with a non–E.164 network, a method of indicating that the calling address is a E.164 address must be employed. This shall be done either by using a standardized escape digit to indicate a E.164 address follows or by some form of NPI/TOA indicating the calling address is an E.164 address.
6.3.1.2	In some cases, even where the transfer of the E.164 calling address is technically possible, there may be administrative reasons why the identity of the calling user, and therefore the E.164 calling address related to it, cannot be passed over an international boundary. In such a case, the procedures are for further study.
6.3.1.3	Networks other than PDNs and ISDNs, whenever they are used in conjunction with the PDN and ISDN for offering data transmission services, should, if possible, provide for the transfer of E.164 calling address. However, this transfer may not be technically possible through some current networks; for example, for a call passing through a PSTN, into a PDN or ISDN, the telephone network is not always able to indicate the E.164 calling address to the E.164 network. In such a case, alternate calling address information transferred through the PDN or ISDN instead of the E.164 calling address is for further study.
6.3.1.4	In a PDN or ISDN the E.164 calling address can be transferred to the called DTE in calling address field (appropriate to the relevant protocol) signalling to the called DTE (see Appendix I).
	Note – Not all DTEs will be able to accept the long packet format that will be required for full E.164 addresses in post Time “T”. The calling address could not be delivered to such DTEs.
6.3.1.5	In an ISDN, the E.164 calling address is transferred to the called DTE primarily in the calling DTE address field signalled to the called DTE. It can also be transferred in a duplicate manner using notification procedures in the calling party number information element contained in the SETUP message sent to the called party across the D–Channel (see Recommendation X.31). In this case, the calling party number information element must be so coded as to indicate that the calling address is an E.164 address.
	Note – Not all DTEs will be able to accept the long packet format that will be required for full E.164 addresses in post Time “T”. The calling address could not be delivered to such DTEs.
6.4	Transfer of X.121 called address
	This section describes arrangements for the transfer of called address information defined in Recommendation X.121 through PDNs and ISDNs. Such information is referred to in this section as the “X.121 called address”.
	Note – The X.121 called address resides only on a PDN.
6.4.1	Transfer during call request phase
	As it is essential for the purposes of call establishment, inlcuding routing, the X.121 called address is systematically transferred through the PDNs and ISDNs during the call request phase.
6.4.2	Transfer during call confirmation phase
	The destination network does not need to provide the X.121 called address (or called line identity) if not requested. When provided, the destination PDN is responsible for validating the X.121 called address.
	However, the following particular situations occur:
6.4.2.1	In the circuit switched data transmission service in CSPDNs, the X.121 called address can be transferred to the calling DTE as the called line identity. It is transferred if the calling DTE requests the called line identification facility (see § 6.4.4). If the call has been redirected or if a hunt group facility has been invoked in the destination PDN, the address of the called DTE/DCE interface over which the call is established shall be transferred.
6.4.2.2	In PSPDNs and ISDNs, the X.121 called address can be transferred to the calling DTE. In the case of call redirection facility, the address of the called DTE/DCE interface over which the call is established is always transferred. In the case of hunt group facility, this address is always transferred, if a specific address has been assigned to the individual DTC/DCE interface over which the call is established.
6.4.3	Transfer during other phases of the call
	The X.121 called address does not need to be transferred through the network during any other phase of the call.
	However, the following particular situation occurs:
6.4.3.1	In the packet switched data transmission service, a clear request issued by a DTE, to which a call has been redirected or distributed among a hunt group as a direct response to the call request phase, should contain the address of the DTE/DCE interface. This is mandatory in the hunt group facility case only if specific addresses have been assigned to the individual DTE/DCE interfaces of the hunt group. When this clear request is destined for an E.164 network, some method of indicating this in an X.121 number must be used (see § 6.1).
6.4.4	Called line identification
6.4.4.1	General
	Called line identification is a user facility, standardized for circuit–switched data transmission services on a CSPDN, that enables a user to be informed for outgoing calls of the identity of the user to which the call has been connected. When provided, the facility applies to all outgoing calls.
	It is an optional user facility assigned to the user for an agreed contractual period.
	The called line identification is the X.121 data number of the user to which the call has been connected. For international calls, the identity is the complete X.121 international data number including the DNIC or DCC component as applicable.
	Information indicating that a user has the called line identification facility is stored at the exchange to which the user is connected. The identity sent to the calling user is originated under control of the exchange to which the called user is connected.

6.4.4.2	Call establishment procedures
	In the case of a call from a user having the called line identification facility, the call control information forwarded by the originating exchange at call establishment includes a request for called line identification. The procedure then depends on whether or not the destination network provides the facility.
a)	In the case where the destination network does provide the called line identification facility, the destination exchange responds with the called line identity, which is returned by the originating exchange to the calling user in accordance with applicable DTE/DCE interface protocol.
b)	In the case where the destination network does not provide the called line identification facility, the destination network responds, depending on what type of signalling is used, with the destination network identity (Recommendation X.302) or with a “dummy” identification (Recommendation X.70 or X.71). The information sent by the originating exchange to the calling user is in accordance with the applicable DTE/DCE interface protocol.
	For circuit switched calls, the originating exchange must not connect through until the identity has been completely sent to the called user. Also, in the case where decentralized signalling is used, transit exchanges have to delay through–connection in certain situations until a possible identification has been completed in accordance with the applicable interexchange signalling procedures (see Recommendations X.70 and X.71).
6.5	Transfer of E.165 called address
	This section describes the arrangements for the transfer of called address information defined in Recommendation E.164.
6.5.1	Transfer during call request phase
	As it is essential for the purposes of call establishment, including routing, the E.164 called address is systematically transferred through the PDNs and ISDNs during the call request phase.
	However, the following particular situation occurs:
6.5.1.1	In the case of interworking with a non–E.164 network where the transit network is a PDN, a method of indicating that the called address is an E.164 address must be employed. This shall be done either by using a standardized escape digit to indicate an E.164 address follows or by some form of NPI/TOA indicating the called address is an E.164 address.
6.5.2	Transfer during call confirmation phase
	The destination network does not need to provide the E.164 called address (or called line identity) if not requested. When provided, the destination network is responsible for validating the E.164 called address.
	However, the following particular situation occurs:
6.5.2.1	In PDNs and ISDNs, the E.164 called address can be transferred to the calling DTE as the called line identification. In the case of call re–direction facility, the address of the called DTE/DCE interface over which the call is established is always transferred. In the case of the hunt goup facility, this address is always transferred, if a specific address has been assigned to the individual DTE/DCE interface over which the call is established.
	Note – Not all DTEs will be able to accept the long packet format that will be required for full E.164 addresses in post Time “T”. The calling address could not be delivered to such DTEs.
6.5.3	Transfer during other phases of the call
	The E.164 called address does not need to be transferred through the network during any other phase of the call.
	However, the following particular situation occurs:
6.5.3.1	In the packet switched data transmission service, a clear request issued by a DTE, to which a call has been redirected or distributed among a hunt goup as a direct response to the call request phase, should contain the address of the DTE/DCE interface. This is mandatory in the hunt group facility case only if specific addresses have been assigned to the individual DTE/DCE interfaces of the hunt goup. When this clear request is destined for an X.121 network, some method of indicating this in an E.164 number must be used (see § 6.1).
6.6	Format of X.121 addresses
	Section 6.1 describes the different cases for the format of X.121 addresses.
	Address information defined in Recommendation X.121 is referred to in this section as the “X.121 address”.
	Whenever an X.121 address has to be conveyed across a DTE/DCE interface or an IDSE X/Y interface, according to the requirements mentioned in this Recommendation, this transfer should be done according to the following principles:
6.6.1	For international calls, the X.121 address shall be given explicitly in the form of the complete international data number including the DNIC or DCC component as applicable.
6.6.2	The exact format of an address signal may not necessarily be the same nationally. Such a format is a matter for specific arrangement at each interface involved in the call: calling DTE/DCE interface, called DTE/DCE interface and interexchange interfaces.
	For example, on an X.21 or X.25 interface, the same address may be represented in either one of the ways illustrated in a) or b) and/or c) or d) and/or e) of Figure 6–2/X.301.
Fig. T0705520-88

	This example illustrates the use of a prefix, as recognized in Recommendation X.121, as one way to distinguish between different format of the same address.
	In the case of mobile services, a conversion between different address formats may be required at various interfaces throughout the network, for roaming subscribers.
	Note – A roaming mobile subscriber is a subscriber who may obtain fully automatic connections, even when he moves out of his normal area of operation.
6.6.3	The specific format(s) that can be used at a given interface are defined in the appropriate CCITT Recommendations dealing with the interface.
6.7	Format of E.164 Addresses
	Section 6.1 describes the different cases for the format of E.164 addresses.
	Address information defined in Recommendation E.164 is referred to in this section as the “E.164 address”.
	Whenever an E.164 address has to be conveyed across a network/user interface or an interexchange interface, according to the requirements mentioned in this Recommentation, this transfer should be done according to the following principles:
6.7.1	For internetwork calls the E.164 address shall be given explicitly in the form of the complete international subscriber number including the CC and N(s)N.
6.7.2	The exact coding (format) of an address signal may not necessarily be the same nationally. Such a format is a matter for specific arrangement at each interface involved in the call: calling network/user interface, called network/user interface and interexchange interfaces.
	For example, on an ISDN interface, the same address may be represented in either one of the ways illustrated in a) or b) and/or c) or d) of Figure 6–3/X.301.
Fig.T0705530-88

	This example illustrates the use of a prefix, as recognized in Recommendation E.164 as one way to distinguish between codings (or formats) of the same address.
6.7.3	The specific formats that can be used at a given interface are defined in the appropriate CCITT Recommendation dealing with that interface.
6.8	Transfer of address information additional to Recommendation X.121 and E.164
	This section describes arrangements for the transfer of address information additional to that defined in Recommendations X.121 and E.164.
6.8.1	General
	The Network Addressing Extension (NAE)/subaddress (see note) mechanism allows the transfer through PDNs on a per call basis of addressing information beyond the total limit established for X.121/E.164 addresses. This mechanism is standardized for circuit and packet switching data transmission service as shown in Table 6–2/X.301.
TABLE 6–2/X.301
Optional user facilities standardized for different data transmission services,
related to addressing information additional to Recommendations X.121 and E.164

Optional user facility	Periodof	
Applies per 	 Applies to circuit switched data transmission service			 Applies to packet switched data transmission service			
	time	call	PTSN	CSPDN	ISDN	ISDN	PSPDN	MSS	
Calling NAE/sub–address		X			X	X	X	X	
Called NAE/sub–address		X			X	X	X	X	
	If sufficient space exists in the fields carrying X.121/E.164 address information, and an arrangement exists between users and networks concerned, this constitutes an alternative capability, available on a per call basis without requiring the NAE mechanism, for the transfer of addressing information additional to that defined in Recommendation X.121/E.164.
	Note – Different terms exists: In general, NAE is used in X–Series Recommendations, and subaddress is used in I–Series Recommendations.
6.8.2	Realization
	The detailed realization of the NAE mechanism at each type of internetwork and user interface is independently defined in the appropriate signalling and interface Recommendations.
6.8.3	Principles
	The following principles apply equally and independently to both called and calling address information:
6.8.3.1	The transfer of addressing information at the OSI Network Layer additional to that defined in Recommendation X.121/E.164 is possible during any phase of the call in which address information defined in X.121/E.164 can also be transferred (see §§ 6.1 and 6.7 above).
6.8.3.2	The addressing information in the NAE/subaddress can be of variable length. It can comprise up to 20 octets of binary coded information (see Note). The content of the information is unrestricted with respect to the grouping of digits.
	Note – The maximum length of 40 decimal digits is derived from the maximum length of the OSI Network Service Access Point (NSAP) address defined in Recommendation X.213 [see also ISO 8348 AD2]. Exact arrangements for treatment of the OSI NSAP address are for further study.
6.8.3.3	Public networks are not required to look at or operate on a NAE/subaddress for any purpose including routing; however, some public networks may look at the NAE/subaddress, if they wish.
6.8.3.4	In cases where it is possible, and an arrangement exists between users and public networks concerned, the conveyance of the complete addressing information (i.e., all elements of OSI Network Addressing) may be performed without NAE/subaddress mechanism.
6.8.3.5	Each internetwork interface should simultaneously accommodate the following partitions of the addressing information between existing protocol elements for addressing and NAEs/subaddresses:
a)	All elements of addressing information are contained in the existing protocol elements for addressing; no NAE/subaddress is needed; the complete DTE Network Address is contained in the existing protocol elements.
b)	The complete DTE Address is contained in the NAE/subaddress; all elements of addressing information needed by the public networks involved in the call are contained in the existing protocol elements for addressing. The information used by public networks may be derived from the NAE/subaddress.
Note – In this case, for some OSI Network Addresses, part of the OSI Network Address information may be duplicated in the existing protocol elements for addressing.
c)	The addressing information is split into two elements, one contained in the existing protocol elements for addressing, the other contained in the NAE/subaddress. The complete DTE address is the concatenation of the two elements.
d)	The addressing information is contained in the NAE/subaddress only. This case is typical for private networks since public networks act typically on X.121/E.164 numbers.
6.8.3.6	The use of the NAE/subaddress is either:
–	as defined in Recommendation X.213 (see also ISO 8348 AD2) or
–	differently.
	When the use of the NAE/subaddress is as defined in Recommendation X.213 (see also ISO 8348 AD2), case c) in § 6.8.3.5 does not apply.
7	Arrangements for user facilities (see Note 1)
	The internetwork arrangements described in this section relate to the optional user facilities defined in Recommendation X.2 and I.250–Series Recommendations (see Note 4).
	Note 1 – Different terms: in general optional user facilities is used in X–Series Recommendations, and supplementary services is used in I–Series Recommendations.
	Note 2 – Support of these facilities by the ISDN in other modes of operation than packet–mode is for further study (see I.230–Series Recommendations).
	Note 3 – General arrangements for treatment of registration procedures (e.g. Recommendation X.32) are for further study.
	Note 4 – Alignment/interworking between facilities defined in X.2 and supplementary services defined in I.250–Series Recommendations is for further study.
	Alphabetical List of Facilities contained in this section
Bilateral closed user group					7.4.2
Called line address modified notification				7.3.5
Call redirection or deflection notification				7.3.6
Charging information						7.2.3
Closed user group						7.4.1
Connect when free and waiting allowed				7.6.2
Deflection of calls						7.3.2
Expedited data negotiation					7.6.4
Fast select							7.5.2
Hunt group							7.3.3
Incoming calls barred						7.4.3
Local charging prevention						7.2.2
Manual answer							7.6.1
Network user identification (NUI)				7.4.5
NUI override permission						7.4.6
Outgoing calls barred						7.4.4
Quality of OSI network service and of data transmission service	7.1.1
Quality of Serive parameters					7.1.2
Receipt confirmation						7.6.3
Redirection of calls						7.3.1
Reverse charging and reverse charging acceptance			7.2.1
RPOA selection							7.3.4
7.1	Facilities related to the quality of service (QOS)for the call
	This section described arrangements required for quality of service related to the transmission capability.
7.1.1	Quality of OSI network service and of data transmission service
	The term “Quality of Service” (QOS) refers to the specification of certain characteristics of a Network Connection (NC) as defined in the OSI network service (X.213). However, QOS can also be specified in relation to the data transmission service which is used to support the OSI network service. Each of these QOS specifications, and the relationship between them is described in the following sections.
7.1.1.1	QOS Specification in the OSI network service
	The OSI network service including a detailed definition of QOS parameters is specified in Recommendation X.213. The reference points between which the QOS parameters apply are the network service access points (NSAPs).
	The value of QOS applies to an entire NC. When determined or measured at both ends of an NC, the QOS observed by the NS users at the two ends of the NC is the same. This is true even in the case where the Network Connection is provided through the interworking of different types of networks.
	Two interworking categories related to the transmission capabilities exist, i.e. interworking at the network layer, and interworking by port access. The reference point between which the QOS parameters apply are in both cases of interworking the two NSAPs involved (see Figures 7–1/X.301 and 7–2/X.301). However, the method of interworking may impact the value of QOS between the reference points.
	The Transport Layer may make a request to the OSI network service provider for a network layer connection with certain QOS characteristics (e.g. in order to decide the class of transport protocol to be used). In response to such a request, the OSI network service provider may offer a network layer connection with QOS characteristics that meet (the margins of) the request, or the OSI network service provider may reject the request, if the QOS characteristics cannot be met.
	The QOS Reference Points between which the QOS has to be measured for this instance of communication, are the NSAPs between which the network layer connection has to be established.
	Recommendation X.224 (Transport Protocol) classifies network connections in terms of QOS with respect to error behaviour in relation to user requirements; its main purpose is to provide a basis for the decision regarding which class of transport protocol should be used on top of a given network connection.
7.1.1.2	QOS Specification in the data transmission service
	Figure 7–3/X.301 illustrates an example of the data transmission service in the case where the data transmission service is provided by a public data network (PDN). The QOS parameters which are specified for the data transmission service can be specified in terms of event occurring within the network layer at the DTE/DCE interface. The QOS Reference Points are defined to be inside the network layer entities through which the PDN may be accessed (e.g. the DCEs) and where these network layer events are observed.
	These reference points apply both to interworking at the network layer and to interworking by port access.
Fig. 7–1/X.301/T0706170-88 = 12 cm

Fig. 7–2/X.301/T0705550-88 = 7 cm

Fig. 7–3/X.301/T0705560-88 = 7 cm

7.1.1.3	Relationships between OSI network service QOS and data transmission service QOS is illustrated in Figure 7–4/X.301. The network service QOS includes a component which is the data transmission service QOS and also a component which is due to the operation of the network service provider outside the data transmission service (i.e. the network service provider between the data transmission service QRPs and the relevant NSAPs). The operation of the network service provider outside the data transmission service may have the effect of either devaluing or improving the QOS depending upon the circumstances and the aspect of QOS involved. In any case, for an instance of communication, the QOS of the network service is different from the QOS of the data transmission service. The relationship between such QOS values is the responsibility of the network service provider outside the data transmission service.

Fig. 7–4/X.301/T0705570-88 = 7 cm

7.1.2	QOS Parameters
7.1.2.1	OSI network service QOS Parameters
	Network service QOS is described by means of QOS parameters. The definition of each parameter specifies the way in which the parameter's value is measured or determined, making reference where appropriate to the events represented by service primitives in the network service.
	It is in terms of network service QOS parameters that information about QOS is exchanged among the network service provider and the NS users.
	Examples of QOS parameters which are defined in the network service are throughput, transit delay, and residual error rate. Recommendation X.213 contains the definitions of the complete set of QOS parameters which apply to the nework service.
7.1.2.1.1	QOS Parameter Values
	In some circumstances, only a single value for a QOS parameter is conveyed (e.g. the target value desired by the network service user or the value being made available by the network service provider). In other cases however, it may be possible to specify a pair of values which define an applicable range of values (e.g. the network service user may be able to specify a range bounded by a target value which is desired and the minimum acceptable value which the user is willing to agree to.) The number of values which may be conveyed is dependent upon the specific QOS parameter.
7.1.2.1.2	QOS Parameter Categories
	The network service QOS parameters can be divided into two categories as follows:
1)	Parameters negotiated on a per–connection basis – the values of these parameters can be conveyed between peer NS users by means of the NS during the establishment phase of an NC; as part of this conveyance, a three–party negotiation among the NS users and the NS provider for the purpose of agreeing upon a particular QOS parameter value may take place; and
2)	Parameters not negotiated on a “per–connection” basis –the values of these parameters cannot be conveyed or negotiated among the NS users and the NS provider, for these QOS parameters, however, information about the values which is useful to the NS provider and each NS user may be made known by local means.
	Only two QOS parameters of the NS, throughput and transit delay, are classified in the first category, and thus are conveyed and negotiated by means of the NS.
	(The negotiation procedures and constraints are described in Recommendation X.213. The mechanisms related to the negotiation of these parameters is described in § 7.1.3.1.)
	All of the remaining QOS parameters are classified as belonging to the second category. The values of these QOS parameters for a particular NC are not negotiated in a three–party fashion nor are they directly conveyed from NS user to NS user. As a local matter, however, there may be means by which the values of one or more of these QOS parameters are known and utilized by the NS provider and each NS user.
	(The mechanisms related to this category of parameters are described in § 7.1.3.2.)
7.1.2.2	Data transmission service QOS Parameters
	This section is for further study.
7.1.3	Mechanisms related to QOS
7.1.3.1	Types of mechanisms related to parameters negotiated on a per connection basis
7.1.3.1.1		Three parties are involved in the specification of these QOS parameters:
a)	The service user at the calling QOS reference point,
b)	The service provider between the QOS reference points,
c)	The service user at the called QOS reference point.
7.1.3.1.2		The service user at the calling QOS reference point will initiate these QOS parameters.
7.1.3.1.3		Both the service provider between the reference points and the service user at the called QOS reference point may devalue these QOS parameters according to their capabilities.
7.1.3.1.4		After possible subsequent devaluation, these QOS parameters will be returned to the service user at the calling QOS reference point without further adjustment.
7.1.3.1.5		The returned QOS parameters specify the QOS between the two QOS reference points.
	Note – The guarantee of the QOS during the lifetime of the connection between the two QOS reference points is subject for further study.
7.1.3.2	Types of mechanisms related to parameters not negotiated on a per–connection basis
	Determination of the value of these types of parameters occurs somewhere within the service provider but does not require that the values be negotiated between QRPs. Values of these parameters may be requested through the calling QRP by a service user. It is also possible that the service provider may convey indications of these values to the service user at the calling QRP, called QRP or both QRPs. Unlike the parameters negotiated on a per–connection basis, the values of these parameters are not subject to negotiation mechanisms as described in § 7.1.3.1.
7.1.3.3	Minimum and target QOS parameters
7.1.3.3.1		The specification of QOS parameters (if present) always contains a target QOS value. In addition this specification may contain a minimum QOS value.
7.1.3.3.2		For parameters negotiated on a per–connection basis, target QOS values are subject to negotiation rules specified in § 7.1.3.1.
7.1.3.3.3		Minimum QOS values specify the least value the service user at the calling QOS reference point agrees to for establishment of a connection between the two QOS reference points. The minimum QOS value may be used by the service provider between the QOS reference points to abort the connection establishment, if the target QOS value is devalued to a value less than the minimum QOS value in the case of parameters negotiated on a per–connection basis.
	Note – It is for further study whether the mechanism using minimum QOS parameters is a general applicable mechanism for all parameters.
7.1.3.4	Specific mechanisms related to QOS
	Some mechanisms have already been defined that relate to the quality of service on a call, (e.g. flow control parameters negotiation mechanism in Recommendations X.25 and X.75).
	Note – It is for further study whether there is a need to introduce new user facilities to request a target quality of service for a call and new network utilities to control that target quality of service.
	The optional user facilities already standardized for different data transmission services, and related to the QOS of the call, are shown in Table 7–1/X.301.
7.1.3.4.1	Transit delay
	For calculation and negotiation of Transit Delay, a number of facilities can be utilized:
–	Transit delay selection and indication (TDSAI)
–	End–to–end transit delay negotiation (EETDN), involving three parameters:
–	Cumulative transit delay (CTD)
–	Target transit delay (TTD)
–	Maximum acceptable transit delay (MATD)
TABLE 7–1/X.301
Optional user facilities, standardized for different data transmission services,
related to the QOS of the call

Optional user facility	
Period 	
Applies per 	Applies to circuit switched data transmission service			Applies to packet switched data transmission service			
	of time	call	PTSN	CSPDN	ISDN	ISDN	PSPDN	MSS	
Transit delay selection and indication		X	 	 		X	X	X	
End–to–End transit delay negotiation		X				X	X	X	
Throughput class negotiation	 X	 X
(Note)			FS	 X	X	X	
Minimum throughput class		X				X	X	X	
Default throughput class assignment	 X					X	X	X	
Note – This facility cannot be used unless the corresponding facility has been agreed for a period of time.
	Utilization of these facilities, and their mutual relationship is described in the following sections.
7.1.3.4.1.1	Transit Delay Selection and Indication
7.1.3.4.1.1.1	General
	Transit delay selection and indication is an optional user facility that permits selection and indication, on a per call basis, of the nominal maximum permissible transit delay applicable to that virtual call.
	A DTE wishing to select a nominal maximum permissible transit delay for a virtual call indicates the desired nominal maximum permissible value in the call request phase.
	During the call request phase, the nominal transit delay applicable to the call will be indicated to the called DTE. This transit delay may be smaller than, equal to, or greater than the desired nominal maximum permissible transit delay requested in the call request phase by the calling DTE.
	During the call confirmation phase, the nominal transit delay applicable to the call will also be sent to the calling DTE.
	Note – This facility specifies the transit delay between the QRPs applicable for the data transmission service (see § 7.1.1.2). Provision of transit delay values applicable for the OSI network service (see § 7.1.1.3) may require the use of an additional parameter (see § 7.1.3.4.1.2).
	For internetwork communication, two utilities are defined to handle these facilities:
1)	The nominal maximum permissible transit delay value requested by the DTE is signalled between networks by the transit delay selection utility in the call request phase.
2)	The accumulated expected nominal transit delay up to, and including the outgoing link is signalled in the transit delay indication utility in the call request phase. The accumulated expected nominal transit delay is signalled back in the transit delay indication utility of the call confirmation phase.
7.1.3.4.1.1.2	Transit delay definition
	This transit delay is the data packet transfer delay as defined in § 3.1 in Recommendation X.135, measured between boundaries B2 and Bn–1, as defined in Figure 2/X.135 (that means, excluding the access lines), with the conditions given in § 3.2 in Recommendation X.135, and is expressed in terms of a mean value.
	Nominal maximum permissible transit delay and the expected nominal transit delay is signalled provisionally in milliseconds and expresses the mean value for the packets (128 octet size) sent by the user on that call.
	Note 1 – It is for further study whether the transit delay values shall apply only for busy hour condition.
	Note 2 – The range and the number of reasonable values of the nominal maximum permissible transit delay and the expected nominal transit delay are for further study.
7.1.3.4.1.1.3	Call request anc call confirmation phases
A)	In the call request phase a network, when able to do so, should allocate resources and route the virtual call in a manner such that the nominal transit delay applicable to that call does not exceed the desired nominal maximum permissible transit delay.
1)	In the call request phase, the calling DTE indicates the nominal maximum permissible transit delay in the transit delay selection and indication facility;
2)	In the call request phase on an internetwork link, the network shall, if routing on transit delay is performed, take into consideration both of the values given in the transit delay selection and transit delay indication utilities.
B)	The network shall determine the expected nominal transit delay for the network part of the vitual circuit in question, based on the definition in § 7.1.3.4.1.1.2.
In accordance with the definition of t3c, this includes the expected nominal transit delay for all DSEs and links that the call passes through, taking into consideration such elements as size of DSEs, transmission speed and type of links.
However, determination of the actual values is a national matter.
If the call in question is resulting from an incoming internetwork link call, the determined expected nominal transit delay shall be added to the received value in the transit delay indication utility.
1)	In the case of an incoming call to a DTE, the expected nominal transit delay shall be transmitted to the DTE in the transit delay selection and indication facility.
2)	In the case of a call request on an internetwork link, the expected nominal transit delay shall be signalled in the transit delay indication utility. The transit delay originally requested by the DTE is optionally signalled in the transit delay selection utility.
C)	The total accumulated expected nominal transit delay is signalled back in the transit delay indication utility in the call confirmation phase. This value is transferred by the originating network to the calling DTE in the transit delay selection and indication facility in the call confirmation phase.
During the call request phase the nominal transit delay applicable to the call will be indicated to the called DTE. This transit delay may be smaller than, equal to, or greater than the desired nominal maximum permissible transit delay requested in the call request phase by the calling DTE.
During the call confirmation phase, the nominal transit delay applicable to the call will also be sent to the calling DTE.
7.1.3.4.1.2	End–to–end transit delay negotiation
7.1.3.4.1.2.1	General
	End–to–end transit delay negotiation is an optional user facility that permits on a per call basis conveyance of:
a)	Cumulative transit delay
b)	Target transit delay (TTD) (optional)
c)	Maximum acceptable transit delay (MATD) (optional)
The TTD corresponds with the target QOS parameter (see § 7.1.3.3) for transit delay.
The MATD corresponds with the minimum QOS parameter (see § 7.1.3.3) for transit delay.
	The CTE accumulates the total transit delay applicable for the call by adding the individual transit delays of the subsequent portions of the connection (which may be presented by the transit delay selection and indication facility; see § 7.1.3.4.1).
7.1.3.4.1.2.2	Call request and call confirmation phases
	The CTD will be conveyed from calling to called DTE during the call request phase. Its values will be incremented by transit delays of individual portions of the connection that may be presented by the transit delay selection and indication facility (see § 7.1.3.4.1) or may be obtained from local knowledge. The TTD and MATD may also be conveyed from calling to called DTE during the call request phase, and can be used for comparison with the accumulated value.
	The public networks involved in the call are not required to look at or operate on these parameters, e.g. for aborting the call; however, some networks may look at the parameters if they wish.
	The total accumulated transit delay, when accepted by the called DTE, is conveyed from the called DTE to the calling DTE during the call confirmation phase in the CTE parameter. The TTD and the MATD parameters are not conveyed during the call confirmation phase.
	Figure 7–5/X.301 shows an example of the utilization of all transit delay parameters.
Fig. /T0705580-88

	The labels (a), (b), (c), (d), (e), (f) and (g) represent the various points between the entities involved in the scenario shown above at which the transit delay information is visible in the protocol information.

Facility	Utilities	EETDN	
TDSAI	TDS	TDI	CTD	TTD	MATD	
Call Request Phase		
a)	 t–2d1 (Note 1)	 NA	 NA	 2d1	 t	 w	
b)	 p1	 NA	 NA	 2d1	 t	 w	
c)	 t–2d1–p1–(g1–g2)	 NA	 NA	 2d1+p1+(g1+g2)	 t	 w	
d)	 NA	 t–2d1
–p1
–(g1–g2)	 p2–e	 2d1+p1+(g1+g2)	 t	 w	
e)	 p2–e–p3	 NA	 NA	 2d1+p1+(g1+g2)	 t	 w	
f)	 t–(2d1–p1–(g1–g2))						
	–(g3–g4)–(p2–e–p3)	NA 	NA	2d1+p1+(g1+g2)
+(p2+e+p3)+
(g3+g4) 	t	w	
 g)	 p4	 NA	 NA	 2d1+p1+(g1+g2)
+(p2+e+p3)+
(g3+g4)	 t	w	

Facility	Utilities	EETDN	
TDSAI	TDS	TDI	CTD	TTD	MATD	
Call Confirmation Phase (Note 2)		
g)	NA	NA	NA	 2d1+p1+(g1+g2)
+(p2+e+p3)+
(g3+g4)+p4	NA	NA	
f)	p4	NA	NA	–	NA	NA	
e)	NA	NA	NA	–	NA	NA	
d)	NA	NA	p2–e–p3	–	NA	NA	
c)	p2–e–p3	NA	NA	–	NA	NA	
b)	NA	NA	NA	–	NA	NA	
a)	p1	NA	NA	–	NA	NA	
							
Note 1 – The calling DTE assumes d1 = d2.
Note 2 – The called DTE may have accepted the call on the basis of:
						2d1+p1+(g1+g2)+(p2+e+p3)+2(g3+g4)+p4w.
FIGURE 7–5/X.301
Utilization of the transit delay parameters
7.1.3.4.2		Throughput
7.1.3.4.2.1	Throughput class negotiation (see Note)
	Note –	Different terms exist for this facility:
	The present term is as denoted in Recommendations X.2, X.25 and X.75.
Recommendation X.213 uses the term “throughput”.
Recommendation X.140 uses the term “User information transfer rate”.
Recommendation Q.931 uses the term “Information rate”.
7.1.3.4.2.1.1	General
	Throughput class negotiation is an optional user facility that permits negotiation on a per call basis of the throughput classes. The throughput classes are considered independently for each direction of data transmission.
	Default values are agreed between the DTE and the Administration (see § 7.1.3.4.2.3). The default values correspond to the maximum throughput classes which may be associated with any virtual call at the DTE/DCE interface.
	This facility corresponds with the target QOS parameter (see § 7.1.3.3) for throughput.
7.1.3.4.2.1.2	Throughput definition
	The throughput parameter is defined in Recommendation X.140 (under the term user information transfer rate).
	Throughput is signalled in bits per second. Provisionally, the throughput value negotiated for a call, is achieved, as measured over the lifetime of the call, in 95% of all cases (calls) during busy hour conditions. Details are for further study.
7.1.3.4.2.1.3	Call request and call confirmation phases
	When the calling DTE has subscribed to the throughput class negotiation facility, it may request the throughput classes of the virtual call in the call request phase for both directions of data transmission. If particular throughput classes are not explicitly requested, the DCE will assume that the default values were requested for both direction of data transmission.
	When a called DTE has subscribed to the throughput class negotiation facility, the throughput classes from which DTE negotiation may start will be indicated to the called DTE during the call request phase. These throughput classes are less than or equal to the ones selected at the calling DTE/DCE interface, either explicitly, or by default if the calling DTE has not subscribed to the throughput class negotiation facility or has not explicitly requested throughput class values in the call request phase. These throughput classes indicate to the called DTE will also not be higher than the default throughput classes, respectively for each direction of data transmission, at the calling and the called DTE/DCE interfaces. They may be further constrained by internal limitations of the network.
	The called DTE may request with a facility in the call confirmation phase the throughput classes that should finally apply to the virtual call. The only valid throughput classes in the call confirmation phase are lower than or equal to the ones (respectively) indicated to the call DTE in the call request phase. If the called DTE does not make any throughput class facility request in the call confirmation phase, the throughput classes finally applying to the virtual call will be the ones indicated to the caller DTE in the call request phase.
	If the called DTE has not subscribed to the throughput class negotiation facility, the throughput classes finally applying to the virtual call are less than or equal to the ones selected at the calling DTE/DCE interface, and less than or equal to the default values defined at the called DTE/DCE interface.
	When the calling DTE has subscribed to the throughput class negotiation facility, the call confirmation phase of each call will indicate the throughput classess finally applying to the call.
	When neither calling DTE nor called DTE has subscribed to the throughput class negotiation facility, the throughput classes applying to the virtual call will not be higher than the ones agreed as defaults at the calling and called DTE/DCE interfaces. They may be further constrained to lower values by the network, e.g. for international service.
	In the case of internetwork calls, any DSE, including the DSEs associated with the originating and destination networks, may reduce, but not raise, the throughput class values requested in the call request phase. Thus, the throughput classes from which the negotiation may start with the called DTE will be indicated to the DSE–associated with the destination network.
	If particular throughput classes are not explicitly requested, the DSE is assumed to request the default throughput class values agreed between both Administrations.
	When the called DTE has accepted the call, the DSE associated with the destination network may convey, in the call confirmation phase, the throughput class values that finally apply to the call following the negotiation with the called DTE.
	If particular throughput classes are not explicitly confirmed, the DSE is assumed to confirm the default class values agreed between both Administrations.
	Note – In the process of determination as whether or not to reduce throughput class values by networks or by the user, different criteria can be envisioned, e.g. the resources available. For packet switched data transmission services, flow control parameters like window and packet size may affect the attainable throughput class.
7.1.3.4.2.1.4	Call clearing phase
	No indication of throughput class should be present during the call clearing phase.
7.1.3.4.2.2	Minimum throughput class
7.1.3.4.2.2.1	General
	Minimum throughput class is an optional user facility that permits, on a per call basis, conveyance of the minimum acceptable throughput class. The minimum throughput classes are considered independently for each direction of data transmission.
	This facility corresponds with the minimum QOS parameter (see § 7.1.3.3) for throughput.
7.1.3.4.2.2.2	Call request and call confirmation phases
	The minimum throughput class parameter will be conveyed from calling DTE to called DTE during the Call Request Phase, and can be used by the called DTE for comparison with the negotiated value of the throughput class negotiation parameter.
	The public networks involved in the call are not required to look at or operate on the minimum throughput class parameter, e.g. for aborting the call; however some networks may look at the parameter if they wish.
	The minimum throughput class parameter is not conveyed during the call confirmation phase.
7.1.3.4.2.3	Default throughput classes assignment
	Default throughput classes assignment is an optional user facility agreed for a period of time. This facility, if subscribed to, provides for the selection of default throughput classes from the list of throughput classes supported by the Administration. Some networks may constrain the default throughput classes to be the same for each direction of data transmission. In the absence of this facility, the default throughput classes correspond to the user class of service of the DTE (see Recommendation X.1) but does not exceed the maximum throughput class supported by the network.
	The default throughput classes are the maximum throughput classes which may be associated with any call at the DTE/DCE interface. Values other than the default throughput classes may be negotiated for a call by means of the throughput classes negotiation facility (see § 7.1.3.4.2.1). Values other than the default throughput classes may be agreed for a period of time for each permanent virtual circuit.
7.2	Facilities relating to the charging conditions applying to the call
	The optional user facilities which are standardized for different data transmission services, and are related to the charging conditions applying to the call are shown in Table 7–2/X.301.

TABLE 7–2/X.301
Optional user facilities, standardized for different data transmission services,
related to charging conditions applying to the call

Optional user facility	
Period	
Applies per	Applies to circuit switched data transmission service			Applies to packet switched data transmission service			
	of time	call	PTSN	 CSPDN	ISDN	 ISDN	PSPDN	MSS	
Reverse charging		X		X		X	X	X	
Reverse charging acceptance	 X			 X	FS	X	X	X	
Local charging prevention	 X		 			X	X	X	
Charging information	X	X		X		X	X	X	
									
7.2.1	Reverse charging and reverse charging acceptance
7.2.1.1	General
	Reverse charging is an optional user facility that may be requested by the user on a per–call basis. It enables a calling user to request that the call should be charged to the called user.
	Reverse charging acceptance is an optional user facility assigned to the user for an agreed contractual period. It enables the user to accept reverse charging calls.
	Note 1 – The international accounting arrangements for reverse charging calls and the consequent implications on network capabilities have not yet been defined.
	Note 2 – All requirements of the reverse charging and reverse charging acceptance facilities have not yet been covered in the DTE/DCE interface and interexchange signalling specifications.
7.2.1.2	Call set–up procedure
7.2.1.2.1		A calling user may request reverse charging by means of a facility request over the DTE/DCE interface.
a)	In the case where reverse charging is allowed by the originating network, the call control information forwarded to the succeeding exchange will include a reverse charging request indication.
b)	In the case where reverse charging is not allowed by the originating network, the call is rejected and an invalid facility request call progress signal is returned to the calling user.
7.2.1.2.2		When receiving a call including a reverse charging request indication the destination exchange will act as follows:
a)	In the case where the called user subscribes to the reverse charging acceptance facility, the incoming call information, including an indication that reverse charging is requested, is sent to the called user.
b)	In the case where the called user does not subscribe to the reverse charging acceptance facility, the call is rejected and a reverse charging acceptance not subscribed signal is sent towards the originating exchange.
	The call may also be rejected for other reasons not related to the reverse charging or reverse charging acceptance facilities.
	When the incoming call information is sent to the called user, the called user may deny establishment of the call by clearing, if the called user is not willing to accept reverse charging for this particular call.