InfoMagic Standards 1993 July/Disc.iso/ccitt/1992/x/x301_1.asc

Text File | 1993-08-17 | 87.2 KB | 2,896 lines

C:\WINWORD\CCITTREC.DOT_______________

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 PROVI-
SION 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 appli-
cable to different types of DTE/DCE interfaces on PDNs and that Recom-
mendations 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 inter-
working 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 inter-
working 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 opera-
tional 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 interna-
tional 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 net-
works;

unanimously recommend

    that arrangements for call control interworking between public net-
works and between public networks and other networks, and that the neces-
sary 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 Rec-
ommendation.

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 interwork-
ing between public networks, and between public networks and other net-
works 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 ser-
vices. Only those arrangements are described that may (also) have signifi-
cance 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 internet-
work 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 opera-
tion, and which are not visible for endûusers, are not described in this Rec-
ommendation. 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 facili-
ties in PDNs and ISDNs,

X.10            Categories of access for data terminal equipment (DTE) to pub-
lic data transmission services,

X.20            Interface between data terminal equipment (DTE) and Data Cir-
cuitûterminating Equipment (DCE) for starûstop transmission
services on PDNs,

X.20 bis            Use on PDNs of DTE which is designed for interfacing to asyn-
chronous duplex VûSeries modems,

X.21            Interface between data terminal equipment (DTE) and Data Cir-
cuitûTerminating Equipment (DCE) for synchronous operation
on PDNs,

X.21 bis            Use on PDNs of DTE which is designed for interfacing to syn-
chronous VûSeries modems,

X.22            Multiplex DTE/DCE interface for user classes 3û6,

X.25            Interface between data terminal equipment (DTE) and data Cir-
cuitûterminating equipment (DCE) for terminals operating in
the packetûmode and connected to public data networks by ded-
icated 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 net-
work through a public switched telephone network or an inte-
grated 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 ser-
vices on internatinal circuits between anisochronous data net-
works,

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 pub-
lic 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 ser-
vice,

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 net-
works for the provision of data transmission services,

X.302            Description of the general arrangements for internal network utili-
ties within a subnetwork and between subnetworks for the pro-
vision 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 opera-
tional signals may be generated towards the interconnected network to the
extent allowed by the signalling arrangements provided in the intercon-
nected 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 net-
works 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 rel-
evant 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 Recommen-
dations 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 sys-
tems 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 sig-
nalling 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 internet-
work operation. In particular, a network may wish to note the exact circum-
stances 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 sig-
nals 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 transmis-
sion 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 net-
work 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 pro-
cess 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 sec-
tion; for example, when accessing a packet switching network from a circuit
switched network, the complete establishment of the switched access is usu-
ally required before the virtual call can be requested. Following the princi-
ple indicated in this section, provision should be made within the
appropriate internetwork signalling Recommendations, for the establish-
ment of direct calls between both end users whenever it is possible. Conse-
quently, 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 facili-
ties 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 clear-
ing to the adjacent networks, unless they are already informed of that clear-
ing. 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 provi-
sion of data transmission services. This comprises addressing information
defined in Recommendation E.164, Recommendation X.121 and any addi-
tional 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


Peri
od


Appli
es per

Applies to circuit
switched data
 transmission service

Applies to packet
switched data
 transmission service



of
tim
e

 call


PTSN


CSPD
N


ISDN


ISDN


PSPD
N


MSS



Calling line
identification

 X

X

Calling line
identification

 X

 X
(Note)

 X

FS

Network
address exten-
sion (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 Recommenda-
tion X.121 is used by PDNs and Recommendation E.164 is used by the tele-
phony 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 indi-
cation 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 pro-
tocol 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 internet-
work 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 Recommen-
dation 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

Directio
n

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 differ-
ent numbering plan. Prefixes may or may not preceed the escape digit.

Note 7 û For protocol elements used, see Appendix I to this Recommenda-
tion.

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 net-
work is not always able to indicate the X.121 calling address to the data net-
work. 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 identifica-
tion 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 Recommenda-
tion).

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 Recog-
nized 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 con-
trol 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 call-
ing line identification facility, the originating exchange
responds with the calling line which is forwarded by the desti-
nation exchange to the called user in accordance with the appli-
cable 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 Recommen-
dation X.302). In this case, the identification sent by the desti-
nation 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 decentral-
ized 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 call-
ing address, when provided. In the case where the calling address is con-
veyed 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 indi-
cating 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. How-
ever, this transfer may not be technically possible through some current net-
works; 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 infor-
mation 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) sig-
nalling 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 proce-
dures in the calling party number information element contained in the
SETUP message sent to the called party across the DûChannel (see Recom-
mendation 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 desti-
nation 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 identifi-
cation 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 trans-
ferred. 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 con-
tractual 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 accor-
dance 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 signal-
ling 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 stan-
dardized 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 desti-
nation 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ûdirec-
tion 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 men-
tioned 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 inter-
face 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 Recommenda-
tion 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 for-
mats 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 oper-
ation.

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 men-
tioned 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 net-
work/user interface and interexchange interfaces.

    For example, on an ISDN interface, the same address may be repre-
sented in either one of the ways illustrated in a) or b) and/or c) or d) of Fig-
ure 6û3/X.301.

