.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
\fBRecommendations Q.65 to Q.87\fR \v'2P'
.ce 0
.sp 1P
.ce 1000
\fBFUNCTIONS AND INFORMATION FLOWS\fR 
.ce 0
.sp 1P
.ce 1000
\fBFOR SERVICES IN THE ISDN\fR 
.ce 0
.sp 1P
.LP
.rs
.sp 28P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.LP
\fBMontage: PAGE \ \ \ 
= PAGE BLANCHE\fR 
.sp 1P
.RT
.LP
.bp
.sp 1P
.ce 1000
\v'3P'
SECTION 1
.ce 0
.sp 1P
.ce 1000
\fBMETHODOLOGY\fR 
.ce 0
.sp 1P
.sp 2P
.LP
\fBRecommendation\ Q.65\fR 
.RT
.sp 2P
.ce 1000
\fBSTAGE 2 OF THE METHOD FOR THE CHARACTERIZATION OF\fR 
.EF '%	Fascicle\ VI.1\ \(em\ Rec.\ Q.65''
.OF '''Fascicle\ VI.1\ \(em\ Rec.\ Q.65	%'
.ce 0
.sp 1P
.ce 1000
\fBSERVICES SUPPORTED BY AN ISDN\fR 
.FS
Some other CCITT Recommendations
(e.g.,\ I.310, I.324) deal with the functional description of the network. 
The relationship between some of the concepts in this Recommendation\ (Q.65) 
(e.g., function entity actions, service providing functions) and those 
in 
Recommendation\ I.130 (e.g., executive processes, elementary functions) needs
urgent further study.
.FE
.ce 0
.sp 1P
.LP
\fB1\fR 	\fBIntroduction\fR 
.sp 1P
.RT
.PP
1.1 
The overall method for deriving switching and signalling
Recommendations for ISDN services consists of three stages and is described 
in general in Recommendation\ I.130. This Recommendation\ (Q.65) describes 
Stage\ 2 in detail. 
.sp 9p
.RT
.PP
1.2
Stage\ 2 of the method takes as its input, the Stage\ 1 basic and
supplementary service descriptions contained in the\ I.200\(hySeries of
Recommendations. The Stage\ 1 description views the network (this term, 
in this context, could include some capability in the user equipment) as 
a single 
entity which provides these services to the user. The Stage\ 2 description
defines the functions required and their distribution within the network. 
The Stage\ 1 user/network interactions are used and interpreted within 
Stage\ 2, as illustrated in Figure\ 1/Q.65. 
.LP
.rs
.sp 12P
.ad r
\fBFigure 1/Q.65, p.  \fR 
.sp 1P
.RT
.ad b
.RT
.PP
1.3
Stage\ 2 identifies the functional capabilities and the information
flows needed to support the service as described in Stage\ 1. The Stage\ 2
service description will also include user operations not directly associated 
with a call (e.g., user change of call forwarding parameters via his service 
interface) as described in Stage\ 1. Furthermore, it identifies various 
possible physical locations for the functional capabilities. The output 
of Stage\ 2, 
which is signalling system independent, is used as an input to the design of
signalling system and exchange switching Recommendations.
.bp
.PP
1.4
This Recommendation describes the five steps of Stage\ 2 in detail.
The order of these steps represents an idealized application of the method,
however, in practice there will of necessity be interactions to define fully
the Stage\ 2 outputs. The Appendix contains detailed formats and graphical
conventions to be used. The Appendix has a parallel structure to the basic
Recommendation. The service specific Recommendations which follow conform to
these procedures.
.PP
1.5
Stage\ 2 of the method employs techniques that provide the following
desirable characteristics:
.LP
	\(em
	a precise definition of functional capabilities and their
possible distribution in network equipment (and in some cases, in user
equipment) to support the basic and supplementary services as described in
Stage\ 1;
.LP
	\(em
	a detailed description of what functions and information
flows are to be provided, but not how they are to be implemented;
.LP
	\(em
	 a single functional specification which can be applied in a number of 
different physical realizations for providing the service; 
.LP
	\(em
	 requirements for protocol and switching capabilities as input to Stage\ 
3 of the method; 
.LP
	\(em
	consistency, within the ISDN principles, of service and
protocol Recommendations which permits substantial implementation flexibility 
to Administrations and manufacturers. 
.PP
\fINote\fR \ \(em\ The Stage\ 2 description method and specific service 
work currently address only ISDN user to ISDN user calls in an ISDN. The 
extensions to interworking with other networks is for further study. 
.sp 2P
.LP
\fB2\fR 	\fBSteps of the method\fR 
.sp 1P
.RT
.sp 1P
.LP
2.1
	\fIStep 1 \(em functional model\fR 
.sp 9p
.RT
.PP
A functional model is derived for each basic supplementary service. In 
each case the model is matched to the requirements and characteristics 
of 
the service concerned.
.PP
The functional model used in the Stage\ 2 description of a service
identifies functional entities and the relationships between them. (The 
concept of functional entity is similar to that of a stored program (not 
necessarily 
implemented in software).)
.PP
The  refinement of the initial functional model is carried out by
development and/or iteration of steps\ 2 to\ 5, as described below. The final
functional model represents a result of the completion of Stage\ 2.
.RT
.sp 1P
.LP
2.1.1
	\fIFunctional entities\fR 
.sp 9p
.RT
.PP
Functional entities are initially derived from an overall
understanding of the network functions needed to support the service.
Functional entities are defined as follows:
.RT
.LP
	\(em
	a functional entity is a grouping of service providing
functions in a single location and is a subset of the total set of functions
required to provide the service. Further work is needed to provide a formal 
way of identifying service providing functions. In particular the list 
of 
elementary functions in Recommendation\ I.310 should be used as the basis of
this study;
.LP
	\(em
	 a functional entity is described in terms of the control of one instance 
of a service (e.g., one call or one connection); 
.LP
	\(em
	 a functional entity is visible to other functional entities that need 
to communicate with it to provide a service (i.e., functional 
entities are network addressable entities);
.LP
	\(em
	a functional model may contain functional entities of
different types. The type of a functional entity is characterized by the
particular grouping of functions of which it is composed. Thus two or more
functional entities are said to be of the same type if they consist of 
the same grouping of functions; 
.LP
	\(em
	a separate functional entity type is normally defined for
each different grouping of functions that may be distributed to separate
physical devices. However, where there is a high degree of commonality 
between different required groupings it may be convenient to define them 
as subsets of a single type rather than as different types; 
.LP
	\(em
	functional entities are derived for each basic and
supplementary service. The same functional entity type may occur more than
once in a functional model and also may appear in the model of more than one
service.
.bp
.sp 1P
.LP
2.1.2
	\fIFunctional entity relationships\fR 
.sp 9p
.RT
.PP
Services are supported by the cooperative actions of a set of
functional entities. Cooperation requires that communication relationships 
be established. 
.RT
.LP
	\(em
	 Each communicating pair of functional entities in a specific service 
functional model is said to be in a relationship. 
.LP
	\(em
	 Each interaction between a communicating pair of functional entities 
is termed an information flow. The relationship between any pair of 
functional entities is the complete set of information flows between them.
.LP
	\(em
	 If a communicating pair of functional entities is located in physically 
separate devices, the information flows between them define the 
information transfer requirements for a signalling protocol between the
devices.
.LP
	\(em
	 Different communicating pairs of functional entities may have relationships 
of different types. The type of a relationship is characterized by the 
set of information flows between two functional entities. The 
relationships between functional entities FE1 and FE2 and between functional
entities FE3 and FE4 are said to be of the same type if they comprise the 
same set of information flows. 
.LP
	\(em
	Relationships are assigned type identifiers (e.g., r\d1\u,
r\d2\u, r\d3\u, etc.) which uniquely identify specific sets of information 
flows within the functional model of a service. The same relationship type 
may occur more than once in a functional model. 
.sp 1P
.LP
2.1.3
	\fIDerivation of the\fR 
\fIfunctional model\fR 
.sp 9p
.RT
.PP
Based on the above definitions the functional model for a
particular service is derived using the following criteria and
guidelines:
.RT
.LP
	\(em
	 appropriate functional entities are chosen based on knowledge of the 
variety of anticipated network realizations. All reasonable 
distributions of functions should be considered, thus leaving the option 
open to an Administration as to how actually to offer the service; 
.LP
	\(em
	relationship types are initially assigned based on an
assessment of the probable nature of the interactions between each pair of
functional entities. Revisions to the initial model may be necessary in the
light of more detailed definition of functional entity actions, information
flows and the range of physical locations for functional entities;
.LP
	\(em
	the model for some services may require that a functional
entity be replicated a number of times (e.g., tandem functions). The
functional model should only describe replications up to the point where 
no new combinations of external relationships to functional entities are 
encountered by further replication. Thus, a single functional entity may 
represent multiple physical tandem entities providing the same functions. 
.PP
Figure 2/Q.65 illustrates a functional model.
.LP
.rs
.sp 18P
.ad r
\fBFigure 2/Q.65, p.  \fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
2.1.4
	\fIRelationship between\fR 
\fIbasic and supplementary service\fR 
\fImodels\fR 
.sp 9p
.RT
.PP
The functional model for a supplementary service is based upon, and includes 
at least part of a basic service model. 
.PP
The relationship between the model for a supplementary service and
that for a basic service may be derived by comparing the models. How the
functional entities of the supplementary service model relate to the functional 
entities of the basic service model is then clarified. 
.PP
The model for some supplementary services may not require the
definitions of additional functional entities (e.g., when the service is a
manipulation of an already defined service, for which the functionality
required to provide the service cannot be remote from a functional entity of
the basic service). In such cases, the supplementary service model will
typically involve additional extensions to basic service functional entities
and their relationships.
.PP
The following guidelines should be followed in resolving whether the functions 
associated with a supplementary service should be defined in the form of 
extensions to existing functional entities or in the form of new functional 
entities. 
.PP
A grouping of functions within a supplementary service model should be 
integrated into a basic service functional entity (e.g., see Figure 3/Q.65) 
if it modifies an object (e.g., call or connection) that is controlled 
by the 
basic service.
.PP
A functional grouping should be a separate functional entity if it is potentially 
assignable to more than one location in relation to particular 
functional entities of the basic service. A functional entity that is separate 
from a basic service functional entity typically would not require detailed 
call/connection state information. A separate functional entity may also be
characterized by having a transactional relationship with a functional 
entity of the basic service (e.g., to provide number translation to the 
basic service functional entity). 
.PP
Figure 3/Q.65 illustrates these relationships.
.RT
.LP
.rs
.sp 25P
.ad r
\fBFigure 3/Q.65, p.  \fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
2.2
	\fIStep 2 \(em information flow diagrams\fR 
.sp 1P
.RT
.sp 1P
.LP
2.2.1
	\fIIdentification of information flows\fR 
.sp 9p
.RT
.PP
The distribution of the functions required to provide a service, as defined 
by the functional model, requires that interactions occur between 
functional entities. Such an interaction is referred to as an \*Qinformation
flow\*U and will have a name descriptive of the intent of the information flow.
.PP
Information flow diagrams are created to contain all the information flows 
necessary for typical cases of succesful operation of the service. 
Information flow diagrams may need to be created as appropriate for other
cases. Figure\ 4/Q.65 illustrates the general form of an information flow
diagram for a basic or supplementary service.
.PP
Information flow diagrams for supplementary services should not
unnecessarily duplicate information flow descriptions that are part of 
a basic service. However, it may be that a supplementary service description 
identifies additional information flow requirements between the functional 
entities of the basic service representation, and this should be described. 
.RT
.LP
.rs
.sp 29P
.ad r
\fBFigure 4/Q.65, p.  \fR 
.sp 1P
.RT
.ad b
.RT
.LP
\fINotes to Figure 4/Q.65\fR 
.LP
\fINote\ 1\fR \ \(em\ Receipt and emission of user inputs/outputs and
information flows are shown by horizontal lines across the relevant functional 
entity columns. Conversely, the absence of a line indicates no receipt 
or 
emission.
.LP
.sp 1
\fINote\ 2\fR \ \(em\ A reference number is assigned to each point in the 
overall 
sequence at which functional entity actions are shown.
.bp
.LP
.sp 1
\fINote\ 3\fR \ \(em\ A brief description of the most significant functional
entity actions is shown on the diagram.
.LP
.sp 1
.LP
\fINote\ 4\fR \ \(em\ Information flows are shown as arrows with the name 
of the 
information flow above and below the arrow. The descriptive name is written 
in capitals above the arrow and the label (e.g., req.ind) written below 
line in 
lower case. For unconfirmed information flows and the \*Qrequest\*U part of
confirmed information flows the label \*Qreq.ind\*U is shown in lower case 
below 
the information flow arrows. For the \*Qconfirmation\*U part of confirmed
information flows the label \*Qresp.conf\*U is used.
.LP
.sp 1
\fINote\ 5\fR \ \(em\ If knowledge of one or more of the items of information
content in the information flow is important to the understanding of the
diagram (i.e. the name of the information flow is not enough), the items 
may be shown in lower case in brackets, following the information flow 
name. 
.LP
.sp 1
\fINote\ 6\fR \ \(em\ In a particular functional entity column:
.LP
	\(em
	 actions shown below a line representing the receipt of a user input or 
information flow are dependent upon that receipt (i.e. they cannot be carried 
out beforehand). Thus Action\ C, for example, cannot be carried out 
before ESTABLISH\ X is received;
.LP
	\(em
	similarly, actions shown above a line representing the
emission of a user output or an information flow must be completed prior 
to the emission of the information flow. Thus, ESTABLISH\ X cannot be emitted 
until 
Actions\ A and\ B are both completed. No implications regarding the order of
execution of Actions\ A and\ B are intended;
.LP
	\(em
	actions shown below a line representing the emission of a
user output or information flow do not need to be completed before emission
(although in many practical implementations they may). No constraint on the
relative order of the emission and the action which immediately follows 
it is intended. Thus Action\ E may be executed before, after or in parallel 
with the emission of the \*Qrequest\*U part of the CHECK information flow. 
.LP
.sp 1
.LP
\fINote\ 7\fR \ \(em\ The Stage\ 1 service interactions are inputs to and
outputs from the Stage\ 2 information flow diagram. Stage\ 1 service interactions 
\fIfrom\fR the user are either of the form XXXXX.req or XXXXX.resp. Stage\ 
1 service interactions \fIto\fR the User are either of the form XXXXX.ind 
or XXXXX.conf. 
.sp 1P
.LP
.sp 2
2.2.2
	\fIDefinition of individual\fR 
\fIinformation flows\fR 
.sp 9p
.RT
.PP
The semantic meaning and information content of each information
flow is determined. An individual information flow may be identified as
requiring confirmation, and if so, it requires a return information flow 
of the same name. 
.PP
Confirmed information flows take the form of a request for an action (in 
one direction) and confirmation that the action has been carried out (in 
the return direction). Confirmed information flows are typically required 
for synchronization purposes. The two main cases are when requesting allocation 
and/or release of a shared resource.
.PP
When interacting functional entities are implemented in physically
separate locations, information flows will normally be conveyed by signalling 
system protocols. When interacting functional entities are implemented 
in the same location, information flows are internal and do not effect 
signalling 
systems protocols.
.RT
.sp 1P
.LP
2.3
	\fIStep\ 3 \(em SDL diagrams for functional entities\fR 
.sp 9p
.RT
.PP
SDL diagrams are used to provide a complete description of actions for 
each functional entity in relation to the associated information flows. 
They are based on (and consistent with) information flow diagrams but also
cover more complex cases including cases of unsuccessful and/or abnormal
operation. Consideration of such cases may result in the need to define new
information flows.
.PP
The inputs to and outputs from the SDL diagram for a functional entity 
are information flows. The Stage\ 3 definition work will make use of these 
information flows to define signalling system output and input primitives 
(see Figure\ 5/Q.65). Thus, signalling system SDL descriptions are precisely 
related to and derived from the Stage\ 2 information flows and functional 
relationships which the signalling system is designed to support. 
.bp
.RT
.LP
.rs
.sp 42P
.ad r
\fBFigure 5/Q.65, p.  \fR 
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
2.4
	\fIStep\ 4 \(em functional entity actions\fR 
.sp 9p
.RT
.PP
The Stage\ 2 actions performed within a functional entity, from the reception 
of each information flow to the transmission of the next resulting 
information flow, are identified and listed. The need for a generic list of
functional entity actions (FEAs), to ensure consistency between different
services, is an urgent item for further study. All externally visible actions 
(those which are explicitly or implicitly notified to other functional 
entities) are included. The identified actions are then represented on the
information flow diagrams and SDL diagrams by brief prose statements, or
separately using reference numbers.
.bp
.RT
.sp 1P
.LP
2.5
	\fIStep\ 5 \(em allocation of functional entities to physical\fR 
\fIlocations\fR 
.sp 9p
.RT
.PP
In Step\ 1, a functional model consisting of functional entities,
each of which has a well defined relationship to the others, is defined for
each basic and supplementary service. Step\ 5 is an allocation of these
functional entities to physical locations and defines all relevant physical
implementations, henceforth called scenarios.
.PP
More than one scenario may be defined for one functional model so
that Administrations will have options as to where the service is actually
provided. For example, a supplementary service functional entity could be
located either in an ISPBX or in an exchange.
.PP
For the allocation of functional entities, it should be noted
that:
.RT
.LP
	a)
	a functional entity may in principle, be allocated to any
physical location;
.LP
	b)
	 a number of functional entities may be allocated to the same physical 
location; 
.LP
	c)
	for every supplementary service, network scenarios which
include the location of its basic service functional entities should be
defined;
.LP
	d)
	different physical locations of functional entities may
imply minor differences in node capabilities (e.g., the transmission path
switch\(hythrough actions may depend on whether the access is in an exchange 
or an ISPBX); 
.LP
	e)
	the relationships between pairs of functional entities,
according to the functional model used, should be invariant for all of the
recommended scenarios.
.PP
Item\ e) implies e.g., that the information flows for a
supplementary service would not be affected by a re\(hyallocation of one 
or more of the required functional entities from public network exchange 
to an ISPBX or viceversa. 
.PP
All identified scenarios will be considered in Stage\ 3 for definition 
of signalling protocols, switching capabilities and service centre 
capabilities.
\v'6p'
.RT
.ce 1000
APPENDIX\ I
.ce 0
.ce 1000
(to Recommendation Q.65)
.sp 9p
.RT
.ce 0
.ce 1000
\fBFormats and graphical conventions used in the Stage 2\fR 
.sp 1P
.RT
.ce 0
.ce 1000
\fBservice description\fR 
.ce 0
.LP
I.1
	\fIGeneral\fR 
.sp 1P
.RT
.PP
This Appendix describes the structure and conventions to be used
when creating a Stage\ 2 description of a particular service. It describes 
the contents of each section and the graphical conventions to be used. 
.RT
.sp 1P
.LP
I.1.1
	\fIIntroduction\fR 
.sp 9p
.RT
.PP
Each Stage 2 service definition starts with an introduction. The
introduction includes the definition of the service from the Stage\ 1
recommendation, plus any further sentences needed for clarification or 
to give extra background information. The Stage\ 1 recommendation number 
is 
included.
.RT
.LP
I.2
	\fISteps of the method\fR 
.sp 1P
.RT
.sp 2P
.LP
I.2.1
	\fIStep 1 \(em identification of a functional model\fR 
.sp 1P
.RT
.sp 1P
.LP
I.2.1.1
	\fIFunctional model description\fR 
.sp 9p
.RT
.PP
This section contains a description of the functional model of this service 
(i.e. there is one model for each service). The functional model 
identifies and names the individual functional entities and their types. It
also identifies the relationships and relationship types between communicating 
functional entities. Functional entities are represented by circles and 
the 
relationship between two communicating functional entities is identified 
by a line joining them. The functional entity type is contained within 
the circle. Each functional entity is given a unique label (e.g., FE1, 
FE2) adjacent to the circle. 
.PP
The relationship types are numbered r\d1\u, r\d2\u, r\d3\uetc., for ease 
of reference (see Figure\ 3/Q.65 for an example). 
.bp
.RT
.sp 1P
.LP
I.2.1.2
	\fIDescription of functional entity \*Qx\*U\fR 
.sp 9p
.RT
.PP
This paragraph provides a brief prose description of the functional entity 
\*Qx\*U. Each functional entity identified in the model has a corresponding 
section and prose description. 
.PP
In the case of supplementary service it is necessary to describe how the 
model for this supplementary service relates to that of the basic service. 
This relationship may be derived by comparing the models. This relationship 
should be clearly indicated in accordance with the guidelines of\ \(sc\ 
2.1.4 of the main body of the Recommendation. A prose explanation may also 
be useful (e.g., to describe that certain supplementary service functions 
actually form a 
modular extension to a functional entity defined in the basic service). See
Figure\ 3/Q.65 for an example.
.RT
.sp 2P
.LP
I.2.2
	\fIStep 2 \(em information flow diagrams\fR 
.sp 1P
.RT
.sp 1P
.LP
I.2.2.1
	\fIIdentification of information flows\fR 
.sp 9p
.RT
.PP
This paragraph contains information flow (arrow) diagrams
describing the information flows between the functional entities of the 
model. See Figure\ 4/Q.65. The purpose of this section is to define in 
a precise and 
descriptive manner, the successful operation of the service. This may require 
a number of arrow diagrams depending on the service. Explanatory prose 
description may also be provided where useful.
.PP
The following guidelines are observed in drafting these information
flow diagrams:
.RT
.LP
	\(em
	vertical columns represent each of the functional entities
identified in the functional model for the service. Information flows are 
shown is descending order in which they are to occur in the processing 
of a call. The order of functional entity actions shown between information 
flows is not 
significant;
.LP
	\(em
	an information flow will be characterized in the arrow
diagrams as being associated with the terms request/indication or
response/confirmation. This is reflected in the primitive which is communicated 
to the underlying signalling system as illustrated in Figure\ 5/Q.65. The 
primitive name is, in general, a direct derivation of the information flow
name. The terms \*Qreq.ind\*U and \*Qresp.conf\*U are part of the information 
flow 
name. The terms are shown in association with the information flow to show 
the relation between the Stage\ 2 SDL and the SDL of the underlying signalling 
system.
.PP
Further details on drafting conventions can be found in the notes to Figure\ 
4/Q.65. 
.PP
A reference number uniquely identifies a particular point in the
Stage\ 2 information flow sequence and appears on the information flow 
diagram at that point. It also serves as a pointer to a description (see\ 
\(sc\ I.2.4 below) of the actions required at this point in the sequence. 
A brief description of the functional entity actions will also appear on 
the relevant part of the 
information flow diagrams. The reference numbering scheme to be used is
described below.
.PP
Each number is of the form NNN and is a decimal number assigned by the 
drafter of the Stage\ 2 description, which identifies a particular point 
in the Stage\ 2 procedural description (arrow diagrams and SDL) at which 
functional 
entity actions are described.
.PP
This number is unique within the Stage\ 2 description of a particular service 
(all variants). 
.RT
.sp 2P
.LP
I.2.2.2
	\fIDefinition of information flow name\fR 
.sp 1P
.RT
.sp 1P
.LP
I.2.2.2.1
	\fIMeaning of information flow name\fR 
.sp 9p
.RT
.PP
This paragraph defines the meaning of the information flow in
terms of the actions, operations, events, etc. which are requested and/or
reported by the information flow. The description will indicate if this is
confirmed or unconfirmed information flow. If confirmed, the meaning of the
confirmation is also identified.
.RT
.sp 1P
.LP
I.2.2.2.2
	\fIInformation content of information flow name\fR 
.sp 9p
.RT
.PP
This paragraph defines the information content conveyed by the
information flow. This consists of elements of static information (e.g., 
called address). For confirmed information flows, a set of elements is 
required in 
each direction. The name of each element, its range of values and the
relationships where it occurs should be identified.
.bp
.RT
.sp 1P
.LP
I.2.3
	\fIStep\ 3 \(em SDL diagrams for functional entities\fR 
.sp 9p
.RT
.PP
This paragraph contains an SDL diagram for each of the functional entities 
identified in the functional model in\ \(sc\ I.2.1. If the provision of 
the service implies a modular extension to the SDL diagram for a functional 
entity of the basic service, then the SDL describing the extension is provided 
(e.g., see Figure\ I\(hy1/Q.65). This may require some modification to 
the basic service SDL to show the extension and the point in the basic 
service SDL where it 
occurs. Alternative approaches which do not require modification (\*Qhooks\*U) 
in the basic service SDL are for further study. 
.RT
.LP
.rs
.sp 31P
.ad r
\fBFigure I\(hy1/Q.65, p.  \fR 
.sp 1P
.RT
.ad b
.RT
.PP
The reference numbers used in the relevant information flow
diagrams (see \(sc\ I.2.2.1) are also used in the SDL diagrams. Where a group
of actions appears only on the SDL diagram, a reference number is also
assigned.
.PP
Each group of actions is in a concise form in a single task box on
the SDL diagrams. As before, the associated reference number points to a
description (see \(sc\ I.2.4) of the functional entity actions required at this
point in the sequence.
.PP
The functional entity SDL diagrams employ conventions and procedures of 
SDL as described in Recommendation\ Z.100. An extract of\ Z.100 follows 
to 
identify briefly the use of some of these conventions in the context of the
Stage\ 2 service description.
.bp
.RT
.LP
.rs
.sp 28P
.ad r
\fBDiagrammes, p.  \fR 
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
I.2.4
	\fIStep\ 4 \(em functional entity actions\fR 
.sp 9p
.RT
.PP
This paragraph contains descriptions of actions required for each functional 
enity and is identified by the reference number, as described 
in\ \(sc\(sc\ I.2.2.1 and\ I.2.3.
.PP
The presentation form for functional entity actions is illustrated in Figure\ 
I\(hy2/Q.65. 
.RT
.LP
.rs
.sp 16P
.ad r
\fBFigure I\(hy2/Q.65 [T1.65], p. (\*`a traiter comme tableau MEP)\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
I.2.5
	\fIStep\ 5 \(em allocation of functional entities to physical locations\fR 
.sp 9p
.RT
.PP
This paragraph describes the possible scenarios for the physical
location of the functional entities shown in the functional model of the
service. They are presented in a matrix form.
.PP
The matrix represents the functional entities of the service
description functional model as columns and each scenario as a row. The 
points of the matrix identify the physical location to which that functional 
entity 
is allocated for that scenario.
.PP
The conventions used for the matrix are illustrated in
Figure\ I\(hy3/Q.65.
.PP
Possible physical locations and their corresponding symbolic
representation are:
.RT
.LP
	\(em
	Terminal equipment; Type 1 or terminal adapter: TE
.LP
	\(em
	Network termination; Type 2: NT2 (typically in ISPBX)
.LP
	\(em
	Local exchange: LE
.LP
	\(em
	Transit exchange: TR
.LP
	\(em
	Service centre: SC
.LP
.rs
.sp 11P
.ad r
\fBFigure I\(hy3/Q.65, p. 9\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure I\(hy3/Q.65 [T2.65], p. 10 (\*`a traiter comme tableau MEP)\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.ce 1000
\v'4P'
SECTION\ 2
.ce 0
.sp 1P
.ce 1000
\fBBASIC\ SERVICES\fR 
.ce 0
.sp 1P
.sp 2P
.LP
\fBRecommendation\ Q.71\fR 
.RT
.sp 2P
.sp 1P
.ce 1000
\fBISDN\ 64\ kbit/s\ CIRCUIT\ MODE\ SWITCHED\ BEARER\ SERVICES\fR 
.EF '%	Fascicle\ VI.1\ \(em\ Rec.\ Q.71''
.OF '''Fascicle\ VI.1\ \(em\ Rec.\ Q.71	%'
.ce 0
.sp 1P
.LP
\fB1\fR 	\fBIntroduction\fR 
.sp 1P
.RT
.sp 1P
.LP
1.1
	\fIGeneral\fR 
.sp 9p
.RT
.PP
This Recommendation provides information on the functions in ISDN entities 
and the information flows between the entities which are required to provide 
en\(hybloc call set\(hyup and call release procedures for circuit mode 
switched 64\ kbit/s, 8\ kHz structured bearer services. Such services
include:
.RT
.LP
	\(em
	speech information transfer,
.LP
	\(em
	3.1 kHz audio information transfer,
.LP
	\(em
	unrestricted information transfer,
.LP
	\(em
	alternate speech/unrestricted information transfer.
.PP
Information about digit\(hyby\(hydigit call set\(hyup, in\(hycall
rearrangement, relationship to and interworking with Teleservices, interworking 
with other networks and connections involving users with multipoint 
configurations is not included but is expected to be added to this
Recommendation at a later date.
.sp 2P
.LP
1.2
	\fIDefinitions of services\fR 
.sp 1P
.RT
.sp 1P
.LP
1.2.1
	\fBspeech information transfer\fR (Recommendation I.231, \(sc 1)
.sp 9p
.RT
.PP
This bearer service category is intended to support speech.
.PP
The digital signal at the S/T reference point is assumed to conform to 
the internationally agreed encoding laws for speech (i.e.\ Recommendation\ 
G.711 A\(hylaw, \(*m\(hylaw) and that the network may use processing techiques 
appropriate for speech such as analogue transmission, echo cancellation 
and low bit rate 
encoding. Hence, bit integrity is not assured. This bearer service is not
intended to support modem derived voiceband data.
.PP
All CCITT Recommendations for the transfer of speech information in
the network apply to this service.
.RT
.sp 1P
.LP
1.2.2
	\fB3.1 kHz audio information transfer\fR (Recommendation I.231, \(sc 2)
.sp 9p
.RT
.PP
This bearer service corresponds to the service which is currently offered 
in the PSTN. 
.PP
This bearer service provides the transfer of speech and for the
transfer of 3.1\ kHz bandwidth audio information such as voiceband data via
modems, groups\ I, II and\ III facsimile information (see Note). The digital
signal at the S/T reference point
.bp
.PP
is assumed to conform to the
internationally
agreed encoding laws for speech A\(hylaw, \(*m\(hylaw, i.e.\ Recommendation\ 
G.711. 
Connections provided for this service should provide for the transfer of the
information indicated above. (This means that the network may include speech
processing techniques provided that they are appropriately modified, or
functionally removed prior to non\(hyspeech information transfer.) The 
control of echo control devices, speech processing services\ etc. is only 
made by use of a 2100\ Hz (disabling) in\(hyband tone. 
.PP
All CCITT Recommendations for the transfer of speech information in
the network apply to this service.
.PP
\fINote\fR \ \(em\ The maximum modem bit rate that can be used by users in
applications of this bearer service depends on the modulation standard 
employed by the user and on the transmission performance within, or between, 
different Administrations. The extent of support is a network, or bilaterally 
agreed 
matter.
.RT
.sp 1P
.LP
1.2.3
	\fBunrestricted information transfer\fR (Recommendation I.231, \(sc 3)
.sp 9p
.RT
.PP
An unrestricted bearer service provides information transfer
without alteration between S/T reference points. It may, therefore, be 
used to support various user applications. Examples include: 
.RT
.LP
	1)
	speech (Note 2);
.LP
	2)
	3.1 KHz audio (Note 2);
.LP
	3)
	multiple subrate information streams multiplexed into 64
kbit/s by the user;
.LP
	4)
	transparent access to an X.25 public network
(Recommendation\ I.462, case\ a).
.PP
User information is transferred over a B channel: signalling is
provided over a D\ channel.
.PP
\fINote\ 1\fR \ \(em\ During an interim period some networks may only support
restricted 64\ kbit/s digital information transfer capability, i.e.\ information 
transfer capability solely restricted by the requirement that the all\(hyzero 
octet is not allowed. For interworking the rules given in Appendix\ 1 of
Recommendation\ I.430 should apply. The interworking functions have to be
provided in the network with restricted 64\ kbit/s capability. The ISDN with
64\ kbit/s transfer capabilities will not be affected by this interworking,
other than conveying the appropriate signalling message to and from the ISDN
terminal.
.PP
\fINote\ 2\fR \ \(em\ Whilst speech and 3.1 kHz audio have been given as one
application for this bearer service, it is recognized that it is the
responsibility of the customers to ensure that a compatible encoding scheme 
is in operation. Customers should also recognize that no network provision 
can be made for the control of such items as echo and loss, as the network 
is unaware of the application in use. Furthermore, the quality of service 
attribute for 
information transfer delay will indicate the suitability of a particular
version of this bearer service for speech.
.RT
.sp 1P
.LP
1.2.4
	 \fBalternate speech/unrestricted information transfer\fR (Recommendation 
I.231, \(sc 4) 
.sp 9p
.RT
.PP
The service provides the alternate transfer at either speech of
64\ kbit/s unrestricted digital information with the same call.
.PP
The request for this alternate capability and the initial mode desired 
by the user must be identified at call set\(hyup time. 
.PP
This service must be provided for the support of multiple capability terminals 
or single capability terminals. 
.PP
\fINote\fR \ \(em\ Initially, this service will only be applicable to multiple 
capability terminals. The use of this service by, and the network support 
of, single capability terminals is for further study (e.g., how a user 
changes 
terminals). All references to single capability terminals reflect possible
future enhancements and are subject to change and have only been included 
for information. 
.RT
.sp 1P
.LP
1.3
	\fIService invocation\fR 
.sp 9p
.RT
.PP
Users indicate their required bearer service capabilities at the
time of call set\(hyup by including appropriate information in the service 
request sent to the network via the user/network signalling channel. Subsequent 
interactions involving status and control information also occur using the
signalling channel. However, tones and announcements associated with speech
.PP
and 3.1\ kHz audio information services are sent to the user over the 64\ 
kbit/s user access channel used for the call. 
.bp
.RT
.sp 2P
.LP
\fB2\fR 	\fBCall set\(hyup and release\fR 
.sp 1P
.RT
.sp 1P
.LP
2.1
	\fIFunctional model\fR 
.sp 9p
.RT
.LP
.rs
.sp 8P
.ad r
\fBFigue 2\(hy1/Q.71, p.\fR 
.sp 1P
.RT
.ad b
.RT
.PP
CCAs are functional entities that serve the users and are
responsible for initiating functional requests and interacting with CCs. CCs
are functional entities that cooperate with each other to provide the services 
requested by the CCAs. r\d1\uand\ r\d2\uare relationships between functional 
entities
wherein information flows occur in order to process call attempts or service
requests.
.sp 1P
.LP
2.1.1
	\fIDescription of the\fR \fIcall control agent (CCA)\fR \fIfunctional\fR 
\fIentity\fR 
.sp 9p
.RT
.PP
The CCA functional entity supports the functionality to:
.RT
.LP
	a)
	access the service\(hyproviding capabilities of the CC
entities, using service requests for the establishment, manipulation and
release of a single call (e.g.\ set\(hyup, transfer, hold,\ etc.).
.LP
	b)
	 receive indications relating to the call from the CC entity and relay 
them to the user. 
.LP
	c)
	maintain call state information as perceived from this
functional end\(hypoint of the service (i.e, 
a single\(hyended view of the
call).
.sp 1P
.LP
2.1.2
	\fIDescription of the\fR \fIcall control (CC)\fR \fIfunctional entity\fR 
.sp 9p
.RT
.PP
The CC functional entity supports the functionality to:
.RT
.LP
	a)
	establish, manipulate and release a single call (upon
request of the CCA entity).
.LP
	b)
	 associate and relate the CCA entities that are involved in a particular 
call and/or service. 
.LP
	c)
	 manage the relationship between the CCA entities involved in a call (i.e.\ 
reconcile and maintain the overall perspective of the call and/or service). 
.sp 2P
.LP
2.2
	 \fIInformation flows required for en\(hybloc and digit\(hyby\(hydigit 
sending\fR \fIcall set\(hyup and call release\fR 
.sp 1P
.RT
.sp 1P
.LP
2.2.1
	\fIInformation flow diagrams\fR 
.sp 9p
.RT
.PP
Information flow diagrams for 64 kbit/s circuit mode switched
bearer service call setup and call release are shown in Figures\ 2\(hy2/Q.71
through\ 2\(hy6/Q.71:
.RT
.LP
	\(em
	 Figure 2\(hy2/Q.71 shows a successful call set\(hyup using en\(hybloc 
sending; 
.LP
	\(em
	Figures 2\(hy3/Q/.71 and 2\(hy4/Q.71 are reserved to show call
set\(hyup procedures for digit\(hyby\(hydigit sending cases;
.LP
	\(em
	 Figure 2\(hy5/Q.71 shows normal clearing initiated by a calling party 
disconnection; 
.LP
	\(em
	Figure 2\(hy6/Q.71 shows normal clearing initated by a called
party disconnection.
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 2\(hy2/Q.71, p. 12 \ \ \ 
\*`a l'italienne\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 2\(hy5/Q.71, p. 13 \ \ \ 
\*`a l'italienne\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 2\(hy6/Q.71, p. 14 \ \ \ 
\*`a l'italienne\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
\fINotes to Figures 2\(hy2/Q.71 through 2\(hy9/Q.71\fR 
.LP
\fINote\ 1\fR \ \(em\ Through connection is dependent on the physical
location of the functional entity:
.LP
	a)
	Originating local exchange \(em
.LP
	i)
	 for 3.1 kHz audio bearer service, speech and telephony services, backwards 
only or both directions, depending on the approach adopted by the Administration 
or RPOA. 
.LP
	ii)
	for 64 kbit/s unrestricted information transfer,
backwards only, except for own\(hyexchange calls, which may be either backwards
only or in both directions at the discretion of the Administration or RPOA.
.LP
	b)
	Transit exchange \(em both directions.
.LP
	c)
	 Terminating local exchange \(em no through connection at this stage of 
call set\(hyup, except as a national option for certain classes of users, 
e.g.\ PABXs. 
.LP
	d)
	NT2 \(em may through connect as required.
.LP
.sp 1
\fINote\ 2\fR \ \(em\ If not already done, complete the through connection in
both directions.
.LP
.sp 1
\fINote\ 3\fR \ \(em\ The method of initiating and stopping charging will
depend on the Administration's method of charging for service (e.g.\ pulse
metering, recording call detail and billing,\ etc.). The charging function 
may be performed at different entities at the discretion of the Administration 
and/or RPOA.
.LP
.sp 1
\fINote\ 4\fR \ \(em\ Further study is required on the possible inclusion of an
entity from/to which information is passed and on the information flows
themselves. The \*QReport\*U indications may or may not be sent to the user
terminal and/or to the user depending on the terminals involved.
.LP
.sp 1
.LP
\fINote\ 5\fR \ \(em\ The intended use of the service (transfer capability
required, e.g.\ speech, 3.1\ kHz audio, unrestricted or alternate
speech/unrestricted information transfer) must be indicated as an element of
the call SETUP information flow from the CCA to the CC.
.LP
.sp 1
\fINote\ 6\fR \ \(em\ Tones are used with speech and 3.1 kHz bearer services 
and telephony. The use of disconnect tone is a national option. 
.sp 2P
.LP
.sp 2
2.2.2
	\fIDefinition of information flows\fR 
.sp 1P
.RT
.PP
2.2.2.1
CONNECTED req.ind is used to acknowledge that a previously sent SETUP resp.conf 
has been received and accepted. This is an uncomfirmed 
information flow within the r\d1\u\ relationship and is sent from the CC 
to the CCA. 
.sp 9p
.RT
.PP
2.2.2.2
DISCONNECT req.ind is used to notify that the end user has
disconnected from the connection or cannot be connected (e.g.\ the called 
user is busy). This is used to solicit a confirmed release of local channels 
and 
other resources associated with the connection. In general, it will not 
always result in immediate release of the connection and related resources. 
DISCONNECT req.ind is not confirmed and appears within relationship\ r\d1\u. 
.PP
The following item of information is conveyed with the DISCONNECT req.ind 
information flow: 
.LP
\fIItem\fR 	\fIRelationship\fR 	\fIReq.ind\fR 
.LP
Cause
	r\d1\u	mandatory
.PP
2.2.2.3
PROCEEDING req.ind optionally reports that the received
connection set\(hyup is valid and authorized and that further routing and
progressing of the call is proceeding. The user entity is not required to
provide this indication. This information flow is not confirmed and appears
within relationship\ r\d1\u.
.PP
The following item of information may be conveyed with the
PROCEEDING req.ind information flow:
.LP
\fIItem\fR 	\fIRelationship\fR 	\fIReq.ind\fR 
.LP
Channel ID
	r\d1\u	optional
.PP
2.2.2.4
RELEASE req.ind and resp.conf is used to free the resources
associated with the call/connection such as call references and channels. 
This is a confirmed information flow whose confirmation indicates that 
all resources previously associated with the connection have been freed. 
It appears within 
relationship\ r\d1\uand\ r\d2\u.
.bp
.PP
The following item of information is conveyed with the RELEASE
req.ind and resp.conf information flows:
.LP
\fIItem\fR 	\fIRelationship\fR 	\fIReq.ind\fR 	\fIResp.conf\fR 
.LP
Cause
	r\d1\u, r\d2\u	mandatory
	mandatory
.PP
2.2.2.5
REPORT req.ind is an information flow that is used to report
status and/or other types of information across the network. The type of
information may be indicated (e.g.\ alerting, suspended, hold, resume,\ etc.).
This is an unconfirmed information flow within the relationship of both\ 
r\d1\uand\ r\d2\u. 
.PP
The following items of information are or may be conveyed with the REPORT 
req.ind information flow: 
.LP
.sp 1
\fIItem\fR 	\fIRelationship\fR 	\fIReq.ind\fR 
.LP
	Channel ID
	r\d1\u, r\d2\u	optional
.LP
	Conn. request
	r\d2\u	optional
.LP
	Called line category
	r\d2\u	mandatory
.LP
	Called line status
	r\d2\u	mandatory
.LP
	Report type
	r\d2\u	mandatory
.PP
2.2.2.6
SETUP req.ind is used to request establishment of a
connection. This is a confirmed information flow and SETUP resp.conf is 
used to confirm that the connection has been established. The request for 
establishment of a connection can be originated by either the network or 
the user. This 
information flow is within the\ r\d1\uand\ r\d2\urelationships.
.PP
The following items of information are or may be conveyed in the SETUP 
req.ind and SETUP resp.conf information flows: 
.LP
.sp 1
\fIUse\fR 	\fIItem\fR 	\fIRelationship\fR 	\fIReq.ind\fR 	\fIResp.conf\fR 
.LP
	Protocol info
	Conn. request
	r\d2\u	optional
	optional
.LP
	Bearer info
	Bearer capability
	r\d1\u, r\d2\u	mandatory
.LP
	Bearer info
	Nature of trans.
	r\d2\u	mandatory
.LP
	Bearer info
	Channel ID
	r\d1\u, r\d2\u	mandatory
.LP
	Routing info
	Called number
	r\d1\u, r\d2\u	mandatory
.LP
	Routing info
	Transit network sel.
	r\d1\u, r\d2\u	optional
.LP
	Orig. info
	Calling line ID
	r\d1\u, r\d2\u	optional
.LP
	Term. info
	Connected line ID
	r\d2\u	mandatory
.LP
	Term. info
	Connected line status
	r\d2\u	mandatory
.LP
	Access info
	Low layer compatibility
	r\d1\u	optional
.LP
	Access info
	High layer compatibility
	r\d1\u	optional
.PP
2.2.2.7
SETUP REJECT req.ind is used to notify the CCA that the
SETUP req.ind has been rejected. This information is within the
r\d1\u\ relationship.
.PP
The following items of information are or may be conveyed in the SETUP 
REJECT req.ind information flow: 
.LP
.sp 1
\fIItem\fR 	\fIRelationship\fR 	\fIReq.ind\fR 
.LP
	Channel ID
	r\d1\u	mandatory
.LP
	Reject indication
	r\d1\u	mandatory
.LP
	Cause
	r\d1\u	optional
.sp 1P
.LP
2.2.3 
	 \fIAdditional information flows required for digit\(hyby\(hydigit call\fR 
\fR \fIset\(hyup cases\fR 
.sp 9p
.RT
.PP
Under study.
.RT
.sp 1P
.LP
2.2.4
	\fIInformation flow meanings \(em Summary table\fR 
.sp 9p
.RT
.PP
The individual semantics of the above information flows, and in
particular the relationship between information flow meanings, is summarized 
in Table\ 2\(hy1/Q.71. 
.bp
.RT
.ce
\fBH.T. [T1.71]\fR 
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(342p) .
TABLE\ 2\(hy1/Q.71
.T&
cw(342p) .
 {
\fBInformation flow meanings\fR
 }
.TE
.TS
cw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
Semantics	SETUP req. ind.	SETUP. resp. conf.	SETUP REJECT req. ind.	PROCEEDING req. ind.	REPORT (Alerting) req. ind.	DISCONNECT req. ind.	RELEASE req. ind.	RELEASE resp. conf.	CONNECTED req. ind.
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
Request for connection	X								
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
Connection accepted by user		X							
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
Call information complete		X		X	X				
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
Connection request accepted		X		X	X				
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
Connection request rejected			X						
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
Called user being alerted					X				
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
Connection unavailable						X	X		
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
 {
Demand to disconnect bearer 
resources
 }						X			
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
 {
Demand to release bearer resources with acknowledgement
 }							X		
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
 {
Disconnected \(em ready to be released
 }						X	X		
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
 {
Bearer resources \(em released \(em reallocatable
 }								X	
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
Request to terminate call						X	X		
_
.T&
lw(72p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) .
Setup response accepted									X
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 2\(hy1/Q.71 [T1.71], p.\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
2.3
	\fISDLs\fR 
.sp 9p
.RT
.PP
The SDLs included in this Recommendation cover only the allowable (expected) 
sequences for successful call set\(hyup and release. It is assumed that 
errors detected by the incoming and outgoing signalling system protocols 
are 
handled within those protocol state machines.
.PP
The call controll states describe the state of the entity in terms of the 
states of the relationships in both directions (i.e.\ when describing states 
related to the relationship \*Qr\d1\u\(em\ r\d2\u\*U the CC state identifies 
the states of the relationship over\ r\d1\uand\ r\d2\u). 
.PP
Figure 2\(hy7/Q.71 shows the directional convention used in drawing event 
symbols. 
.RT
.LP
.rs
.sp 10P
.ad r
\fBFigure 2\(hy7/Q.71, p.\fR 
.sp 1P
.RT
.ad b
.RT
.PP
2.3.1
SDLs for the Call Control Agent (CCA) entity are shown in
Figure\ 2\(hy8/Q.71.
.PP
2.3.2
SDLs for the Call Control (CC) entity are shown in
Figure 2\(hy9/Q.71.
.LP
.rs
.sp 29P
.ad r
\fBFigure 2\(hy8/Q.71 (page 1 sur 11), p. 17\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 2\(hy8/Q.71 (page 2 sur 11), p. 18\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 24P
.ad r
\fBFigure 2\(hy8/Q.71 (page 3 sur 11), p. 19\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 24P
.ad r
\fBFigure 2\(hy8/Q.71 (page 4 sur 11), p. 20\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 2\(hy8/Q.71 (page 5 sur 11), p. 21\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 2\(hy8/Q.71 (page 6 sur 11), p. 22\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 2\(hy8/Q.71 (page 7 sur 11), p. 23\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 2\(hy8/Q.71 (page 8 sur 11), p. 24\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 2\(hy8/Q.71 (page 9 sur 11), p. 25\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 2\(hy8/Q.71 (page 10 sur 11), p. 26\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 47P
.ad r
\fBFigure 2\(hy8/Q.71 (page 11 sur 11), p. 27\fR 
.sp 1P
.RT
.ad b
.RT
.LP
.bp