.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\"                 Not Copyright ( c) 1991 
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P

.rs
\v | 5i'
.sp 1P
.ce 1000
\v'12P'
\s12PART\ III
\v'4P'
.RT
.ce 0
.sp 1P
.ce 1000
\fBI.300\(hySeries Recommendations\fR \v'2P'
.ce 0
.sp 1P
.ce 1000
\fBOVERALL\ NETWORK\ ASPECTS\ AND\ FUNCTIONS\fR 
.ce 0
.sp 1P
.LP
.rs
.sp 31P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.LP
\fBMONTAGE: PAGE 2 = PAGE BLANCHE\fR 
.sp 1P
.RT
.LP
.EF '%	Fascicle\ III.8\ \(em\ Rec.\ I.310''
.OF '''Fascicle\ III.8\ \(em\ Rec.\ I.310	%'
.LP
.bp
.sp 1P
.ce 1000
\v'3P'
SECTION\ 1
.ce 0
.sp 1P
.ce 1000
\fBNETWORK\ FUNCTIONAL\ PRINCIPLES\fR \v'6p'
.ce 0
.sp 1P
.sp 2P
.LP
\fBRecommendation\ I.310\fR 
.RT
.sp 2P
.sp 1P
.ce 1000
\fBISDN\ \(em\ NETWORK\ FUNCTIONAL\ PRINCIPLES\fR 
.EF '%	Fascicle\ III.8\ \(em\ Rec.\ I.310''
.OF '''Fascicle\ III.8\ \(em\ Rec.\ I.310	%'
.ce 0
.sp 1P
.ce 1000
\fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR 
.sp 9p
.RT
.ce 0
.sp 1P
.LP
\fB1\fR 	\fBGeneral\fR 
.sp 1P
.RT
.sp 1P
.LP
1.1
	\fIBasic philosophy of the functional description\fR 
.sp 9p
.RT
.PP
The objective of this Recommendation is to provide a common
understanding of the ISDN capabilities, including terminal, network and
specialized service centre aspects.
.PP
A functional description of ISDN capabilities must allow a clear
distinction between definition/specification aspects of services provided by
the ISDN and the actual specification of the equipment utilized to support
those services. Therefore, an implementation\(hyindependent approach should be
adopted.
.PP
Moreover in the context of this Recommendation the adjective
\*Qfunctional\*U is used in the sense of an implementation\(hyindependent 
approach. 
The noun \*Qfunction\*U itself has a specific meaning which is explained
below.
.PP
The description of network capabilities is consistent with the
protocol reference mode, e.g.:
.RT
.LP
	\(em
	the layering structure of all systems involved in a
communication process, i.e.\ partitioning the required functions between
different layers;
.LP
	\(em
	 the clear discrimination between layer service concept, layer function 
concept and layer protocol concept. 
.PP
Furthermore, the three following distinctions apply:
.LP
	\(em
	distinction between basic services and supplementary
services;
.LP
	\(em
	distinction between ISDN capabilities and services offered to the customer;
.LP
	\(em
	distinction between static and dynamic aspects of the
description.
.sp 1P
.LP
1.2
	\fIServices supported by an ISDN\fR 
.sp 9p
.RT
.PP
The concepts and the principles of an ISDN are described in
Recommendation\ I.120. The services supported by an ISDN are given in the
I.200\(hySeries of Recommendations. A classification and the tools for the
description of telecommunication services are specified in Recommendation\ 
I.210 according to the description method as given in Recommendation\ I.130. 
The 
network capabilities to support these services are defined in the I.300\(hySeries 
of Recommendations. The relationship between these Recommendations and 
some 
other relevant I\(hySeries Recommendations is shown in
Figure\ 1/I.310.
.bp
.RT
.LP
.rs
.sp 22P
.ad r
\fBFigure 1/I.310, (N), p.\fR 
.sp 1P
.RT
.ad b
.RT
.PP
It should be noted that the service concept defined in
Recommendation\ I.210 is different from the layer service concept of the
OSI\ model. The telecommunication service concept in Recommendation\ I.210
corresponds to the services offered to users by the network. Besides
operational and commercial aspects, the provision of these telecommunication
services (bearer and teleservices) and associated supplementary services
requires the availability of appropriate capabilities:
.LP
	\(em
	network capabilities, in various network equipments
(exchanges\ etc.);
.LP
	\(em
	terminal capabilities;
.LP
	\(em
	specialized service centre capabilities, when
required.
.sp 1P
.LP
1.3
	\fIGeneric description of required capabilities\fR 
.sp 9p
.RT
.PP
ISDN capabilities are the total sum of the functions required to
support all basic and supplementary services offered by the ISDN.
.RT
.sp 1P
.LP
1.3.1
	\fIStatic description\fR 
.sp 9p
.RT
.PP
The identification and characterization of these functions, which are related 
to the specification and analysis of these basic and supplementary services, 
form the first step of the generic description. This part of the 
generic description is intrinsically static.
.RT
.sp 1P
.LP
1.3.2
	\fIDynamic description\fR 
.sp 9p
.RT
.PP
The use of a basic or supplementary service generally requires
cooperation between functions located in different equipment.
.PP
The static description of the ISDN capabilities, which will be a list of 
functions, is not sufficient. It is necessary, in addition, to depict the 
sequence of events and the activation of functions coordinated by suitable
inter\(hyequipment signals. This second step is the dynamic aspect of the
description. This involves firstly an identification and characterization of
the functions and then a method of showing the dynamic interaction between
functions.
.bp
.RT
.sp 2P
.LP
\fB2\fR 	\fBObjectives of the\fR 
\fBfunctional description of the ISDN\fR 
.sp 1P
.RT
.PP
As described in Recommendation\ I.120, an Integrated Services
Digital Network (ISDN) is a network providing 
end\(hyto\(hyend digital
connectivity
to support a wide range of telecommunication services.
.PP
The characterization of ISDN is centered on three main
areas:
.RT
.LP
	a)
	 the standardization of services offered to users, so as to enable services 
to be internationally compatible; 
.LP
	b)
	the stadardization of user\(hynetwork interfaces, so as
to enable 
terminal equipment to be portable
[and to assist in a)];
.LP
	c)
	the standardization of ISDN capabilities to the degree
necesary to allow user\(hynetwork and network\(hynetwork interworking, and thus
achieve\ a) and\ b) above.
.PP
The I.200\(hySeries of Recommendations identifies the range of
telecommunication services to be offered in an ISDN, namely bearer services,
teleservices, and associated supplementary services and the attributes
characterizing those services. The I.400\(hySeries of Recommendations describes
both the functional and technical aspects of user\(hynetwork interfaces. This
Recommendation defines the ISDN capabilities to support services via interfaces 
in terms of functions. A functional description enables a decoupling of 
services and ISDN capabilities, and therefore allows an
implementation\(hyindependent approach.
.PP
The principal objectives of the ISDN functional method
are:
.RT
.LP
	1)
	 to define the ISDN capabilities, by building up a harmonized set of functions 
that are necessary and sufficient to support telecommunication services 
by their static and dynamic description; 
.LP
	2)
	to aid the evolution of ISDN capabilities (modifications,
addition of capabilities to support new basic or supplementary services), by
organizing this set of functions in an open\(hyended and modular structure;
.LP
	3)
	 to aid the standardization of system\(hyindependent switching functions 
between exchanges of differing designs and manufacture; 
.LP
	4)
	 to aid the standardization of interworking standards between switching 
systems located in different countries; 
.LP
	5)
	to provide information for the preparation of functional
specifications for new telecommunication services;
.LP
	6)
	to maximize the exploitation of functions provided and
available in switching systems.
.PP
The transition from an existing network to a comprehensive ISDN
may require a period of time extending over one or more decades. Therefore 
the design of an ISDN will be revolutionary, adding capabilities in a flexible 
and modular manner. An ISDN may therefore be expected to provide an open\(hyended 
set of functional capabilities able to accommodate new needs as they arise 
at 
acceptable cost.
.PP
During a long intermediate period, some functions may not be
implemented within a given ISDN. Also, specific arrangements should be 
used to ensure compatibility with existing networks and services. An ISDN 
should also give access to existing services and interwork with existing 
networks and 
terminals.
.RT
.sp 2P
.LP
\fB3\fR 	\fBGeneric description model\fR 
.sp 1P
.RT
.sp 1P
.LP
3.1
	\fIGeneral concepts\fR 
.sp 9p
.RT
.PP
The ISDN functional description defines a set of capabilities which enable 
bearer and teleservices to be offered to users (see 
Recommendation\ I.210). The services require two different levels of ISDN
capabilities viz.:
.RT
.LP
	\(em
	the low\(hylayer functions (LLF) relate to the bearer services;
.LP
	\(em
	 the high\(hylayer functions (HLF) together with the lower layer functions 
relate to the teleservices. 
.PP
In addition, operation and maintenance capabilities are required to support 
both bearer and teleservices (see Figure\ 2/I.310). 
.bp
.LP
.rs
.sp 18P
.ad r
\fBFigure 2/I.310, (N), p.\fR 
.sp 1P
.RT
.ad b
.RT
.PP
The capabilities of the ISDN need a detailed and rigorous
characterization because there is a wide range of standardization issues
involved.
.PP
To achieve the functional objectives described in \(sc\ 2, the ISDN
functional description has been designed to:
.RT
.LP
	\(em
	define the overall functional characteristics of the
ISDN;
.LP
	\(em
	be implementation\(hyindependent and place no constraints on
national network architectures beyond the network and interface standards 
given in the I\(hySeries of Recommendations; 
.LP
	\(em
	take full account of the constraints of existing dedicated
networks;
.LP
	\(em
	support the 
layering protocol
concepts defined in
Recommendation\ I.320.
.PP
For this purpose the concept of an 
ISDN function
is used, which is defined as:
.PP
\*QA distiguishing characteristic which describes functional
capabilities of a given equipment, or system, or network, as seen from the
designer point of view.\*U
.PP
As far as possible, the number of functions should be
limited.
.RT
.sp 2P
.LP
3.2
	\fIStatic description model\fR 
.sp 1P
.RT
.sp 1P
.LP
3.2.1
	\fIGlobal functions (GF)\fR 
.sp 9p
.RT
.PP
The description of ISDN capabilities concerns the low layers (1\(hy3) in 
a global context (see Note), i.e.\ taking into account all the equipment 
involved in the communication, according to the protocol reference model. In
this context, a global function is defined as:
.RT
.LP
	\(em
	referring to the ISDN capabilities;
.LP
	\(em
	having a global significance in the lower layers.
.PP
The set of all GFs leads to the description of the total ISDN low layer 
capabilities. 
.PP
\fINote\fR \ \(em\ This concept of global function may be extended to describe 
the higher layer capabilities of ISDN terminals (and network capabilities, 
where these exist). In this case the GF has a global significance inside the
higher layers.
.bp
.RT
.LP
.rs
.sp 13P
.ad r
\fBFigure 3/I.310, (N), p.\fR 
.sp 1P
.RT
.ad b
.RT
.PP
There are two kinds of GFs:
.LP
	\(em
	the 
Basic Global Functions
(BGF), are those global
functions needed to support ISDN basic services. The BGFs are
related to ISDN connection types, as indicated in
Table\ 1/I.310;
.LP
	\(em
	the 
Additional Global Functions
(AGF), are related
to the ISDN capability to support supplementary services.
Details of the relationship between AGFs and the ISDN
capability to support supplementary services are given in
\(sc\ 4.1.2.
.sp 1P
.LP
3.2.2
	\fIElementary functions\fR \fI(EF)\fR 
.sp 9p
.RT
.PP
The introduction of the GF concept allows a general description of low 
layer capabilities. 
.PP
The following is a more detailed description: for each GF, a set of
elementary functions is identified as the set of basic elements which are 
then \fIallocated\fR to different functional entities involved in the 
communication.
.PP
GF\ =\ (EF1,\ EF2,\ EF3,\ . |  | \ EFn)
.PP
An EF within this Recommendation is the lowest level of
functionality. It is allocated to a functional entity involved in supporting 
a telecommunication service. An EF is an intrinsically static description 
of the capability of performing an action on a resource when defined conditions 
are 
met.
.PP
For building up a GF, each associated EF must be present in one or
more functional entities of the ISDN. (In this context the ISDN may include 
the terminals, the network or specialized service centres.) But in a specific 
functional entity the complete set of associated EFs need not be present 
(see for example Figure\ 4/I.310). 
.RT
.LP
.rs
.sp 14P
.ad r
\fBFigure 4/I.310, (N), p.\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
3.2.3
	\fIAllocation of EFs\fR 
.sp 9p
.RT
.PP
This flexibility in construction of EFs allows a specialization of the 
functions to be allocated to particular functional entities. Because the 
Recommendations on the architecture of the ISDN (Recommendation\ I.324) will
only specify a functional approach to standardization, the relationship 
between functional entities and specific equipment is, in general, a national 
matter. However an important first step in allocation of functions will 
be the 
distinction between terminal equipment and the network equipment
involved.
.PP
Recommendation I.324 introduces the functional grouping CRF
(connection related functions). The CRF can be local, national transit or
international transit. EFs can be associated with each of these.
.RT
.sp 1P
.LP
3.3
	\fIDynamic description model\fR 
.sp 9p
.RT
.PP
The complete description of ISDN capabilities must include dynamic aspects 
involved in the process of a call. 
.PP
This association of functional and protocol aspects leads to the use of 
the following dynamic description method: 
.RT
.sp 1P
.LP
3.3.1
	\fIInformation flow diagrams\fR 
.sp 9p
.RT
.PP
The operation of basic and supplementary services are described and characterized, 
as seen from a network point of view, by using information flow diagrams 
which show the sequence of events occurring in the course of the 
call.
.RT
.sp 1P
.LP
3.3.2
	\fIExecutive processes\fR 
.sp 9p
.RT
.PP
An executive process (EP) corresponds to the particular use of
one or more elementary functions within a particular functional entity which
always yields specific results. Therefore an EP is characterized by input
information it needs for execution and by output information or actions
resulting from execution.
.PP
Executive processes involve (see Figure\ 5/I.310):
.RT
.LP
	a)
	sequences that link together events producing the activation
of an EP, by means of signalling information passed between
the function entities;
.LP
	b)
	the information (or data) actually used:
.LP
	\(em
	protocol information (signalling information sent or
received by the component);
.LP
	\(em
	component information (\*Qnetwork information\*U);
.LP
	\(em
	static information (description of available resources,
environment, services,\ etc.)
.LP
	\(em
	dynamic information (elaborated and used during the
call handling).
.PP
The dynamic description of each basic or supplementary service as required 
in stage\ 2 of the description method given in Recommendation\ I.130, 
based on the above elements, results in a chart showing functional entities
involved (e.g.\ associated with originating and destination exchanges,
specialized service centres when required), the signalling information flow
passed between them, and the executive processes used inside them.
.sp 2P
.LP
\fB4\fR 	\fBUse of\fR 
\fBgeneric description model\fR 
.sp 1P
.RT
.PP
The analysis of telecommunication services and technological
development leads to the identification of the range of required
functions.
.PP
The analysis of all the basic and supplementary services provided by the 
ISDN will lead to the establishment of a set of elementary functions which 
can be allocated to different functional entities. 
.PP
The design of a new basic or supplementary service should maximize the 
use of the set of existing EFs available to existing systems. This will 
minimize changes to the systems necessary for introducing these new services. 
The specifications for new equipment designed for providing particular 
services will have to comply with the set of EFs required for these
services.
.bp
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure 5/I.310, (N), p. 5\fR 
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
4.1
	\fIIdentification of\fR 
\fIISDN global functions\fR 
.sp 1P
.RT
.sp 1P
.LP
4.1.1
	\fIBasic global functions (BGF)\fR 
.sp 9p
.RT
.PP
The basic global functions correspond to the ISDN capability to
provide the various connection types that support telecommunication
services.
.PP
The functions implemented to support telecommunication services can be 
classified into the following categories: 
.RT
.LP
	\(em
	\fIConnection handling:\fR  | functions which enable the
establishment (set\(hyup), holding and release of connections
(e.g.\ user\(hyto\(hynetwork signalling).
.LP
	\(em
	\fIRouting:\fR  | functions that determine a suitable connection
for a particular service (call) request, i.e.\ suitable paths between the
various equipments and inside the switching systems to establish end\(hyto\(hyend 
connections (e.g.\ called number analysis).
.LP
	\(em
	 \fIResources handling:\fR  | functions that enable the control of the 
resources necesary for the use of connections (e.g.\ transmission equipment, 
switching resources, data storage equipment). 
.LP
	\(em
	\fISupervision:\fR  | functions that check the resources used to
support the connections, to detect and signal possible problems and to solve
them if possible (e.g.\ transmission error detection and correction).
.LP
	\(em
	\fIOperation and maintenance:\fR  | functions providing the
capability to control the correct working of the services/network as well 
for the subscribers as for the Administration. 
.LP
	\(em
	\fICharging:\fR  | functions providing the capability to the
Administration to charge the subscribers.
.LP
	\(em
	 \fIInterworking:\fR  | functions providing the capability for both service 
and network interworking. 
.LP
	\(em
	\fILayer 2 and 3 data unit handling:\fR  | functions providing
handling of layers\ 2 and\ 3 data units during the information transfer 
phase for the case of packet mode connections. 
.PP
According to this classification, a basic global function is
defined as:
.LP
	\(em
	referring to an ISDN connection type;
.LP
	\(em
	belonging to one of the above categories.
.PP
Table 1/I.310 shows the total set of BGFs.
.bp
.ce
\fBH.T. [T1.310]\fR 
.ce
TABLE\ 1/I.310
.ce
\fBISDN basic global functions\fR 
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
 {
Connection
type
Category
 }	CT 1	CT 2	. |  | 	CT n
_
.T&
lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
Connection handling	1 BGF 1	2 BGF 1		n BGF 1
_
.T&
lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
Routing	1 BGF 2	2 BGF 2		n BGF 2
_
.T&
lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
Resources handling	1 BGF 3	2 BGF 3		n BGF 3
_
.T&
lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
Supervision	1 BGF 4	2 BGF 4		n BGF 4
_
.T&
lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
Operation and maintenance	1 BGF 5	2 BGF 5		n BGF 5
_
.T&
lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
Charging	1 BGF 6	2 BGF 6		n BGF 6
_
.T&
lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
Interworking	1 BGF 7	2 BGF 7		n BGF 7
_
.T&
lw(72p) | cw(42p) | cw(36p) | cw(42p) | cw(36p) .
 {
Layer 2 and 3 data unit handling
 }	1 BGF 8	2 BGF 8		n BGF 8
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 1/I.310, [T1.310], p.\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.sp 3
.sp 1P
.LP
4.1.2
	\fIAdditional global functions (AGF)\fR 
.sp 9p
.RT
.PP
The additional global functions corresponds to the ISDN capability to support 
supplementary services. 
.PP
The classification of AGFs is based on the principle that the support of 
a supplementary service is considered as being realized by a number of 
functions distributed throughout the ISDN. The definition of AGFs needs
further study.
.RT
.sp 1P
.LP
4.2
	\fIIdentification of\fR 
\fIISDN elementary functions\fR 
.sp 9p
.RT
.PP
Like GFs, there are two kinds of elementary functions: the basic
EFs (i.e.\ components of BGFs, and possibly AGFs) and the additional EFs
(i.e.\ components of AGFs). Therefore, identification of basic EFs requires a
detailed analysis of connection types. Implementation and identification of
additional EFs requires a detailed analysis of supplementary services
implementation.
.RT
.LP
	\(em
	\fIBasic EFs:\fR  | for each connection type, there are up to
8\ BGFs to implement (see Table\ 1/I.310). Therefore each BGF is composed of
basic EFs related to this connection type. However some basic EFs may be 
common to several connection types (e.g.\ \*Qcalled number analysis\*U 
belonging to the BGF \*Qrouting\*U). 
.LP
	\(em
	\fIAdditional EFs:\fR  | additional EFs form a common set of
functional elements available to build up the various AGFs, and thus to
implement supplementary services.
.bp
.PP
This grouping of EFs into sets of BGFs and AGFs is illustrated in Figure\ 
6/I.310. 
.PP
The list of EFs so far identified is contained in Annex\ A, together
with a preliminary set of definitions.
.RT
.LP
.rs
.sp 28P
.ad r
\fBFigure 6/I.310, (N), p.\fR 
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
4.3
	\fIIdentification of\fR 
\fIISDN executive processes\fR 
.sp 9p
.RT
.PP
A possible use of the concept of an Executive Process (EP) is the definition 
of Functional Components (FC) as executive processes that can be invoked 
by the network to realize a telecommunication service. 
.PP
According to this an FC is a specific example of how to use the EP
concept.
.PP
A functional component is a set of elementary functions performed in an 
order that yields a specified result. An FC always has an invoking and 
a 
responding entity. The 
invoking entity
is the entity which acts in
response to an FC request from an invoking entity.
.PP
In defining an FC, the following guidelines should be
considered:
.RT
.LP
	\(em
	 FCs are used as building blocks and may be invoked in order to realize 
a telecommunication service. FCs will have signalling impact and 
should be structured in such a way that several telecommunication services 
can use them. In particular, the definition of an FC should as far as possible 
be independent of any connection type. 
.LP
	\(em
	A new FC should not be defined if its functionality can be
provided by one or more existing FCs. As an objective, an FC will not invoke
another FC.
.PP
The relationship between an FC and EFs is shown in
Figure\ 7/I.310.
.bp
.LP
.rs
.sp 14P
.ad r
\fBFigure 7/I.310, (N), p.\fR 
.sp 1P
.RT
.ad b
.RT
.PP
Once invoked, the responding entity will not be affected by
unsolicited inputs from the invoking entity. However, the request for
execution of an FC may be cancelled by the invoking entity if the request
was received.
.PP
It should also be noted that the functionality of an FC could be
invoked by a user equipment, i.e.\ the invoking entity of an FC could be
allocated to user equipment. When an FC affects the user\(hynetwork interface a
service description is needed. Figure\ 8/I.310 illustrates FCs affecting
different interfaces, FC1 affecting the user\(hynetwork interface, FC2 
affecting an internal network interface. It also illustrates that the invoking 
and 
responding entities of different FCs may appear in the same functional
entity.
.RT
.LP
.rs
.sp 17P
.ad r
\fBFigure 8/I.310, (N), p.\fR 
.sp 1P
.RT
.ad b
.RT
.PP
FCs are building blocks, which by themselves are not sufficient to provide 
a service. There is a need for some logic reflecting how FCs are 
coordinated in order to support a given service: this logic is termed
service control
. Service control is an example of the application
process concept which can be found in other Recommendations.
.PP
Annex B gives descriptions of FCs so far identified for the
ISDN.
.bp
.RT
.sp 2P
.LP
\fB5\fR 	\fBFunctional realization of\fR 
\fBbasic service requests\fR 
.sp 1P
.RT
.PP
From the functional point of view, the process involved in
satisfying a basic service request in the ISDN can be described as
follows:
.RT
.LP
	a)
	A basic service request contains a set of attribute values.
The appropriate connection type(s) to support the service
must be identified.
.LP
	Service request examination:
.LP
	\(em
	input: service request containing a set of attribute
values;
.LP
	\(em
	process: examine service request and determine
appropriate connection type(s);
.LP
	\(em
	output: connection type(s).
.LP
	b)
	Once selected, the connection type (which has end\(hyto\(hyend
significance) can be further broken down into one or more
smaller functional components called \*Qconnection elements\*U
(see Recommendation\ I.324).
.LP
	Connection element selection:
.LP
	\(em
	input: connection type;
.LP
	\(em
	process: determine connection element(s) to form the
connection type;
.LP
	\(em
	output: connection element(s).
.LP
	c)
	Each connection element would require a set of functions in
order to be established.
.LP
	Function set determination:
.LP
	\(em
	input: connection element;
.LP
	\(em
	process: select appropriate functions to establish
connection element;
.LP
	\(em
	output: set of functions.
.ce 1000
ANNEX A
.ce 0
.ce 1000
(to Recommendation I.310)
.sp 9p
.RT
.ce 0
.LP
A.1
	 \fIList of identified basic elementary functions and additional\fR \fIelementary 
functions (EFs) for the ISDN\fR 
.sp 1P
.RT
.sp 2P
.LP
A.1.1
	\fIBASIC EFs related to connection types\fR 
.sp 1P
.RT
.sp 1P
.LP
	\fIConnection handling\fR 
.sp 9p
.RT
.LP
	BEF100
	Characteristics of service requested
examination
.LP
	BEF101
	Connection elements type determination
.LP
	BEF102
	User\(hynetwork access resources reservation
(channels)
.LP
	BEF103
	Transit resources reservation
.LP
	BEF104
	Communication references handling
.LP
	BEF
104\ E:
	Establish call reference
.LP
	BEF
104\ C:
	Clear call reference
.LP
	BEF105
	Establishment control
.LP
	BEF
105\ R:
	Establish connection\(hyreturn path only
.LP
	BEF
105\ F:
	Establish connection\(hyforward path
.LP
	BEF
150\ B:
	Establish connection\(hyboth directions
.LP
	BEF106
	Release control
.LP
	BEF107
	Service related authorizations examination
.LP
	BEF108
	User\(hynetwork signalling handling (layer\ 3)
.LP
	BEF109
	Inter\(hyexchange signalling handling (user part)
.LP
	BEF110
	Supplementary services compatibility checking
.LP
	BEF111
	Building up of and maintaining dynamic information
relating to the call/connection
.LP
	BEF112
	Signalling interworking
.LP
	BEF113
	Priority
.LP
	BEF114
	Queue handling
.bp
.sp 1P
.LP
	\fIRouting\fR 
.sp 9p
.RT
.LP
	BEF200
	ISDN number identification
.LP
	BEF201
	Called number analysis (address analysis)
.LP
	BEF202
	Routing information examination (if provided)
.LP
	BEF203
	Predetermined specific routing
.LP
	BEF204
	Connection path selection
.LP
	BEF205
	Rerouting
.sp 1P
.LP
	\fIResources handling\fR 
.sp 9p
.RT
.LP
	BEF300
	Hold and release of user\(hynetwork access resources
(channels)
.LP
	BEF
300\ H:
	Hold user\(hynetwork access resources
.LP
	BEF
300\ R:
	Release user\(hynetwork access resource
.LP
	BEF301
	Hold and release of transit resources (circuits)
.LP
	BEF
301\ H:
	Hold transit resources
.LP
	BEF
301\ R:
	Release transit resources
.LP
	BEF302
	Insertion and suppression of specific equipment
.LP
	BEF303
	Tones, announcements and display information
.LP
	BEF304
	User\(hynetwork signalling handling (layer 1\(hy2)
.LP
	BEF305
	Inter\(hyexchange signalling handling (message
transfer)
.LP
	BEF306
	Path search inside switching unit
.LP
	BEF307
	Synchronization handling
.LP
	BEF308
	Timing handling
.LP
	BEF309
	Line service marking
.LP
	BEF310
	Real time clock
.sp 1P
.LP
	\fISupervision\fR 
.sp 9p
.RT
.LP
	BEF400
	User\(hynetwork access resources monitoring
.LP
	BEF401
	Transit resources monitoring
.LP
	BEF402
	Continuity checking
.LP
	BEF403
	Detection of congestion
.LP
	BEF404
	Semi\(hypermanent connection checking
.sp 1P
.LP
	\fIOperation and maintenance\fR 
.sp 9p
.RT
.LP
	BEF500
	Management of subscriber data
.LP
	BEF501
	Fault report
.sp 1P
.LP
	\fICharging\fR 
.sp 9p
.RT
.LP
	BEF600
	Charging management
.LP
	BEF
600\ I:
	Initiate charging
.LP
	BEF
600\ C:
	Cease charging
.LP
	BEF601
	Charging registering
.LP
	BEF602
	Charging recording
.LP
	BEF603
	Billing
.LP
	BEF604
	Accounting
.LP
	BEF605
	Charging information
.sp 1P
.LP
	\fIInterworking\fR 
.sp 9p
.RT
.LP
	BEF700
	Rate adaption
.LP
	BEF701
	Protocol conversion
.LP
	BEF702
	Handling of signalling for interworking
.LP
	BEF703
	Numbering interworking
.LP
	BEF704
	Special routing algorithms
.LP
	BEF705
	Negotiation
.LP
	BEF706
	Notification
.LP
	BEF707
	Charging for interworking
.LP
	BEF708
	Mapping of lower layer comparability
.bp
.sp 2P
.LP
A.1.2
	\fIAEFs relating to supplementary services\fR 
.sp 1P
.RT
.LP
	AEF00
	Insertion and suppression of additional resources
(tones\ etc.)
.LP
	AEF01
	Line hunting
.LP
	AEF02
	Direct dialling\(hyin
.LP
	AEF03
	Address determination
.LP
	AEF04
	Subscriber's dedicated storage
.LP
	AEF05
	Bridge
.LP
	AEF06
	User\(hynetwork access resource hold
.LP
	AEF07
	Hold of communication
.LP
	AEF08
	Additional subscriber signalling
.LP
	AEF09
	Additional inter\(hyexchange signalling
.LP
	AEF10
	Multi\(hycall handling
.LP
	AEF11
	Internal call initialization
.LP
	AEF12
	Access/route restriction
.LP
	AEF13
	Subscriber call data registration
.LP
	AEF14
	Data display option
.LP
A.2\ \ \fIShort description of elementary functions\fR 
.sp 1P
.RT
.sp 2P
.LP
A.2.1\ \ \fIBasic EFs related to connection types\fR 
.sp 1P
.RT
.sp 1P
.LP
A.2.1.1\ \ \fIConnection handling\fR 
.sp 9p
.RT
.sp 1P
.LP
100
	\fICharacteristics of service requested examination\fR 
.sp 9p
.RT
.PP
Function of a functional entity to determine the required service characteristics 
(certain attributes of the bearer service and optional 
supplementary services) of a call by means of examination of information 
set by calling terminal. 
.RT
.sp 1P
.LP
101
	\fIConnection elements type determination\fR 
.sp 9p
.RT
.PP
Function of a functional entity to determine connection types and connection 
elements necessary to provide the requested service. 
.RT
.sp 1P
.LP
102
	\fIUser access resources reservation\fR 
.sp 9p
.RT
.PP
Function of a functional entity to determine the type of
user\(hynetwork access (basic, primary), the state of the resources (channels
availability) and to reserve the channel(s) needed for establishing the 
access connection element. 
.RT
.sp 1P
.LP
103
	\fITransit resources reservation\fR 
.sp 9p
.RT
.PP
Function of a functional entity to reserve the transit connection element, 
based on the state of resources. 
.RT
.sp 1P
.LP
104
	\fICommunication references handling\fR 
.sp 9p
.RT
.PP
Function of a functional entity to assign a local reference (at the access 
interface) to the call and an internal reference (at the internal 
interface) to the connection, and to clear these references when the
call/connection is cleared/released.
.RT
.LP
	104\ E
	Establish call reference.
(For further study.)
.LP
	104\ C
	Clear call reference.
(For further study.)
.sp 1P
.LP
105
	\fIEstablishment control\fR 
.sp 9p
.RT
.PP
Function of a functional entity to set up a connection through the functional 
entity. 
.RT
.LP
	105\ R
	Establish connection\(hyreturn path only.
(For further study.)
.LP
	105\ F
	Establish connection\(hyforward path.
(For further study.)
.LP
	105\ B
	Establish connection\(hyboth direction.
(For further study.)
.bp
.sp 1P
.LP
106
	\fIRelease control\fR 
.sp 9p
.RT
.PP
Function of a functional entity to release a connection through the functional 
entity. 
.RT
.sp 1P
.LP
107
	\fIService related authorization examination\fR 
.sp 9p
.RT
.PP
Function of a functional entity to determine the authorization
(calling or called user) relating to basic and supplementary services that 
have been subscribed to. 
.RT
.sp 1P
.LP
108
	\fIUser\(hynetwork signalling handling (layer 3)\fR 
.sp 9p
.RT
.PP
Function of a functional entity to support the layer\ 3 protocol of the 
user\(hynetwork signalling system. 
.PP
\fINote\fR \ \(em\ For layers 1 and 2, see \(sc\ A.2.1.3, Resources
handling.
.RT
.sp 1P
.LP
109
	\fIInter\(hyexchange signalling handling (user part)\fR 
.sp 9p
.RT
.PP
Function of a functional entity to support the user part of the
inter\(hyexchange signalling system.
.RT
.sp 1P
.LP
110
	\fISupplementary services compatibility checking\fR 
.sp 9p
.RT
.PP
Function of the network to check the compatibility of requested
supplementary services, e.g.:
.RT
.LP
	\(em
	with requested bearer service to teleservice;
.LP
	\(em
	with other requested supplementary services;
.LP
and to verify coherence between parameters that may be associated.
.sp 1P
.LP
111
	 \fIBuilding\(hyup of and maintaining dynamic information related to the\fR 
\fIcall/connection\fR 
.sp 9p
.RT
.PP
Function of a functional entity to compile information related to the call/connection,\ 
e.g.: 
.RT
.LP
	\(em
	resources needed (connection type, connection elements,
channels, circuits);
.LP
	\(em
	details of call in progress;
.LP
	\(em
	supplementary services effected and associated
parameters.
.sp 1P
.LP
112
	\fISignalling interworking\fR 
.sp 9p
.RT
.PP
Function of a functional entity to support interworking functions between 
signalling systems. 
.RT
.sp 1P
.LP
113
	\fIPriority\fR 
.sp 9p
.RT
.PP
Function of a functional entity to handle specific calls
with priority (e.g.\ in the case of overload or degraded mode of
operation).
.RT
.sp 1P
.LP
114
	\fIQueue handling\fR 
.sp 9p
.RT
.PP
Function of a functional entity to store requests in a
queue, in order to handle this information later in a predefined
order.
.RT
.sp 2P
.LP
A.2.1.2\ \ \fIRouting\fR 
.sp 1P
.RT
.sp 1P
.LP
200
	\fIISDN number identification\fR 
.sp 9p
.RT
.PP
Function of a functional entity to identify the ISDN number of the user\(hynetwork 
interface. This information is limited to that included within the ISDN 
numbering plan. 
.RT
.sp 1P
.LP
201
	\fICalled number analysis\fR 
.sp 9p
.RT
.PP
Function of a functional entity to analyse called ISDN number sent by the 
calling terminal in the call set\(hyup phase. 
.bp
.RT
.sp 1P
.LP
202
	\fIRouting information examination\fR 
.sp 9p
.RT
.PP
Function of a functional entity to analyse routing information that may 
be sent by the calling terminal and that has an effect on path 
selection.
.RT
.sp 1P
.LP
203
	\fIPredetermined specific routing\fR 
.sp 9p
.RT
.PP
Function of an exchange to select a specific routing according to the information 
received from the calling terminal (for example routing towards operators, 
access points, an interworking unit, an operational or maintenance unit,\ 
etc.). 
.RT
.sp 1P
.LP
204
	\fIConnection path selection\fR 
.sp 9p
.RT
.PP
Function of a functional entity to select the transit outgoing part relating 
to connection types to be used, and the overall path through the 
network.
.RT
.sp 1P
.LP
205
	\fIRerouting\fR 
.sp 9p
.RT
.PP
Function of a functional entity to select a new connection path
through the network depending on changed conditions during call set\(hyup or
information transfer phases.
.RT
.sp 2P
.LP
A.2.1.3\ \ \fIResources handling\fR 
.sp 1P
.RT
.sp 1P
.LP
300
	\fIHold and release of user\(hynetwork access resources (channels)\fR 
.sp 9p
.RT
.PP
Function of a functional entity to hold the access channel(s)
reserved to support the communication, and to release it at the end of this
communication.
.RT
.LP
	300\ H
	Hold user\(hynetwork access resource.
(For further study.)
.LP
	300\ R
	Release user\(hynetwork access resource.
(For further study.)
.sp 1P
.LP
301
	\fIHold and release of transit resources (circuits)\fR 
.sp 9p
.RT
.PP
Function of a functional entity to hold the circuit(s) reserved to support 
the communication at the transit connection element and to release it at 
the end of this communication. 
.RT
.LP
	301\ H
	Hold transit resources.
(For further study.)
.LP
	301\ R
	Release transit resources.
(For further study.)
.sp 1P
.LP
302
	\fIInsertion and suppresion of specific equipment\fR 
.sp 9p
.RT
.PP
Function of a functional entity to insert or remove specific
equipments particularly to satisfy the service request invoked by the user.
Examples of such equipment include:
.RT
.LP
	\(em
	echo suppressers;
.LP
	\(em
	A\(hy\(*m law conversion units (change of A/D conversion);
.LP
	\(em
	interworking unit;
.LP
	\(em
	storage unit.
.sp 1P
.LP
303
	\fITones, announcements and display information\fR 
.sp 9p
.RT
.PP
Function of a functional entity to provide call progress
information in one or more of the following ways:
.RT
.LP
	\(em
	a tone is an audible (call progress) indication comprising
one or more discrete frequencies but excluding speech;
.LP
	\(em
	 a recorded announcement is an audible indication in the form of speech 
or music; 
.LP
	\(em
	 display information is (call progress) information set to the user which 
is displayed visually. 
.PP
Definitions of the other topics are not yet available.
.bp
.sp 1P
.LP
304
	\fIUser\(hynetwork signalling handling (layers 1\(hy2)\fR 
.sp 9p
.RT
.PP
Functions of a functional entity to support layers 1 and 2 of the user\(hynetwork 
signalling system. 
.RT
.sp 1P
.LP
305
	\fIInter\(hyexchange signalling handling (message transfer)\fR 
.sp 9p
.RT
.PP
Function of a functional entity to support the messages transfer
part of the inter\(hyexchange signalling systems.
.RT
.sp 1P
.LP
306
	\fIPath search inside switching unit\fR 
.sp 9p
.RT
.PP
Function of a functional entity to select an internal connection
inside the switching unit.
.RT
.sp 1P
.LP
307
	\fISynchronization handling\fR 
.sp 9p
.RT
.PP
Function of a functional entity to provide synchronization between different 
functional entities; and 
.PP
Function of a functional entity to provide its own internal
synchronization functional entity.
.RT
.sp 1P
.LP
308
	\fITiming handling\fR 
.sp 9p
.RT
.PP
Function of a functional entity to provide timing between time
instances involved in calls.
.RT
.sp 1P
.LP
309
	\fILine service marking\fR 
.sp 9p
.RT
.PP
Functions of a functional entity to store for each customer the
data on the parameters of the bearer and teleservices that are subscribed 
to. The store also contains the data on the parameters of the basic bearer 
and 
teleservices that are subscribed to by the customer. In addition, it contains 
the binary information (i.e.\ subscribed to or not) for a range of supplementary 
services which the subscriber can use. In general this data does \fInot\fR 
contain information on the type of subscriber terminal, but it may contain 
information on the type of access (basic, primary rate,\ etc.), the type 
of NT2 
(simple, intelligent,\ etc.) and the attributes of the services
subscribed\ to.
.RT
.sp 1P
.LP
310
	\fIReal time clock\fR 
.sp 9p
.RT
.PP
Function of a functional entity to provide real time
information.
.RT
.sp 2P
.LP
A.2.1.4\ \ \fISupervision\fR 
.sp 1P
.RT
.sp 1P
.LP
400
	\fIUser\(hynetwork access resources monitoring\fR 
.sp 9p
.RT
.PP
Function of a functional entity to check the correct operation of subscriber 
access resources. 
.RT
.sp 1P
.LP
401
	\fITransit resources monitoring\fR 
.sp 9p
.RT
.PP
Function of a functional entity to check the correct operation of the transit 
resources. 
.RT
.sp 1P
.LP
402
	\fIContinuity checking\fR 
.sp 9p
.RT
.PP
Function of a functional entity to control the checking operations relating 
to the continuity of a connection. 
.RT
.sp 1P
.LP
403
	\fIDetection of congestion\fR 
.sp 9p
.RT
.PP
Function of a functional entity to detect congestion during the
selection of a connection path.
.bp
.RT
.sp 1P
.LP
404
	\fISemi\(hypermanent connection checking\fR 
.sp 9p
.RT
.PP
Function of a functional entity to check the availability of
a given semi\(hypermanent connection (e.g.\ passive continuity
checking).
.RT
.sp 2P
.LP
A.2.1.5\ \ \fIOperation and maintenance\fR 
.sp 1P
.RT
.sp 1P
.LP
500
	\fIManagement of subscriber data\fR 
.sp 9p
.RT
.PP
Function of a functional entity to manage subscriber data related to services. 
Examples include: 
.RT
.LP
	\(em
	in/out of service
.LP
	\(em
	number translation
.LP
	\(em
	changing of subscriber data.
.sp 1P
.LP
501
	\fIFault report\fR 
.sp 9p
.RT
.PP
Function of a functional entity to register the cause if an attempt to 
set up a call fails. 
.RT
.sp 2P
.LP
A.2.1.6\ \ \fICharging\fR  | (the groupings below require further study)
.sp 1P
.RT
.PP
Function of the network to determine, collect and store the
charging information. The following features are involved in this
process:
.RT
.sp 1P
.LP
600
	\fICharging management\fR 
.sp 9p
.RT
.PP
Function of a functional entity to determine by means of certain
parameters the charging mode (free of charge, ordinary, peak, reduced
rate charge,\ etc.). These parameters include service type, class of customer, 
time information, distance,\ etc. 
.RT
.LP
	600\ I
	Initiate charging.
(For further study.)
.LP
	600\ C
	Cease charging.
(For further study.)
.sp 1P
.LP
601
	\fICharging registering\fR 
.sp 9p
.RT
.PP
Function of a functional entity to register the details of the call (both 
short\(hy and long\(hyterm storage). 
.RT
.sp 1P
.LP
602
	\fICharging recording\fR 
.sp 9p
.RT
.PP
Function of a functional entity to format the charging details in a standardized 
way. 
.RT
.sp 1P
.LP
603
	\fIBilling\fR 
.sp 9p
.RT
.PP
Function of functional entity to calculate the variable charges to the 
customer which depend on the use of a service and on the fixed costs of 
the subscription. Both of these are accumulated over a fixed period of 
time. This billing is associated with the subscriber and not with a user\(hynetwork 
interface, a terminal,\ etc.
.RT
.sp 1P
.LP
604
	\fIAccounting\fR 
.sp 9p
.RT
.PP
Function of a functional entity to analyse, store and forward
information relating to the use of inter\(hynetwork resources between the
different Administrations involved in a call.
.RT
.sp 1P
.LP
605
	\fICharging information\fR 
.sp 9p
.RT
.PP
Function of the network to indicate the user the amount of the
charge involved in the (current) use of the service.
.bp
.RT
.sp 2P
.LP
A.2.1.7\ \ \fIInterworking\fR 
.sp 1P
.RT
.PP
Functions that permit the establishment of end\(hyto\(hyend connections 
when an ISDN and a dedicated network are involved. This requires the provision 
of the basic elementary features (BEFs) which are described below and others 
that have been defined already (service request examination, signalling
interworking, called number analysis, routing information examination,
insertion and suppresion of interworking units,\ etc.).
.RT
.sp 1P
.LP
700
	\fIRate adaption\fR 
.sp 9p
.RT
.PP
Function of a functional entity to adapt, according to a
certain method, the user/dedicated network bit rates to the ISDN bit
rates.
.RT
.sp 1P
.LP
701
	\fIProtocol conversion\fR 
.sp 9p
.RT
.PP
Function of a functional entity to support mapping functions
between interfaces.
.RT
.sp 1P
.LP
702
	\fIHandling of signalling for interworking\fR 
.sp 9p
.RT
.PP
Function of a functional entity to handle signalling information
for interworking (interpretation, termination, generation).
.RT
.sp 1P
.LP
703
	\fINumbering interworking\fR 
.sp 9p
.RT
.PP
Function of a functional entity to support interworking functions between 
numbering plans. 
.RT
.sp 1P
.LP
704
	\fISpecial routing algorithms\fR  | (For further study)
.sp 9p
.RT
.sp 1P
.LP
705
	\fINegotiation\fR  | (For further study)
.sp 9p
.RT
.sp 1P
.LP
706
	\fINotification\fR  | (For further study)
.sp 9p
.RT
.sp 1P
.LP
707
	\fICharging for interworking\fR  | (For further study)
.sp 9p
.RT
.sp 1P
.LP
708
	\fIMapping of lower layer comparability (LLC) lists\fR  | (For further
study)
.sp 9p
.RT
.sp 2P
.LP
A.2.2\ \ \fIAdditional EFs relating to supplementary services\fR 
.sp 1P
.RT
.sp 1P
.LP
AEF00\ \ \fIInsertion and suppression of additional resources (tone,\ etc.)\fR 
.sp 9p
.RT
.PP
\fINote\fR \ \(em\ A definition has already been proposed for a basic EF. 
It needs to be considered if this feature should also be regarded as an 
additional feature. With respect to supplementary services a proposed description 
is:
.PP
Function of an exchange to manage (reserve, insert, release)
additional resources related to the handling of supplementary
services.
.RT
.sp 1P
.LP
AEF01\ \ \fILine hunting\fR 
.sp 9p
.RT
.PP
Function of a functional entity to select, on receipt of a certain terminal 
address, one free line in a multi\(hyline group corresponding to that 
number.
.RT
.sp 1P
.LP
AEF02\ \ \fIDirection dialling\(hyin\fR 
.sp 9p
.RT
.PP
Function of a functional entity to transfer address and other
appropriate call handling information to a PABX for the purpose of setting 
up a call to its extensions without assistance of the PABX operator. 
.RT
.sp 1P
.LP
AEF03\ \ \fIAddress determination\fR 
.sp 9p
.RT
.PP
Function of a functional entity to determine the destination
number(s) called by means of short\(hylong number conversion or of association
between one code and one list of numbers.
.bp
.RT
.sp 1P
.LP
AEF04\ \ \fISubscriber's dedicated storage\fR 
.sp 9p
.RT
.PP
Function of a functional entity to store details in addition to the LSM 
(line service marking) for each customer and which contains the 
registration data for supplementary services that have been subscribed to
(i.e.\ listed in the LSM as binary\ 1). For example, it would contain a 
list of abbreviated numbers. 
.RT
.sp 1P
.LP
AEF05\ \ \fIBridge\fR 
.sp 9p
.RT
.PP
Functions of a functional entity to allow more than two individual participants 
on the same call. 
.RT
.sp 1P
.LP
AEF06\ \ \fIUser\(hynetwork access resource hold\fR 
.sp 9p
.RT
.PP
Function of a functional entity to hold the user\(hynetwork access
resources (channel) involved in a communication in a waiting condition 
and, at the same time, to release the network connection. The call reference 
information is maintained.
.RT
.sp 1P
.LP
AEF07\ \ \fIHold of communication\fR 
.sp 9p
.RT
.PP
Function of a functional entity to initiate the function to hold
one, or more, of the other parties engaged in an established call in a 
waiting condition without the disestablishment of the call, and at the 
same time to 
release the initiating user\(hynetwork access resource.
.RT
.sp 1P
.LP
AEF08\ \ \fIAdditional subcriber signalling\fR 
.sp 9p
.RT
.PP
Functions of an exchange to send or receive specific signalling
information to or from the user, related to the handling of supplementary
services. (Additional signalling to the subscriber signalling for basic
calls.)
.RT
.sp 1P
.LP
AEF09\ \ \fIAdditional inter\(hyexchange signalling\fR 
.sp 9p
.RT
.PP
Function of a functional entity to send or receive specific
signalling information to or from another component, related to the handling 
of supplementary services. (Additional signalling to the inter\(hyexchange 
signalling for basic calls.) 
.RT
.sp 1P
.LP
AEF10\ \ \fIMulti\(hycall handling\fR 
.sp 9p
.RT
.PP
Function of a functional entity to set up and manage several
connections by means of a single procedure. (In response to only one call
request.)
.RT
.sp 1P
.LP
AEF11\ \ \fIInternal call initialization\fR 
.sp 9p
.RT
.PP
Functions of a functional entity to initiate the setting\(hyup of a
connection without receiving a call request from the user [e.g.\ used for
Completion of Call to Busy Subscribers (CCBS) supplementary service and 
alarm call services]. 
.RT
.sp 1P
.LP
AEF12\ \ \fIAccess/route restriction\fR 
.sp 9p
.RT
.PP
Function of a functional entity to reject incoming or outgoing
calls, either:
.RT
.LP
	\(em
	totally for all services, or
.LP
	\(em
	for one type of service (e.g.\ telephony).
.sp 1P
.LP
AEF13\ \ \fISubscriber call data registration\fR 
.sp 9p
.RT
.PP
Function of a functional entity to register and display or print
subscriber call data. Subscriber call data is information related to specific 
calls. This data is collected by the same functional entity as that which 
contains the EF \*Qsubscriber call data registration\*U.
.RT
.sp 1P
.LP
AEF14\ \ \fIData display option\fR 
.sp 9p
.RT
.PP
Functions of a terminal to display information to the
user.
.bp
.RT
.ce 1000
ANNEX\ B
.ce 0
.ce 1000
(to Recommendation I.310)
.sp 9p
.RT
.ce 0
.ce 1000
\fBDescriptions of identified \fR \fBfunctional components (FCs)\fR \fBfor 
the ISDN\fR 
.sp 1P
.RT
.ce 0
.LP
B.1
	\fIHold invocation\fR 
.sp 1P
.RT
.PP
This FC allows to invoke the disconnection of an established
communication channel between the initiating and responding entities and its
resevation for subsequent reuse for another (or the previous) communication.
This implies the interruption of the communication for an existing connection.
.PP
The initiating entity provides the information required to identify
the connection to be interrupted.
.PP
The successful application of this FC results in:
.RT
.LP
	\(em
	the disconnection of the communication channel between the
initiating and the responding entities;
.LP
	\(em
	the reservation of the disconnected communication channel
for the initiating entity (for originating or terminating
connections);
.LP
	\(em
	an indication of successful completion from the responding
entity.
.PP
The unsuccessful application of this FC results in a response
containing the failure details.
.PP
\fINote\fR \ \(em\ The exact definition of communication channel is for 
further study. 
.RT
.sp 1P
.LP
B.2
	\fIRetrieve\fR 
.sp 9p
.RT
.PP
This FC allows the initiating entity to request the reconnection of a communication 
channel between the initiating and responding entities in order to re\(hyestablish 
a previously held connection. 
.PP
The initiating entity provides the information required to identify
the connection to be re\(hyestablished over the reserved communication
channel.
.PP
The successful completion of this FC results in:
.RT
.LP
	\(em
	the re\(hyestablishment of the connection. The communication
channel will be the reserved channel whenever possible. If exceptionally an
alternate channel had to be allocated, the responding entity will indicate 
its identity; 
.LP
	\(em
	an indication of succesful completion from the responding
entity.
.PP
The unsuccessful application of the FC results in a response
containing the failure details.
.PP
The possible re\(hyestablishment of a connection over another
communication channel than the reserved one is for further study.
.RT
.sp 1P
.LP
B.3
	\fIJoin\fR 
.sp 9p
.RT
.PP
This FC allows to invoke the addition of a connection in order
to form, or to add to, a multiparty connection of the same connection
type.
.PP
The initiating entity provides all information required to identify
the connection to be joined to the multi\(hyparty connection. The responding
entity executes the functions to join the connection and provides the
initiating entity with the information of the result of the execution.
.PP
Upon successful completion, all connections involved are connected
together. A successful indication is returned to the initiating
entity.
.PP
Upon unsuccessful completion, the status of last connection remains
unchanged and an unsuccessful indication is returned to the initiating party
with failure cause(s).
.RT
.sp 1P
.LP
B.4
	\fISplit\fR 
.sp 9p
.RT
.PP
This FC allows the initiating entity to separate a connection from a multiparty 
connection. 
.PP
The initiating entity provides the identities of the multiparty
connection and the connection to be separated. The responding entity executes 
the functions to separate the designated connection from the multiparty 
connection.
.bp
.PP
Upon successful completion the designated connection is
separated from the multiparty connection. The separated connection is put on
hold; the remainder of the multiparty connection remains unchanged. A
successful indication is returned to the initiating entity.
.PP
Upon unsuccessful completion, the status of the multiparty connection remains 
unchanged and an unsuccessful indication is returned to the initiating 
party with failure cause(s). 
.RT
.sp 1P
.LP
B.5
	\fITransfer\fR 
.sp 9p
.RT
.PP
This FC allows the initiating entity to reassign the ownership of a call 
to an elected subscriber. 
.PP
The initiating entity provides the identity of the connection to be
transferred and the identity of the elected subscriber.
.PP
Successful completion of this FC results in:
.RT
.LP
	\(em
	the elected subscriber assumes the subsequent charges;
.LP
	\(em
	 the initiating entity receives a successful confirmation from the responding 
entity; 
.LP
	\(em
	the initiating entity is disconnected from the transferred
connection.
.PP
Upon unsuccessful completion, the status of the connection
remains unchanged and an unsuccessful indication is returned to the initiating 
party with failure cause(s). 
.PP
\fINote\fR \ \(em\ The concept of ownership requires further investigation in
relation to control and charging aspects.
.RT
.sp 1P
.LP
B.6
	\fINotify\fR 
.sp 9p
.RT
.PP
This FC provides the capability for one entity to inform another
entity of some action or condition without requiring a response from the
receiving entity.
.PP
\fINote\fR \ \(em\ A more precise definition of this FC is required.
.RT
.sp 1P
.LP
B.7
	\fIEnquire\fR 
.sp 9p
.RT
.PP
This FC provides the capability for the initiating entity to
request information from another entity, without changing that information.
.PP
The initiating entity provides to the responding entity what
information is requested and other information the responding entity needs 
to respond successfully. For example, in requesting information from the 
responding entity about busy/idle status of an interface, the initiating 
entity provides information uniquely identifying that interface. 
.PP
Upon successful completion, the responding entity returns to the
initiating entity the requested information.
.PP
Upon unsuccessful completion, the responding entity returns an
unsuccessful indication including failure cause(s).
.RT
.sp 1P
.LP
B.8
	\fIAdjourn\fR 
.sp 9p
.RT
.PP
This FC provides the capability for the initiating and responding entities 
to retain knowledge of a call ( or call attempt) sufficient for 
subsequent re\(hyestablishment.
.PP
The initiating entity provides to the responding entity the identity of 
the call to be adjourned. 
.PP
Upon successful completion, all channels previously allocated for the call 
(or call attempt) are released and the knowledge of the call is 
retained.
.PP
Upon unsuccessful completion, the status of the call remains unchanged 
and an unsuccessful completion indication with failure cause(s) is returned 
to the initiating entity. 
.RT
.sp 1P
.LP
B.9
	\fIRestart\fR 
.sp 9p
.RT
.PP
This FC provides the capability for the initiating entity to
allocate resources to restore an adjourned call.
.PP
The initiating entity provides the identity of the adjourned call to be 
restored. 
.PP
Upon successful completion, the necessary resources to re\(hyestablish
the call are restored and the call set\(hyup process resumes.
.PP
Upon unsuccessful completion, the adjourned call is released and a
failure indication returned to the initiating entity including failure
cause(s).
.bp
.RT
.sp 1P
.LP
B.10
	\fIMonitor\fR 
.sp 9p
.RT
.PP
This FC allows the initiating entity to watch for an event
(e.g.\ transition to idle, transition to busy) on a resource. The resource 
being monitored may be a network resource or a user resource. 
.PP
The initiating entity provides the identity of the resource to be
monitored, the event to be reported, and optionally the period of the monitor 
function. If the event to be monitored is the availability of a resource, 
the initiating entity may also request the resource be reserved when it 
becomes 
available. The responding entity will indicate acceptance or rejection 
of the monitor request immediately and subsequently check the states of 
the resource during the period specified. 
.PP
Upon successful completion, the responding entity will notify the
intiating entity if the period expired before the monitored event
occured.
.PP
Upon unsuccessful completion, an unsuccessful indication is returned to 
the initiating entity with failure cause(s). 
.RT
.sp 1P
.LP
B.11
	\fIReroute\fR 
.sp 9p
.RT
.PP
The FC allows the initiating entity to redirect an incoming call to an 
alternate address before the call is established. 
.PP
The initiating entity provides the identity of the incoming call and the 
aternate address to where the incoming call is to be redirected. 
.PP
Upon successful completion, the incoming call is connected to the
alternate address.
.PP
Upon unsuccessful completion, the responding entity provides to the
initiating entity the cause of failure and the call processing of the incoming 
call is resumed. 
.RT
.LP
.rs
.sp 28P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.sp 1P
.ce 1000
\v'3P'
SECTION\ 2
.ce 0
.sp 1P
.ce 1000
\fBREFERENCE\ MODELS\fR 
.ce 0
.sp 1P
.sp 2P
.LP
\fBRecommendation\ I.320\fR 
.RT
.sp 2P
.sp 1P
.ce 1000
\fBISDN\ PROTOCOL\ REFERENCE\ MODEL\fR 
.EF '%	Fascicle\ III.8\ \(em\ Rec.\ I.320''
.OF '''Fascicle\ III.8\ \(em\ Rec.\ I.320	%'
.ce 0
.sp 1P
.ce 1000
\fI(Malaga\(hyTorremolinos, 1984; amended at Melbourne, 1988)\fR 
.sp 9p
.RT
.ce 0
.sp 1P
.LP
\fB1\fR 	\fBIntroduction\fR 
.sp 1P
.RT
.PP
The objective of the ISDN Protocol Reference Model (ISDN PRM) is to model 
the interconnection and exchange of information\ \(em\ including user 
information and control information\ \(em\ to, through or inside an ISDN.
.PP
Communicating entities may be:
.RT
.LP
	\(em
	ISDN users;
.LP
	\(em
	an ISDN user and a functional entity within an ISDN, e.g.
network control facilities;
.LP
	\(em
	an ISDN user and a functional entity inside or outside an
ISDN, e.g.\ an information storage/processing/messaging facility;
.LP
	\(em
	various functional entities in an ISDN, e.g. a network
management facility and a switching facility;
.LP
	\(em
	an ISDN functional entity and an entity located in or
attached to a non\(hyISDN network.
.PP
The purpose of communications between these functional entities is to support 
the telecommunication services introduced in Recommendations\ I.211 and 
I.212, by providing ISDN capabilities as defined in Recommendation\ I.310. 
Examples of these capabilities are: 
.LP
	\(em
	circuit\(hyswitched connection under the control of common
channel signalling;
.LP
	\(em
	packet\(hyswitched communication over B\(hy, D\(hy and
H\(hychannels;
.LP
	\(em
	 signalling between users and network\(hybased facilities (e.g. information 
retrieval systems such as Videotex, operations data bases such as directory); 
.LP
	\(em
	 end\(hyto\(hyend signalling between users (e.g. to change mode of communication 
over an already established connection); 
.LP
	\(em
	combinations of the above as in multi\(hymedia communication,
whereby several simultaneous modes of communication can take place under 
common signalling control. 
.PP
With such diversity of ISDN capabilities (in terms of information flows 
and modes of communication), there is a need to 
model all these capabilities within a common framework (i.e. reference 
model). This would enable the critical protocol architectural issues to 
be readily 
identified and facilitate the development of ISDN protocols and associated
features. It is not intended as a definition of any specific implementation 
of an ISDN or of any systems or equipment in, or connected to, an ISDN. 
.PP
Examples of applications of this model are included in this
Recommendation.
.bp
.RT
.sp 2P
.LP
\fB2\fR 	\fBModelling concepts\fR 
.sp 1P
.RT
.sp 1P
.LP
2.1
	\fIRelationship with the X.200\(hySeries\fR 
.sp 9p
.RT
.PP
The ISDN Protocol Reference Model (ISDN PRM) and the Open Systems Interconnection 
Reference Model (OSI\ RM) for CCITT Applications, defined by 
Recommendation X.200, have both commonalities and differences.
.PP
Both the ISDN PRM and the OSI RM organize communications functions
into layers and describe the relation of these layers with respect to each
other. However, the scope of the ISDN PRM is different from the scope of 
the OSI RM. 
.PP
The scope of the ISDN PRM is to model information flows across the
range of telecommunication services defined in the I.200\(hySeries. These are
bearer services, teleservices and supplementary services. This description
necessarily incorporates ISDN\(hyspecific characteristics not encountered 
in other network types. Among these characteristics are multi\(hyservice 
types of 
communications which include voice, video, data and multi\(hymedia
communications.
.PP
The scope of the OSI RM is not associated with any particular network  type
.FS
Note that the term \*Qnetwork\*U in the ISDN corresponds to \*Qsub\(hynetwork\*U 
in the OSI terminology. 
.FE
. In that sense it is less specific than the ISDN PRM. Further, the scope 
of the OSI PRM is tied to data communications and so, in this respect, 
its scope is more specific than the ISDN PRM. The OSI is used to model 
data communications between open systems in an ISDN environment. 
.PP
The relative scopes of the two models are illustrated by
Figure\ 1/I.320. The existence of a common intersection shows that these 
models coexist and overlap. 
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure 1/I.320, (N), p.\fR 
.sp 1P
.RT
.ad b
.RT
.PP
However, in spite of these differences in scope, a number of
concepts and the associated terminology which have been introduced in\fR 
Recommendations\ X.200 and\ X.210 are fully applicable to the ISDN PRM. They
include the concept of layer, layer service (Recommendation\ X.200), and the
notions of service primitive, peer entity and peer protocol
(Recommendation\ X.210).
.PP
\fINote\fR \ \(em\ The relation between service primitives and functional
components introduced in Recommendation I.310 requires further study.
.PP
The layer identification used in Recommendation\ X.200 is limited
in this Recommendation to the use of layer numbers. Layer titles (e.g. 
network layer) as used in Recommendation\ X.200 are sometimes misleading 
in the ISDN 
context, and have not been used here.
.bp
.PP
The following ISDN needs have to be specifically catered for in
Recommendation\ I.320:
.RT
.LP
	\(em
	information flows for out\(hyof\(hyband call control processes,
or more generally, information flows among multiple related
protocols;
.LP
	\(em
	information flows for selection of connection
characteristics;
.LP
	\(em
	information flows for re\(hynegotiation of connection
characteristics of calls;
.LP
	\(em
	information flows for suspension of connections;
.LP
	\(em
	information flows for overlap sending ;
.LP
	\(em
	information flows for multi\(hymedia calls;
.LP
	\(em
	information flows for asymmetric connections;
.LP
	\(em
	information flows for network management
(e.g. change over and change back) and for maintenance
functions (e.g\ test loops);
.LP
	\(em
	information flows for power activation/deactivation;
.LP
	\(em
	interworking;
.LP
	\(em
	switching of information flows;
.LP
	\(em
	new layer service definitions for non\(hydata services;
.LP
	\(em
	application to other than end\(hysystems, e.g. signal transfer
points (STPs) and interworking points;
.LP
	\(em
	information flows for multi\(hypoint connections;
.LP
	\(em
	information flows for applications such as:
.LP
	i)
	voice (including A/\(*m law conversion),
.LP
	ii) 
	full motion video,
.LP
	iii)
	transparent flow,
.LP
	IV
	telex.
.sp 1P
.LP
2.2
	\fIControl and user planes\fR 
.sp 9p
.RT
.PP
The support of out\(hyof\(hyband signalling and the ability to activate 
supplementary services during the active phase of the call imply a separation 
between control information and user information. 
.PP
The notion of plane\ \(em\ control plane, or C\(hyplane, and user plane,
or U\(hyplane\ \(em\ is introduced to reflect this.
.PP
The main rationale for protocols within the user plane is the
transfer of information among user applications, e.g. digitized voice, 
data and information transmitted between users. This information may be 
transmitted 
transparently through an ISDN, or it may be processed or manipulated,
e.g.\ A/\(*m law conversion.
.PP
The main rationale for protocols within the control plane is the
transfer of information for the control of user plane connections,
e.g.\ in:
.RT
.LP
	\(em
	controlling a network connection (such as establishing and
clearing down);
.LP
	\(em
	controlling the use of an already established network
connection (e.g.\ change in service characteristics during a
call such as alternate speech/unrestricted
64\ kbit/s);
.LP
	\(em
	providing supplementary services.
.PP
\fR In addition to user information, any information which controls
the exchange of data within a connection, but otherwise does not alter the
state of this connection (e.g.\ flow control), pertains to the U\(hyplane. All
control information which involves resource allocation/deallocation by 
the ISDN pertains to the C\(hyplane. 
.sp 1P
.LP
2.3
	\fILocal and global significance\fR 
.sp 9p
.RT
.PP
A key characteristic of the ISDN is that, due to the integration of telecommunication 
services, the facilities to be provided depend on whether the adjacent 
entity, or a remote entity, is involved: different services, possibly using 
different routes, may have to be provided accordingly. An example is a 
telecommunication service, which can be supported by various network
capabilities, (e.g.\ a telematic service supported either by circuit or
packet facilities), or an ISDN connection based on various types of basic
connection components (e.g.\ analogue and digital circuits for a speech
connection).
.bp
.PP
As a consequence, the control information handled by an entity may
concern:
.RT
.LP
	\(em
	an adjacent functional entity, in which case it is said to
have local significance; 
.LP
	\(em
	 a remote (non\(hyadjacent) functional entity, in which case it has global 
significance. 
.PP
The significance concept is illustrated by Figure 2/I.320
.PP
The notion of significance applies to control plane information
only. As an example from the ISDN user's point of view:
.RT
.LP
	\(em
	the overall service to be provided to users has a
global significance;
.LP
	\(em
	 the control of any resources to be used at the user\(hynetwork interface 
has local significance; 
.LP
and, from the network's point of view:
.LP
	\(em
	the overall service to be provided by the ISDN (ISDN
connection types, as introduced in Recommendation I.340) has a global
significance;
.LP
	\(em
	the handling of connection elements has local
significance.
.LP
.rs
.sp 16P
.ad r
\fBFigure 2/I.320, (N),  p.\fR 
.sp 1P
.RT
.ad b
.RT
.PP
Depending on their functional requirements, supplementary services relate 
to either the local, or global perspective. For example: 
.LP
	\(em
	completion of calls to busy subscribers (CCBS) or
user\(hyto\(hyuser signalling (UUS) have global
significance;
.LP
	\(em
	call waiting has local significance.
.PP
Global information falls into three classes:
.LP
	1)
	the information is transported transparently;
.LP
	2)
	the information may be processed, but remains
unchanged (e.g.\ teleservice);
.LP
	3)
	the information may be altered (e.g. destination number
in relation with freephone or call forwarding supplementary
services).
.sp 2P
.LP
\fB3\fR 	\fBModel\fR 
.sp 1P
.RT
.PP
The ISDN PRM is represented by a 
protocol block
which
incorporates the concepts of layer, significance and plane described
above.
.PP
Such a protocol block can be used to describe various elements in the ISDN 
user premises and the network [e.g.\ terminal equipment (TE), ISPBX network 
termination (NT), exchange termination (ET), signalling point (SP) and 
signalling transfer point (STP), etc.].
.bp
.RT
.sp 1P
.LP
3.1
	\fIGeneric protocol block\fR 
.sp 9p
.RT
.PP
The considerations above lead to the introduction of the concept
of significance in combination with planes; the result is a splitting of the
control plane into two parts: a local control (LC) plane, and a global
control (GC) plane, in addition to the user (U) plane.
.PP
The layering principles apply in each of these planes: each plane can potentially 
accommodate a 7\(hylayer stack of protocols. A 
plane management
function
is required to allow coordination between the activities in the
different planes. Examples of plane management function are:
.RT
.LP
	\(em
	 the decision on whether an incoming information is relevant to the LC\(hy 
or GC\(hyplane, 
.LP
\fR 	\(em
	allowing communication between C\(hy and U\(hyplanes, for
synchronization purposes.
.PP
The Generic protocol block is represented in
Figure 3/I.320.
.PP
\fINote\fR \ \(em\ The plane management function should not be confused
with the system management as introduced to model OSI
management.
.PP
The following remarks apply:
.RT
.LP
	1)
	Some layers may be empty, i.e. they provide no
functionality. For example, it is likely that not all
seven layers are required to serve the LC\(hyplane requirements;
however, entities communicating in this plane are application
layer entities. Note that this is not in contradiction with
the OSI\ RM.
.LP
	2)
	An element (either in the network, or in user premises)
does not have to support in all cases protocols of LC\(hy, GC\(hy
and U\(hyplanes: some may ignore one or even two of these
planes. For example, a network service centre accessed to provide a
supplementary service (e.g.\ freephone) will be concerned
by the LC\ plane only, and will have no knowledge of the
other two planes.
.LP
	3)
	 A network element\ \(em\ unless it provides a high layer function (HLF)\ 
\(em\ will generally not support any U\(hyplane 
protocol above layer 3.
.LP
	4)
	The need for application processes specific to each
plane, or for application processes able to access several planes, is
for further study.
.LP
.rs
.sp 27P
.ad r
\fBFigure 3/I.320, (N), p.\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
3.2
	\fIRelations between layers in one plane\fR 
.sp 9p
.RT
.PP
Adjacent layers within a plane communicate using service
primitives. If a layer is empty the primitive is mapped directly onto a
primitive to the next layer.
.PP
Further study is required on which layer services have to be specified 
in order to describe a telecommunication service. 
.RT
.sp 1P
.LP
3.3
	\fIRelations between planes\fR 
.sp 9p
.RT
.PP
Starting from GC\(hyplane requirements, an entity will derive the
LC\(hyplane requirements, and the facilities that have to be provided for the
support of U\(hyplane lower layers. For example, in order to provide an ISDN
connection (GC\(hyplane), an exchange will have to identify the required basic
connection component (LC\(hyplane).
.PP
This relation is made via the plane management function.
.PP
Informations in different planes need not be carried by distinct
physical/logical means in all cases. For example:
.RT
.LP
	\(em
	control and user information may use the same
support, e.g.\ when in\(hyband signalling is used, or
when user information is carried on a
D\(hychannel;
.LP
	\(em
	LC and GC information share the same support
when the LC\(hyplane pass\(hyalong facility
is used;
.LP
	\(em
	ISPBX\(hyto\(hyISPBX control information appears as U\(hyplane
information to the ISDN.
.sp 1P
.LP
3.4
	\fIData flow modelling\fR 
.sp 9p
.RT
.PP
For further study.
.RT
.sp 2P
.LP
\fB4\fR 	\fBISDN management\fR 
.sp 1P
.RT
.PP
For further study.
.RT
.sp 2P
.LP
\fB5\fR 	\fBInterworking\fR 
.sp 1P
.RT
.PP
A number of particular interworking situations should be
considered:
.RT
.LP
	\(em
	internetworking with an OSI network;
.LP
	\(em
	interworking with an non\(hyISDN terminal;
.LP
	\(em
	interworking between two ISDNs which do not provide the
same set of facilities;
.LP
	\(em
	interworking involving a network\(hyprovided
interworking function to support high\(hylayer and/or
low\(hylayer facilities.
.sp 1P
.LP
5.1
	\fIGeneral\fR 
.sp 9p
.RT
.PP
All the interworking situations mentioned above are covered by the model 
illustrated by Figure 4/I.320. 
.PP
The service S may be:
.RT
.LP
	\(em
	the initially required telecommunication service (TS),
if both networks are able to provide it (F is then
empty);
.LP
	\(em
	a telecommunication service resulting from a negotiation
process, which both networks are able to provide (F is then
empty);
.LP
	\(em
	a service which is required to support the
telecommunication service to be provided, which is offered
by both networks, but by means of different capabilities in
the two networks.
.PP
The service S is provided:
.LP
	\(em
	by means of functions F1 and protocol(s) P1 in
network\ 1;
.LP
	\(em
	by means of functions F2 and protocol(s) P2 in
network\ 2.
.PP
The interworking function (IWF) maps the facilities offered by   F1 and F2.
.bp
.LP
.rs
.sp 24P
.ad r
\fBFigure 4/I.320, (N), p. 13\fR 
.sp 1P
.RT
.ad b
.RT
.PP
Two kinds of interworking can take place:
.RT
.LP
	1)
	a one\(hystage interworking, where the calling user is not
explicitly aware that an interworking function is
required;
.LP
	2)
	a two\(hystage interworking, where the calling user has a
dialogue with the interworking function prior to
exchanging control information with the destination
user.
.PP
The model applies to both cases.
.PP
Interworking may involve the GC\(hyplane, and/or the U\(hyplane.
.PP
In an interworking situation, the GC\(hyplane has to:
.RT
.LP
	\(em
	determine the telecommunication service to be provided
(agreed telecommunication service): this may imply service
negotiation;
.LP
	\(em
	identify the interworking situation, i.e. the fact that
more than one network is involved, and that for some
service\ S required to support the telecommunication
service, two adjacent networks do not use the same underlying
facilities;
.LP
	\(em
	locate and invoke an IWF capable of mapping the facilities
in the two networks.
.PP
In each network, the GC\(hyplane facilities will provide the
functions and protocols (Fi and Pi) required to support service\ S; this will
result in different (and independent) requirements on the LC\(hyplane in each
network.
.PP
In the two\(hystage interworking case, the GC\(hyplane information is
\*Uconsumed\*U by the IWF during the first phase, and is forwarded (with 
or without modification) during the second phase. 
.PP
Whenever interworking in the U\(hyplane is involved, the following
differences apply in the two cases:
.RT
.LP
	\(em
	one\(hystage interworking: in this case only the
first three layers (at most) may be involved for the provision
of the requested end\(hyto\(hyend service. No HLF is
required.
.LP
	\(em
	 two\(hystage interworking: in this case the first stage is the establishment 
of the U\(hyplane facilities between the calling 
user and the IWF. High layer functions (HLF) and protocols
may be involved, in which case the IWF acts as a substitute
for the called user.
.bp
.sp 1P
.LP
5.2
	\fIRelationships with the OSI RM\fR 
.sp 9p
.RT
.PP
The OSI RM, seen from the ISDN PRM point of view, appears not to
be in contradiction with the latter, but contains some restrictions which 
stem from the fact that it does not have the same scope: 
.RT
.LP
	1)
	The C\(hy and U\(hyplanes are not separated, since the C\(hy and
U\(hyplane information in one layer (\fIn\fR ) always maps onto the U\(hyplane
information of the layer below (\fIn\fR \ \(em\ 1).
.LP
	2)
	The concept of significance does not explicitly appear;
however control informations (e.g.\ in layer 3) include both \*Qlocal\*U
informations and informations which are carried end\(hyto\(hyend transparently 
or 
take part in the definition of the overall service provided to the user
(e.g.\ throughput).
.LP
	3)
	 The C\(hy and U\(hyplane informations in one layer (\fIn\fR ) map onto 
the U\(hyplane informations of the layer below (\fIn\fR \ \(em\ 1). 
.PP
Interworking between the OSI RM and ISDN PRM takes place in the
following situations:
.LP
	\(em
	internetworking with a specialized network (e.g. PSPDN)
which respects the OSI RM: the reference points involved
are K/L;
.LP
	\(em
	interworking with an \*QOSI terminal\*U via a terminal adaptor:
the reference point is then R;
.LP
	\(em
	the interworking of an ISDN terminal on the S reference
point which conforms to the OSI reference model is for
further study.
.PP
In each case, the interworking function (an IWF or a TA)
has to map information flows of one model onto information flows of the
other.
.sp 1P
.LP
5.2.1
	\fIInterworking at reference point K/L\fR 
.sp 9p
.RT
.PP
For further study.
.RT
.sp 1P
.LP
5.2.2
	\fIInterworking at reference point R\fR 
.sp 9p
.RT
.PP
In the case when a user application, running an OSI system,
requires network services across the ISDN, the originating user application
will address the terminating application as a destination user.
.PP
In the OSI system, the application is considered as an ISDN user \(em
a communicating functional entity in the PRM.
.PP
The GC information pertinent to the higher layer OSI application
is carried in the U\(hyplane to the destination application. The GC information
pertinent to the network service required is carried in the C\(hyplane with
LC information.
.PP
The OSI system requests the network service from the ISDN by placing a 
service request to both the LC\(hyplane and the U\(hyplane (Figure 5/I.320). 
The 
distribution of the information to the appropriate planes is made by the
plane management function
. The plane management function is responsible for providing an OSI service 
access point to the OSI system. 
.RT
.sp 2P
.LP
\fB6\fR 	\fBExamples\fR 
.sp 1P
.RT
.PP
Applications of the PRM to the following examples is for further
study.
.RT
.sp 1P
.LP
6.1
	\fIBasic call situations\fR  | (no supplementary service,
no interworking)
.sp 9p
.RT
.PP
\(em 
	circuit service (see Figure\ 6/I.320)
.RT
.LP
	\(em
	packet service
.LP
	\(em
	multi\(hybearer capability
.LP
	\(em
	data base access.
.bp
.LP
.rs
.sp 18P
.ad r
\fBFigure 5/I.320, (N), p. 14\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 18P
.ad r
\fBFigure 6/I.320, (N), p. 15\fR 
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
6.2
	\fIMore elaborate situations\fR 
.sp 9p
.RT
.PP
\(em 
	supplementary services:
.RT
.LP
	\(em
	completion of calls to busy subsribers (CCBS);
.LP
	\(em
	three\(hyparty service;
.LP
	\(em
	PABX facilities;
.LP
	\(em
	OAM (operational, administrative and maintenance)
applications.
.bp
.sp 1P
.LP
6.3
	\fIInterworking\fR 
.sp 9p
.RT
.PP
\(em 
	at reference point R (Teletex terminal):
.RT
.LP
	\(em
	with a PSTN;
.LP
	\(em
	with a PSPDN (Videotex);
.LP
	\(em
	inside an ISDN (provision of an HLF by the network);
.LP
	\(em
	of public ISDN with other networks (a possible example is
given in Figure\ 7/I.320).
.LP
.rs
.sp 25P
.ad r
\fBFigure 7/I.320, (N), p.\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.EF '%	Fascicle\ III.8\ \(em\ Rec.\ I.324''
.OF '''Fascicle\ III.8\ \(em\ Rec.\ I.324	%'
.LP
.rs
.sp 18P
.sp 2P
.LP
\fBMONTAGE:\ \ \fR Rec. I.324 sur le reste de cette page
.sp 1P
.RT
.LP
.bp