Fig.T0705530-88



    This example illustrates the use of a prefix, as recognized in Recommenda-
tion 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 infor-
mation 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 address-
ing 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

Peri
odo
f


Applies
 per

 Applies to cir-
cuit switched
data transmission
service

 Applies to
packet switched
data transmission
service



tim
e

call

PTS
N

CSP
DN

ISD
N

ISD
N

PSP
DN

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 con-
cerned, this constitutes an alternative capability, available on a per call basis
without requiring the NAE mechanism, for the transfer of addressing infor-
mation additional to that defined in Recommendation X.121/E.164.

    Note û Different terms exists: In general, NAE is used in XûSeries Recom-
mendations, and subaddress is used in IûSeries Recommendations.

6.8.2    Realization

    The detailed realization of the NAE mechanism at each type of inter-
network and user interface is independently defined in the appropriate sig-
nalling 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 dur-
ing 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/sub-
address 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 exist-
ing protocol elements for addressing.

c)    The addressing information is split into two elements, one con-
tained 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 net-
works 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 Recom-
mendations).

    Note 3 û General arrangements for treatment of registration proce-
dures (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 ser-
vice. 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 mea-
sured 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 net-
works.

    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 mea-
sured 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 con-
nections 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 regard-
ing which class of transport protocol should be used on top of a given net-
work connection.

7.1.1.2        QOS Specification in the data transmission service

    Figure 7û3/X.301 illustrates an example of the data transmission ser-
vice 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 transmis-
sion 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 pro-
vider 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 ser-
vice may have the effect of either devaluing or improving the QOS depend-
ing 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 out-
side 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 ser-
vice 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 val-
ues 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 catego-
ries 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 clas-
sified in the first category, and thus are conveyed and negotiated by means
of the NS.

    (The negotiation procedures and constraints are described in Recommenda-
tion 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 sec-
ond 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 con-
nection 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 ser-
vice user at the called QOS reference point may devalue these QOS parame-
ters 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 some-
where 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 net-
work 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 ser-
vices,
related to the QOS of the call






Optional user
facility


Peri
od


Applie
s per

Applies to circuit
switched data
transmission ser-
vice

Applies to packet
switched data
transmission ser-
vice



of
tim
e

call

PTS
N

CSP
DN

ISD
N

ISD
N

PSP
DN

MSS



Transit delay
selection and
indication

X





X

X

X

EndûtoûEnd
transit delay
negotiation

X

X

X

X

Throughput
class negotia-
tion

 X

 X
(Note)

FS

 X

X

X

Minimum
throughput
class

X

X

X

X

Default
throughput
class assign-
ment

 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 per-
missible 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 selec-
tion utility in the call request phase.

2)    The accumulated expected nominal transit delay up to, and includ-
ing the outgoing link is signalled in the transit delay indication util-
ity 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 Rec-
ommendation 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 tran-
sit 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 allo-
cate 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 consid-
eration 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 defi-
nition 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 indi-
cation 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 appli-
cable 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 add-
ing the individual transit delays of the subsequent portions of the connection
(which may be presented by the transit delay selection and indication facil-
ity; 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 selec-
tion 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 oper-
ate 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 confirma-
tion 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 tran-
sit 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 negoti-
ation 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 inter-
face.

    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 through-
put 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 facil-
ity, 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 sub-
scribed to the throughput class negotiation facility or has not explicitly
requested throughput class values in the call request phase. These through-
put 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 con-
strained 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 negotia-
tion 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 Adminis-
trations.

    Note û In the process of determination as whether or not to reduce through-
put class values by networks or by the user, different criteria can be envi-
sioned, 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 direc-
tion 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 oper-
ate 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 ser-
vices,
related to charging conditions applying to the call






Optional user
facility


Peri
od


Applie
s per

Applies to circuit
switched data
transmission ser-
vice

Applies to packet
switched data
transmission ser-
vice



of
tim
e

call

PTS
N


CSP
DN

ISD
N


ISD
N

PSP
DN

MSS



Reverse charg-
ing

X

X

X

X

X

Reverse charg-
ing acceptance

 X

 X

FS

X

X

X

Local charging
prevention

 X



X

X

X

Charging infor-
mation

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 charg-
ing calls and the consequent implications on network capabilities have not
yet been defined.

    Note 2 û All requirements of the reverse charging and reverse charg-
ing acceptance facilities have not yet been covered in the DTE/DCE inter-
face 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 net-
work, 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 indica-
tion 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 orig-
inating 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 will-
ing to accept reverse charging for this particular call.