home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD2.mdf
/
ccitt
/
1992
/
q
/
q65.asc
< prev
next >
Wrap
Text File
|
1991-12-31
|
37KB
|
1,062 lines
SECTION 1 - METHODOLOGY
Contents of Recommendation Q.65
Stage 2 of the method for characterization
of services supported by an ISDN
Page
1. Introduction ..................................................... 7
2. Steps of the method .............................................. 8
Appendix I: Formats and graphical conventions used in the Stage 2
service descriptions ...................................... 19
SECTION 1 - METHODOLOGY
Recommendation Q.65
STAGE 2 OF THE METHOD FOR THE CHARACTERIZATION OF
SERVICES SUPPORTED BY AN ISDN1
1. Introduction
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.
1.2 Stage 2 of the method takes as its input, the Stage 1 basic and
supplementary service descriptions contained in the I.200-Series 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 the following figure:
FIGURE 1/Q.65
Stage 1/Stage 2 relationship
1 Note - 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.310 (e.g., executive
processes, elementary functions) needs urgent further study.
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.
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 iterations 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.
1.5 Stage 2 of the method employs techniques that provide the following
desirable characteristics:
- 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;
- a detailed description of what functions and information flows
are to be provided, but not how they are to be
implemented;
- a single functional specification which can be applied in a
number of different physical realizations for
providing the service;
- requirements for protocol and switching capabilities as input to
Stage 3 of the method;
- consistency, within the ISDN principles, of service and protocol
Recommendations which permits substantial
implementation flexibility to administrations and manufacturers.
Note - The Stage 2 description method and specific service work currently
address only ISDN user to ISDN user calls in an ISDN. The extension to
interworking with other networks is for further study.
2. Steps of the method
2.1 Step 1 - functional model
A functional model is derived for each basic and supplementary service.
In each case the model is matched to the requirements and characteristics of the
service concerned.
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).)
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.
2.1.1 Functional entities
Functional entities are initially derived from an overall understanding of
the network functions needed to support the service. Functional entities are
defined as follows:
- 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;
- a functional entity is described in terms of the control of one
instance of a service (e.g., one call or one
connection);
- 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);
- 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;
- 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;
- 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.
2.1.2 Functional entity relationships
Services are supported by the cooperative actions of a set of
functional entities. Cooperation requires that communication
relationships be established.
- Each communicating pair of functional entities in a specific
service functional model is said to be in a
relationship.
- 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.
- 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.
- 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.
- Relationships are assigned type identifiers (e.g., r1, r2, r3
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.
2.1.3 Derivation of the functional model
Based on the above definitions the functional model for a particular
service is derived using the following criteria and guidelines:
- 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;
- 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;
- 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,
Figure 2/Q.65 illustrates a functional model.
FIGURE 2/Q.65
Example of a functional model
Note 1 - FE1, FE2 etc. are functional entities (type A, B, etc.) defined to meet
the requirements of the particular service considered. The diagram also includes a
functional extension to FE4.
Note 2 - rl, rj, etc. are relationship types between communicating pairs of
functional entities.
Note 3 - This diagram illustrates the following points:
a) a functional model may include more than one FE of the same type
(e.g., type B);
b) a functional model may include more than one relationship of the
same type (e.g., rj);
c) an extension to an FE does not modify its type of relationship to
adjacent FEs (e.g., r1).
2.1.4 Relationship between basic and supplementary service models
The functional model for a supplementary service is based upon, and
includes at least part of a basic service model.
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.
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.
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.
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.
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).
Figure 3/Q.65 illustrates these relationships.
FIGURE 3/Q.65
Alternative ways of adding supplementary service functions to
basic service functional model
2.2 Step 2 - information flow diagrams
2.2.1 Identification of information flows
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 "information flow" and will
have a name descriptive of the intent of the information flow.
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.
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.
FIGURE 4/Q.65
Example of information flow diagram
(the example shows part of an information flow
diagram corresponding to the functional
model examples in Figure 2/Q.65
Notes to Figure 4/Q.65
(1) 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.
(2) A reference number is assigned to each point in the overall sequence at
which functional entity actions are shown.
(3) A brief description of the most significant functional entity actions is
shown on the diagram.
(4) 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., reg ind) written below line in lower
case. For unconfirmed information flows and the "request" part of
confirmed information flows the label "req.ind" is shown in lower case below the
information flow arrows. For the "confirmation" part of confirmed
information flows the label "resp.conf" is used.
(5) 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.
(6) In a particular functional entity column:
- 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;
- 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;
- 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
"request" part of the CHECK information flow.
(7) The Stage 1 service interactions are inputs to and outputs from the
Stage 2 information flow diagram. Stage 1 service interactions from
the user are either of the form XXXXX.req or XXXXX.resp. Stage 1
service interactions to the User are either of the form XXXXX.ind or
XXXXX.conf.
2.2.2 Definition of individual information flows
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.
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.
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
system protocols.
2.3 Step 3 - SDL diagrams for functional entities
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.
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.
Note - The primitives to the underlying signalling system are derived from the
information flows between the functional entities.
FIGURE 5/Q.65
Relationship of primitives, information flows and SDLs
2.4 Step 4 - functional entity actions
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.
2.5 Step 5 - allocation of functional entities to physical locations
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.
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.
For the allocation of functional entities, it should be noted that:
a) a functional entity may in principle, be allocated to any
physical location;
b) a number of functional entities may be allocated to the same
physical location;
c) for every supplementary service, network scenarios which include
the location of its basic service functional entities
should be defined;
d) different physical locations of functional entities may imply
minor differences in node capabilities (e.g., the
transmission path switch-through actions may depend on
whether the access is in an exchange or an ISPBX);
e) the relationships between pairs of functional entities, according
to the functional model used, should be invariant for
all of the recommended scenarios.
Item e) implies e.g., that the information flows for a supplementary
service would not be affected by a re-allocation of one or more of the
required functional entities from public network exchange to an ISPBX or vice-versa.
All identified scenarios will be considered in Stage 3 for definition
of signalling protocols, switching capabilities and service centre
capabilities.
Appendix I
(to Recommendation Q.65)
Formats and graphical conventions used in the Stage 2
service description
1. General
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.
1.1 Introduction
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.
2. Steps of the method
2.1 Step 1 - identification of a functional model
2.1.1 Functional model description
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.
The relationship types are numbered r1, r2, r3 etc., for ease of
reference (see Figure 3/Q.65 for an example).
2.1.2 Description of functional entity "x"
This section provides a brief prose description of the functional
entity "x". Each functional entity identified in the model has a corresponding
section and prose description.
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 section 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.
2.2 Step 2 - information flow diagrams
2.2.1 Identification of information flows
This section 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.
The following guidelines are observed in drafting these information
flow diagrams:
- 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;
- 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 "req.ind" and
"resp.conf" 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.
Further details on drafting conventions can be found in the notes to
Figure 4/Q.65.
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 section 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.
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.
This number is unique within the Stage 2 description of a particular
service (all variants).
2.2.2 Definition of information flow name
2.2.2.1 Meaning of information flow name
This section 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 a confirmed or
unconfirmed information flow. If confirmed, the meaning of the confirmation is
also identified.
2.2.2.2 Information content of information flow name
This section 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.
2.3 Step 3 - SDL diagrams for functional entities
This section contains an SDL diagram for each of the functional
entities identified in the functional model in section 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-1/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 ("hooks") in the
basic service SDL are for further study.
FIGURE I-1/Q.65
An example technique to describe extension to
functional entity of the basic service
The reference numbers used in the relevant information flow diagrams
(see section 2.2.1 above) are also used in the SDL diagrams. Where a group of
actions appears only on the SDL diagram, a reference number is also assigned.
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 section 2.4 below) of the functional entity actions required at this point
in the sequence.
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.
- A signal conveying a variable received from the preceding (in the
context of call setup) functional entity or user.
- A signal conveying a variable sent to the subsequent functional entity
or user.
- A signal conveying a variable received from the subsequent functional
entity or user.
- A signal conveying a variable sent to the preceding functional entity
or user.
XX X.X XX A set of alphanumeric characters which constitute the name
of an object (e.g., a state, signal, variable or timer).
'XX XXX' An informal text.
Each process must begin with a START symbol. The START symbol is
empty.
/*XXXXXX*/ Designates a note.
]--- Designates a note.
2.4 Step 4 - functional entity actions
This section contains descriptions of actions required for each
functional entity and is identified by the reference number, as
described in sections 2.2.1 and 2.3.
The presentation form for functional entity actions is illustrated in
Figure I-2/Q.65.
┌────────────────────────────────────────────────────────────────────────┐
│ Functional entity - FE2 │
│ │
│ Reference number: NN1 │
│ │
│ Process service request │
│ │
│ - Receive and acknowledge user's service request │
│ - Interact with user to accumulate information │
│ - Select network access resource │
│ - Reserve facilities, both directions, as required │
│ │
│ Reference number: NN2 │
│ │
│ - Interact with user to obtain call address │
│ - Determine and indicate end of dialling │
└────────────────────────────────────────────────────────────────────────┘
FIGURE I-2/Q.65
Example of descriptions of functional entity actions
2.5Step 5 - allocation of functional entities to physical locations
This section 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.
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.
The conventions used for the matrix are illustrated in
Figure I-3/Q.65.
FIGURE I-3/Q.65
Example of a scenario matrix format
Possible physical locations and their corresponding symbolic
representation are:
Terminal equipment; Type 1 or terminal adapter: TE
Network termination; Type 2: NT2 (typically an ISPBX)
Local exchange: LE
Transit exchange: TR
Service centre: SC
