InfoMagic Standards 1993 July/Disc.iso/ccitt/1992/q/q704_3.asc

Text File | 1993-08-15 | 57.3 KB | 2,495 lines

C:\WINWORD\CCITTREC.DOT_______________

    12.6        Automatic allocation of signalling data links

12.6.1    In conjunction with the signalling link activation and restoration pro-
cedures specified in º 12.4, signalling data links may be allocated automati-
cally. Any signalling data link applicable to a link group may be chosen for
a signalling link within that link group.

    The signalling data links applicable to a link group are determined by
bilateral agreement and may, for example, include all speech circuits
between two exchanges. A signalling data link may also be established as a
semipermanent connection via one or more intermediate exchanges.

    When a potential signalling data link is not employed for signalling, it
is normally used for other purposes (e.g. as a speech circuit).

    The identity of the signalling data link to be used for a particular sig-
nalling link is determined at one of the two involved signalling points and
reported to the remote end by a signalling data link connection order mes-
sage. The signalling point controlling the choice of signalling data link is
the signalling point initiating the activation or restoration procedure or, in
the case when both ends initiate the procedure at the same time, the signal-
ling point having the highest signalling point code (included in the label of
the message).

12.6.2    When a signalling data link has been chosen at a signalling point, the
data link is made unavailable for other uses (e.g. as a speech circuit) and an
order to connect the appointed signalling data link to a signalling terminal is
sent to the signalling point at the remote end of the signalling link.

    The signallingùdataùlinkùconnectionùorder message contains:

ù    the label, indicating the destination and originating signalling
points and the identity of the signalling link to activate or restore;

ù    the signallingùdataùlinkùconnectionùorder;

ù    the identity of the signalling data link.

    Formats and codes for the signallingùdataùlinkùconnectionùorder mes-
sage appear in º 15.

12.6.3    Upon reception of the signallingùdataùlinkùconnectionùorder,
the following applies:

a)    In the case when the signalling link to which a received signallingù
dataùlinkùconnectionùorder message refers is inactive as seen
from the receiving signalling point, the message is regarded as an
order to activate the concerned signalling link, resulting in, for
example, allocation of a signalling terminal. The signalling data
link indicated in the signallingùdataùlinkùconnectionùorder is
then connected to the associated signalling terminal and signalling
link initial alignment starts. An acknowledgement is sent to the
remote signalling point.

    If it is not possible to connect the appointed signalling data link to a
signalling terminal (e.g. because there is no working signalling ter-
minal available), the acknowledgement contains an indication
informing the remote signalling point whether or not an alternative
signalling data link should be allocated to the concerned signalling
link.

b)    If the signalling point receives a signallingùdataùlinkùconnec-
tionùorder when waiting for an acknowledgement, the order is
disregarded in the case when the signalling point code of the
receiving signalling point is higher than the signalling point code
of the remote signalling point. If the remote signalling point has
the higher signalling point code, the message is acknowledged and
the signalling data link referred to in the received message is con-
nected.

c)    If a signallingùdataùlinkùconnectionùorder is received in other
situations (e.g. in the case of an error in procedure), no actions are
taken.

    The signallingùdataùlinkùconnectionùacknowledgement contains the
label, indicating the destination and originating signalling points and the
identity of the signalling link to activate or restore, and one of the following
signals:

ù    connectionùsuccessful signal, indicating that the signalling data
link has been connected to a signalling terminal;

ù    connectionùnotùsuccessful signal, indicating that it was not pos-
sible to connect the signalling data link to a signalling terminal,
and that an alternative signalling data link should be allocated;

ù    connectionùnotùpossible signal, indicating that it was not possi-
ble to connect the signalling data link to a signalling terminal, and
that no alternative signalling data link should be allocated.

    The formats and codes for the signalling data link connection acknowledge-
ment message appear in º 15.

12.6.4    When the signalling point initiating the procedure receives a message
indicating that signalling data link and signalling terminal have been con-
nected at the remote end, the signalling data link is connected to the associ-
ated signalling terminal and initial alignment starts (see º 12.4).

    If the acknowledgement indicates that it was not possible to connect the sig-
nalling data link to a signalling terminal at the remote end, an alternative
signalling data link is allocated and a new signallingùdataùlinkùconnec-
tionùorder is sent (as specified above). However, if the acknowledgement
indicates that no alternative signalling data link should be allocated, the acti-
vation or restoration procedure is terminated for the concerned signalling
link.

    If no signallingùdataùlinkùconnectionùacknowledgement or order is
received from the remote signalling point within a time T7 (see º 16), the
signallingùdataùlinkùconnectionùorder is repeated.

12.6.5    When a signalling data link is disconnected in conjunction with sig-
nalling link restoration or deactivation, the signalling data link is made idle
(and available, e.g. as a speech circuit).

12.7    Different signalling link management procedures at the two ends of a
link set

    Normally both ends of a link set will use the same signalling link
management procedures.

    However, if one end uses the basic signalling link management proce-
dures, the other end may use the signalling link management procedures
based on automatic allocation of signalling terminals. In that case a signal-
ling link includes a predetermined signalling terminal at one end, a predeter-
mined signalling data link and at the other end, any of the signalling
terminals applicable to the concerned link group.

    If one end of a link set uses the basic signalling link management pro-
cedures and the other end uses the signalling link management procedures
based on automatic allocation of signalling terminals, the values of the ini-
tial alignment timeùout T2 do not have to be different at the two ends of
the link set.

13        Signalling route management

13.1    General

    The purpose of the signalling route management function is to ensure
a reliable exchange of information between the signalling points about the
availability of the signalling routes.

    The unavailability, restriction15) and availability of a signalling route is
communicated by means of the transferùprohibited, transferù
restricted15) and transfer allowed procedures, respectively in ºº 13.2,
13.4 and 13.3.

    Recovery of signalling route status information is made by means of the sig-
nallingùrouteùsetùtest procedure specified in º 13.5.

    In the international signalling network, congestion of a route set is commu-
nicated by means of the transferùcontrolled (TFC) messages specified in º
13.6.

    In national networks, congestion of a signalling route set may be communi-
cated by means of the TFC as specified in ºº 13.7 and 13.8 and the signal-
ling route set congestion test procedure specified in º 13.9.

13.2        Transfer prohibited

13.2.1    The transferùprohibited procedure is performed at a signalling point
acting as a signalling transfer point for messages relating to a given destina-
tion, when it has to notify one or more adjacent signalling points that they
must no longer route the concerned messages via that signalling transfer
point.

    The transferùprohibited procedure makes use of the transferùpro-
hibited message which contains:

ù    the label, indicating the destination and originating points;

ù    the transferùprohibited signal; and

ù    the destination for which traffic transfer is no longer possible.

    Format and code of these messages appear in º 15.

    Transfer prohibited messages are always addressed to an adjacent signalling
point. They may use any available signalling route that leads to that signal-
ling point.16)

13.2.2    A transferùprohibited message relating to a given destination X is
sent from a signalling transfer point Y in the following cases:

i)    When signalling transfer point Y starts to route (at changeover,
changeback, forced or controlled rerouting) signalling destined to
signalling point X via a signalling transfer point Z not currently
used by signalling transfer point Y for this traffic. In this case the
transferùprohibited message is sent to signalling transfer point Z.

ii)    When signalling transfer point Y recognizes that it is unable to
transfer signalling traffic destined to signalling point X (see ºº
5.3.3 and 7.2.3). In this case a transferùprohibited message is sent
to all accessible adjacent signalling points (Broadcast method).

iii)    When a message destined to signalling point X is received at sig-
nalling transfer point Y and Y is unable to transfer the message. In
this case the transfer prohibited message is sent to the adjacent sig-
nalling point from which the message concerned was received
(Response Method).

iv)    When an adjacent signalling point Z becomes accessible, STP Y
sends to Z a transfer prohibited message concerning destination X,
if X is inaccessible from Y (see º 9).

v)    When a signalling transfer point Y restarts, it broadcasts to all
accessible adjacent signalling points transfer prohibited messages
concerning destination X, if X is inaccessible from Y (see º 9).

    As long as transferùprohibited messages for a destination are being trans-
mitted according to criteria i), ii), iv), or v) above, and also within T8 (see º
16) after the last transferùprohibited message was transmitted, no trans-
ferùprohibited messages will be sent via the Response Method (criterion
iii) above) referring to that destination.

    Examples of the above situation appear in Recommendation Q.705.

13.2.3    When a signalling point receives a transferùprohibited message from
signalling transfer point Y it performs the actions specified in º 7 (since
reception of transferùprohibited message indicates the unavailability of the
concerned signalling route, see º 3.4.1). In other words, it may perform
forced reùrouting and, if appropriate, generate additional transferùprohib-
ited messages.

13.2.4    In some circumstances it may happen that a signalling point receives
either a repeated transferùprohibited message relating to a nonexistent
route (i.e. there is no route from that signalling point to the concerned desti-
nation via signalling transfer point Y, according to the signalling network
configuration) or to a destination which is already inaccessible, due to previ-
ous failures; in this case no actions are taken.

13.3        Transfer allowed

13.3.1    The transferùallowed procedure is performed at a signalling point,
acting as signalling transfer point for messages relating to a given destina-
tion, when it has to notify one or more adjacent signalling points that they
may start to route to it, if appropriate, the concerned messages.

    The transferùallowed procedure makes use of the transferùallowed
message which contains:

ù    the label, indicating the destination and originating points;

ù    the transferùallowed signal; and

ù    the destination for which transfer is now possible.

    The format and code of these messages appear in º 15.

    Transfer allowed messages are always addressed to an adjacent signalling
point. They may use any available signalling route that leads to that signal-
ling point.17)

13.3.2    A transferùallowed message relating to a given destination ôXö is
sent from signalling transfer point ôYö in the following cases:

i)    When signalling transfer point ôYö stops routing (at changeback or
controlled rerouting) signalling traffic destined to signalling point
ôXö via a signalling transfer point ôZö (to which the concerned
traffic was previously diverted as a consequence of changeover or
forced rerouting). In this case the transferùallowed message is
sent to signalling transfer point ôZö.

ii)    When signalling transfer point ôYö recognizes that it is again able
to transfer signalling traffic destined to signalling point ôXö (see
ºº 6.2.3 and 8.2.3). In this case a transferùallowed message is
sent to all accessible adjacent signalling points. (Broadcast
method).

    Examples of the above situations appear in Recommendation Q.705.

13.3.3    When a signalling point receives a transferùallowed message from
signalling transfer point ôYö, it performs the actions specified in º 8 (since
reception of a transferùallowed message indicates the availability of the
concerned signalling route, (see º 3.4.2)). In other words, it may perform
controlled reùrouting and, if appropriate, generate additional transferù
allowed messages.

13.3.4    In some circumstances it may happen that a signalling point receives
either a repeated transferùallowed message or a transferùallowed mes-
sage relating to a nonùexistent signalling route (i.e. there is no route from
that signalling point to the concerned destination via signalling transfer
point Y according to the signalling network configuration); in this case no
actions are taken.

13.4        Transferùrestricted (National option)

13.4.1    The transfer restricted procedure is performed at a signalling point
acting as a signalling transfer point for messages relating to a given destina-
tion, when it has to notify one or more adjacent signalling points that they
should, if possible, no longer route the concerned messages via the signal-
ling transfer point.

    The transferùrestricted procedure makes use of the transferù
restricted message which contains:

ù    the label, indicating the destination and originating points;

ù    the transferùrestricted signal, and

ù    the destination for which traffic is no longer desirable.

    Formats and codes of this message appear in º 15.

    Transfer restricted messages are always adressed to an adjacent signalling
point. They may use any available signalling route that leads to that signal-
ling point.

    Note ù Undesirable situations result in increased signalling delays, possi-
bly overloading portions of the network. These inefficiencies could be
avoided if the traffic can be appropriately diverted.

13.4.2    A transferùrestricted message relating to a given destination ôXö is
sent from a signalling transfer point ôYö when the normal link set (com-
bined link set) used by signalling point ôYö to route to destination ôXö
experiences a longùterm failure such as an equipment failure, or there is
congestion on an alternate link set currently being used to destination ôXö.
In this case, a transferùrestricted message is sent to all accessible adjacent
signalling points.

    When an adjacent signalling point ôXö becomes accessible, the STP ôYö
sends to ôXö transferùrestricted messages concerning destinations that are
restricted from ôYö (see º 9).

    When a signalling point Y restarts, it broadcasts to all accessible adjacent
signalling points transfer restricted messages concerning destinations
restricted from ôYö (see º 9).

    Note ù Characterization of long term failure remains for further study.

13.4.3    When a signalling point receives a transferùrestricted message from
signalling transfer point ôYö and has an alternative equal priority link set
available and not restricted to destination ôXö, it performs the actions in º
8.2. In other words, it performs controlled rerouting to maintain the
sequence of messages while diverting them to the alternative link set. If it
cannot perform alternate routing to destination ôXö because no alternative
link set is available, it may generate additional transferùrestricted mes-
sages.

13.4.4    In some circumstances, it may happen that a signalling point receives
either a repeated transferùrestricted message or a transferùrestricted mes-
sage relating to a nonùexistent route (i.e. there is no route from that signal-
ling point to the concerned destination via signalling transfer point ôYö,
according to the signalling network configuration); in this case, no actions
are taken.

13.4.5    When a transferùrestricted message is received updating a transferù
prohibited status, signalling traffic management decides if an alternative
route is available or restricted; if it is not (i.e. no alternative route exists), the
concerned traffic is restarted towards the signalling point from which the
transferùrestricted message was received. Otherwise, no other actions are
taken.

13.5        Signallingùrouteùsetùtest

13.5.1    The signallingùrouteùsetùtest procedure is used at a signalling
point to test whether or not signalling traffic towards a certain destination
may be routed via an adjacent signalling transfer point.

    The procedure makes use of the signallingùrouteùsetùtest mes-
sage, and the transferùallowed and the transferùprohibited procedures.

    The signallingùrouteùsetùtest message contains:

ù    the label, indicating the destination and originating points;

ù    the signallingùrouteùsetùtest signal;

ù    the destination, the accessibility of which is to be tested; and

ù    the current route status of the destination being tested.18)

    Format and coding of this message appear in º 15.

13.5.2    A signallingùrouteùsetùtest message is sent from a signalling
point after a transferùprohibited or transferùrestricted19) message is
received from an adjacent signalling transfer point. In this case, a signal-
lingùrouteùsetùtest message is sent to that signalling transfer point refer-
ring to the destination declared inaccessible or restricted by the transferù
prohibited or transferùrestricted19) message, every T10 period (see º 16)
until a transferùallowed message, indicating that the destination has
become accessible, is received.

    This procedure is used in order to recover the signalling route availability
information that may not have been received because of some signalling
network failure.

13.5.3    A signallingùrouteùsetùtest message is sent to the adjacent signal-
ling transfer point as an ordinary signalling network management message.

13.5.4    At the reception of a signallingùrouteùsetùtest message, a signal-
ling transfer point will compare the status of the destination in the received
message with the actual status of the destination. If they are the same, no
further action is taken. If they are different, one of the following messages is
sent in response, dictated by the actual status of the destination:

ù    a transferùallowed message, referring to the destination the acces-
sibility of which is tested, if the signalling transfer point can reach
the indicated destination via a signalling link not connected to the
signalling point from which the signallingùrouteùsetùtest mes-
sage was originated, and via the normal routing;

ù    a transferùrestricted19) message when access to the destination is
possible via an alternative to the normal routing which is less effi-
cient, but still not via the signalling point from which the signal-
ling routeùsetùtest was originated;

ù    a transferùprohibited message in all other cases (including the
inaccessibility of that destination).

13.5.5    At the reception of the transferùprohibited or transferùallowed
message, the signalling point will perform the procedures specified in ºº
13.2.3 or 13.2.4 and 13.3.3 or 13.3.4 respectively.

13.6        Transfer controlled (International network)

    The only use made of the transfer controlled procedure in the interna-
tional signalling network is to convey the congestion indication from the SP
where congestion was detected to the originating SP (see º 11.2.3) in a
transferùcontrolled message.

    The transferùcontrolled message contains:

ù    the label, indicating the destination and originating points;

ù    the transfer controlled signal;

ù    the identity of the congested destination.

    The format and coding of the transfer controlled message appear in º 15.

13.7        Transfer controlled (National option with congestion priorities)

13.7.1    The transferùcontrolled procedure is performed at a signalling trans-
fer point for messages relating to a given destination, when it has to notify
one or more originating signalling points that they should no longer send to
the concerned destination messages with a given priority or lower.

    The transferùcontrolled procedure makes use of the transferùcon-
trolled message which contains:

ù    the label, indicating the destination and originating points,

ù    the transferùcontrolled signal,

ù    the destination for which messages with a congestion priority lower
than the specified congestion status should no longer be sent, and

ù    the current congestion status encountered in routing a particular
message towards the concerned destination.

    The format and coding of this message appear in º 15.

13.7.2    A transferùcontrolled message relating to a given destination ôXö is
sent from a signalling transfer point ôYö in response to a received message
originating from signalling point ôZö destined to signalling point ôXö when
the congestion priority of the concerned message is less than the current
congestion status of the signalling link selected to transmit the concerned
message from ôYö to ôXö.

    In this case, the transferùcontrolled message is sent to the originating point
ôZö with the congestion status field set to the current congestion status of
the signalling link.

13.7.3    When the originating signalling points ôZö receive a transferùcon-
trolled message relating to destination ôXö, if the current congestion status
of the signalling route set towards destination ôXö is less than the conges-
tion status in the transferùcontrolled message, it updates the congestion
status of the signalling route set towards destination ôXö with the value of
the congestion status carried in the transferùcontrolled message.

13.7.4    If within T15 (see º 16) after the receipt of the last transferùcon-
trolled message relating to destination ôXö, signalling point ôZö receives
another transferùcontrolled message relating to the same destination, the
following action is taken: If the value of the congestion status carried in the
new transferùcontrolled message is greater than the current value of the
congestion status of the signalling route set towards destination ôXö, then
the current value is updated by the new value.

13.7.5    If T15 (see º 16) expires after the last update of the signalling route
set towards destination ôXö by a transferùcontrolled message relating to
the same destination, the signallingùrouteùsetùcongestionùtest proce-
dure is invoked (see º 13.9).

13.7.6    In some circumstances it may happen that a signalling point receives
a transferùcontrolled message relating to a destination which is already
inaccessible due to previous failures; in this case the transferùcontrolled
message is ignored.

13.8        Transfer controlled (National option without congestion priorities)

    The only use made of the TFC procedure by the national signalling
network, using multiple congestion states without congestion priorities, is to
convey the congestion indication primitive from the SP where congestion
was detected to the originating SP (see º 11.2.5) in a transferùcontrolled
message.

    The transferùcontrolled message contains:

ù    the label, indicating the destination and originating points;

ù    the transferùcontrolled signal;

ù    the identity of the congested destination;

ù    the current congestion status encountered in routing a particular
message towards the concerned destination.

    The format and coding of this message appear in º 15.

13.9        Signallingùrouteùsetùcongestionùtest (National Option)

13.9.1    The signallingùrouteùsetùcongestionùtest procedure is used at
an originating signalling point to update the congestion status associated
with a route set towards a certain destination. The purpose is to test whether
or not signalling messages destined towards that destination with a given
congestion priority or higher may be sent.

    In the case of a processor restart the congestion status of all signalling
route sets will be initialized to the zero value. The response mechanism
within the transferùcontrolled procedure will correct signalling route sets
whose congestion status does not have the zero value.

    The procedure makes use of the signallingùrouteùsetùconges-
tionùtest message, and the transferùcontrolled procedure.

    The signallingùrouteùsetùcongestionùtest message contains:

ù    the label, indicating the destination and originating points, and

ù    the signallingùrouteùsetùcongestionùtest signal.

    The format and coding of this message appear in º 15.

13.9.2    The signallingùrouteùsetùcongestionùtest message differs from
other signalling network management messages in that it is not assigned the
highest congestion priority. Instead, the congestion priority assigned to a
signallingùrouteùsetùcongestionùtest message to be sent to a given
destination is equal to one less than the current congestion status associated
with the signalling route set towards the destination.

13.9.3    If within T16 (see º 16), after sending a signallingùrouteùsetùcon-
gestionùtest message, a transferùcontrolled message relating to the con-
cerned destination is received, the signalling point updates the congestion
status of the signalling route set towards the concerned destination with the
value of the congestion status carried in the transferùcontrolled message.
Following this, the procedures specified in ºº 13.9.4 and 13.9.5 are per-
formed.

    If T16 (see º 16) expires after sending a signallingùrouteùsetùconges-
tionùtest message without a transferùcontrolled message relating to the
concerned destination having been received, the signalling point changes
the congestion status associated with the signalling route set towards the
concerned destination to the next lower status.

13.9.4    Provided that the signalling route set towards destination ôXö is not in
the ôunavailableö state, a signallingùrouteùsetùcongestionùtest mes-
sage is sent from an originating signalling point to destination ôXö in the
following cases:

i)    When T15 (see º 16) expires after the last update of the congestion
status of the signalling route set toward destination ôXö by a trans-
ferùcontrolled message relating to the same destination.

ii)    When T16 (see º 16) expires after sending a signallingùrouteù
setùcongestionùtest message to destination ôXö without a trans-
ferùcontrolled message relating to the same destination having
been received. After the congestion status has been decremented
by one, the test is repeated, unless the congestion status is zero.

13.9.5    At the reception of a signallingùrouteùsetùcongestionùtest mes-
sage, a signalling transfer point will route it as an ordinary message, i.e.
according to the procedure specified in º 2.3.5.

13.9.6    When a signallingùrouteùsetùcongestionùtest message reaches
its destination, it is discarded.

14        Common characteristics of message signal unit formats

14.1    General

    The basic signal unit format which is common to all message signal
units is described in RecommendationQ.703, º 2. From the point of view of
the Message Transfer Part level 3 functions, common characteristics of the
message signal units are the presence of:

ù    the service information octet;

ù    the label, contained in the signalling information field, and, in par-
ticular, the routing label.

14.2        Service information octet

    The service information octet of message signal units contains the ser-
vice indicator and the subùservice field. The structure of the service infor-
mation octet is shown in Figure 13/Q.704.

Figure 13/Q.704 - CCITT 35510



14.2.1        Service indicator

    The service indicator is used by signalling handling functions to per-
form message distribution (see º 2.4) and, in some special applications, to
perform message routing (see º 2.3).

    The service indicator codes for the international signalling network
are allocated as follows:



bit
s

D

C

B

A

0

0

0

0

Signalling network management messages

0

0

0

1

Signalling network testing and mainte-
nance messages

0

0

1

0

Spare

0

0

1

1

SCCP

0

1

0

0

Telephone User Part

0

1

0

1

ISDN User Part

0

1

1

0

Data User Part (call and circuit related
messages)

0

1

1

1

Data User Part (facility registration and
cancellation messages)

1

0

0

0

Reserved for MTP Testing User Part

1

0

0

1

ⁿ

1

0

1

0

·

1

0

1

1

·

1

1

0

0

²

spare

1

1

0

1

·

1

1

1

0

·

1

1

1

1

■

    The allocation of the service indicator codes for national signalling
networks is a national matter. However, it is suggested to allocate the
same service indicator code to a User Part which performs similar
functions as in the international network.

14.2.2        Subùservice field

    The subùservice field contains the network indicator (bits C and D)
and two spare bits (bits A and B).

    The network indicator is used by signalling message handling func-
tions (e.g., in order to determine the relevant version of a User Part), see ºº
2.3 and 2.4.

    If the network indicator is set to 00 or 01, the two spare bits, coded 00,
are available for possible future needs that may require a common solution
for all international User Parts.

    If the network indicator is set to 10 or 11, the two spare bits are for
national use. They may be used, for example, to indicate message priority,
which is used in the optional flow control procedure in national applica-
tions.

    The network indicator provides for discrimination between interna-
tional and national messages. It can also be used, for example, for the dis-
crimination between functionally two national signalling networks, each
having different routing label structures and including up to 16 User Parts
defined by the 16 possible codes of the service indicator.

    In the case of only one national signalling network the spare code of
the network indicator reserved for national use can be used, for example, to
define an additional 16 User Parts (making a total of 32 User Parts) for that
national signalling network.

    The network indicator codes are allocated as follows:



bit
s

D

C

0

0

International network

0

1

Spare (for international use only)

1

0

National network

1

1

Reserved for national use

    The international spare code (01) should not be used for implementing fea-
tures which are to be provided both internationally and nationally.

    In national applications, when the discrimination provided by the network
indicator between international and national messages is not used, i.e.
in a closed national signalling network seen from the signalling point
of view, the whole subùservice field can be used independently for
different User Parts.

14.3    Label

    The structure and content of the label is defined for each User Part
and is defined in the relevant specification. The common part of the label
used for signalling message handling, the routing label, is specified in º2.2.

15        Formats and codes of signalling network management messages

15.1    General

15.1.1    The signalling network management messages are carried on the sig-
nalling channel in message signal units, the format of which is described in
º 14 and in Recommendation Q.703, º 2. In particular, as indicated in º 14.2
these messages are distinguished by the configuration 0000 of the service
indicator (SI). The subùservice field (SSF) of the messages is used accord-
ing to the rules indicated in º 14.2.2.

15.1.2    The signalling information field consists of an integral number of
octets and contains the label, the heading code and one or more signals and
indications. The structure and function of the label, and of the heading code,
are described in ºº 15.2 and 15.3 respectively; the detailed message formats
are described in the following sections. For each message the sequence of
fields is shown in the corresponding figure, including fields that may or may
not be present.

    In the figures, the fields are shown starting from the right to the left
(i.e. the first field to be transmitted is at the right). Within each field the
information is transmitted least significant bit first. Spare bits are coded 0
unlesss otherwise indicated.

15.2    Label

    For signalling network management messages the label coincides
with the routing label and indicates the destination and originating signal-
ling points of the message; moreover, in the case of messages related to a
particular signalling link, it also indicates the identity of the signalling link
among those interconnecting the destination and originating points. The
standard label structure of Message Transfer Part level 3 messages appears
in Figure 14/Q.704; the total length is 32 bits.

Figure 14/Q.704 - CCITT 35870



    The meaning and use of the destination point code (DPC) and of the origi-
nating point code (OPC) fields are described in º 2. The signalling link code
(SLC) indicates the signalling link, connecting the destination and originat-
ing points, to which the message is related. If the message is not related to a
signalling link, or another particular code is not specified, it is coded 0000.

15.3    Heading code (H0)

    The heading code (H0) is the 4 bit field following the label and identi-
fies the message group.

    The different heading codes are allocated as follows:

0000    Spare

0001    Changeover and changeback messages

0010    Emergency changeover message

0011    Transfer controlled and signalling route set congestion messages

0100    Transferùprohibitedùallowedùrestricted messages

0101    Signallingùrouteùsetùtest messages

0110    Management inhibit messages

0111    Traffic restart allowed message

1000    Signallingùdataùlinkùconnection messages

1001    Spare

1010    User part flow control messages

    The remaining codings are spare.

    The synopsis of singalling network management messages is given in Table
1/Q.704.

15.4        Changeover message

15.4.1    The format of the changeover message is shown in Figure 15/Q.704.

Figure 15/Q.704 - CCITT 35880



15.4.2    The changeover message is made up of the following fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.4.3

ù    Forward sequence number of last accepted message signal unit (7
bits)

ù    A filler bit coded 0

15.4.3    The heading code H1 contains signal codes as follows:



bit

D

C

B

A

0

0

0

1

Changeover order signal

0

0

1

0

Changeover acknowledgement signal

15.5        Changeback message

15.5.1    The format of the changeback message is shown in Figure 16/Q.704.

Figure 16/Q.704 - CCITT 35580



15.5.2    The changeback message is made up of the following fields:

ù    Label (32 bits) see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.5.3

ù    Changeback code (8 bits): see º 15.5.4

15.5.3    The header code H1 contains signal codes as follows:



bit

D

C

B

A

0

1

0

1

Changeback declaration signal

0

1

1

0

Changeback acknowledgement signal

15.5.4    The changeback code is an 8 bit code assigned by the signalling
point which sends the message according to the criteria described
in º 6.

15.6        Emergency changeover message

15.6.1    The format of the emergency changeover message is shown in Figure
17/Q.704.

Figure 17/Q.704 - CCITT 35570



15.6.2    The emergency changeover message is made up of the following
fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.6.3

15.6.3    The header code H1 contains signal codes as follows:



bit

D

C

B

A

0

0

0

1

Emergency changeover order signal

0

0

1

0

Emergency changeover acknowledgement
signal

15.7        Transferùprohibited message

15.7.1    The format of the transferùprohibited message is shown in Figure
18/Q.704.

Figure 18/Q.704 - CCITT 35890



15.7.2    The transferùprohibited message is made up of the following fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.7.3

ù    Destination (14 bits): see º 15.7.4

ù    Spare bits (2 bits) code 00

15.7.3    The heading code H1 contains one signal code as follows:



bit

D

C

B

A

0

0

0

1

Transferùprohibited signal

15.7.4    The destination field contains the identity of the signalling
point to which the message refers.

15.8        Transferùallowed message

15.8.1    The format of the transferùallowed message is shown in Figure 19/
Q.704.

Figure 19/Q.704 - CCITT 35890



15.8.2    The transferùallowed message is made up of the following fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.8.3

ù    Destination (14 bits): see º 15.7.4

ù    Spare bits (2 bits) coded 00

    Note ù For the use of the 2 spare bits in the national option for a SIF com-
patibility mechanism, see Recommendation Q.701, º 7.2.6.

15.8.3    The heading code H1 contains one signal code as follows:



bit

D

C

B

A

0

1

0

1

Transferùallowed signal

15.9        Transfer restricted message (national option)

15.9.1    The format of the transfer restricted message is shown in Figure 18/
Q.704.

15.9.2    The transfer restricted message is made up of the following fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.9.3

ù    Destination (14 bits): see º 15.9.4

ù    Spare (2 bits) coded 00

15.9.3    The heading code H1 contains one signal code as follows:



bit

D

C

B

A

0

0

1

1

Transfer restricted

15.9.4    The destination field contains the identity of the signalling
point to which the message refers.

15.10        Signallingùrouteùsetùtest message

15.10.1    The format of the signallingùrouteùsetùtest message is shown in
Figure 20/Q.704.

Figure 20/Q.704 - CCITT 35890



15.10.2    This message is made up of the following fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.10.3

ù    Destination (14 bits): see º 15.7.4

ù    Spare bits (2 bits) coded 00

15.10.3    The heading code H1 contains signal codes as follows:



bit

D

C

B

A

0

0

0

1

Signallingùrouteùsetùtest signal for pro-
hibited destination

0

0

1

0

Signallingùrouteùsetùtest signal for
restricted destination (national option)

15.11        Management inhibit message

15.11.1    The format of the management inhibit message is shown in Figure
20a/Q.704.

Figure 20a/Q.704 - CCITT 35570



15.11.2    The management inhibit message is made up of the following fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.11.3

15.11.3    The header code H1 contains signal codes as follows:



bit

D

C

B

A

0

0

0

1

Link inhibit signal

0

0

1

0

Link uninhibit signal

0

0

1

1

Link inhibited acknowledgement signal

0

1

0

0

Link uninhibited acknowledgement signal

0

1

0

1

Link inhibit denied signal

0

1

1

0

Link force uninhibit signal

0

1

1

1

Link local inhibit test signal

1

0

0

0

Link remote inhibit test signal

15.12        Traffic restart allowed message

15.12.1    The format of the traffic restart allowed message is shown in Figure
21/Q.704.

Figure 21/Q.704 - CCITT 35570



15.12.2    The traffic restart allowed message is made up of the following
fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.12.3

15.12.3    The heading code H1 contains one signal code as follows:



bit

D

C

B

A

0

0

0

1

Traffic restart allowed signal

15.13        Signallingùdataùlinkùconnectionùorder message

15.13.1    The format of the signallingùdataùlinkùconnectionùorder mes-
sage is shown in Figure 22/Q.704.

Figure 22/Q.704 - CCITT 35900



15.13.2    The signallingùdataùlinkùconnectionùorder message is made
up of the following fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.13.3

ù    Signalling data link identity (12 bits): see º 15.13.4

ù    Spare bits (4 bits) coded 0000.

15.13.3    The heading code H1 contains one signal code as follows:



bit

D

C

B

A

0

0

0

1

Signallingùdataùlinkùconnectionùorder
signal

15.13.4    The signalling data link identity field contains the circuit iden-
tification code (CIC), or the bearer identification code (BIC) in
case of a 64 kbit/s channel used to carry submultiplex data streams,
of the transmission link corresponding to the signalling data link.

15.14        Signallingùdataùlinkùconnectionùacknowledgement message

15.14.1    The format of the signallingùdataùlinkùconnectionùacknowl-
edgement message is shown in Figure22a/Q.704.

Figure 22a/Q.704 - CCITT 35570



15.14.2    The signallingùdataùlinkùconnection acknowledgement mes-
sage is made up of the following fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.14.3

15.14.3    The heading code H1 contains signal codes as follows:



bit

D

C

B

A

0

0

1

0

Connectionùsuccessful signal

0

0

1

1

Connectionùnotùsuccessful signal

0

1

0

0

Connectionùnotùpossible signal

15.15        Transfer controlled message

15.15.1    The format of the TFC message is shown in Figure 22b/Q.704.

Figure 22b/Q.704 - CCITT 35900



15.15.2    The transfer controlled message is made up of the following fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.15.3

ù    Destination (14 bits): see º 15.15.4

ù    Spare (2 bits): see º15.15.5

15.15.3    The heading code H1 contains one signal code as follows:



bit

D

C

B

A

0

0

1

0

Transfer controlled signal

15.15.4    The destination field carries the address of the destination to
which the message refers.

15.15.5    In national signalling networks using multiple congestion
states, the spare bits in the transfer controlled message are used to
carry the congestion status associated with the destination.

15.16        Signallingùrouteùsetùcongestionùtest message (national
option)

15.16.1    The format of the signallingùrouteùsetùcongestionùtest mes-
sage is shown in Figure 22c/Q.704.

Figure 22c/Q.704 - CCITT 35570



15.16.2    The signallingùrouteùsetùcongestion test message is made up of
the following fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.16.3

15.16.3    The heading code H1 contains one signal code as follows:



bit

D

C

B

A

0

0

0

1

Signallingùrouteùsetùcongestionùtest
signal

15.17        User part unavailable message

15.17.1    The format of the user part unavailable message is shown in Figure
22d/Q.704.

Figure 22d/Q.704 - CCITT 35898



15.17.2    The user part unavailable message is made up of the following
fields:

ù    Label (32 bits): see º 15.2

ù    Heading code H0 (4 bits): see º 15.3

ù    Heading code H1 (4 bits): see º 15.17.3

ù    Destination (14 bits): see º 15.15.4

ù    Spare (2 bits): coded 00

ù    User part identity (4 bits): see º 15.17.4

ù    Spare (4 bits) coded 0000

15.17.3    The heading code H1 contains signal codes as follows:



bit

D

C

B

A

0

0

0

1

User part unavailable

15.17.4    The user part identity is coded as follows:



b
i
t

D

C

B

A

0

0

0

0

Spare

0

0

0

1

Spare

0

0

1

0

Spare

0

0

1

1

SCCP

0

1

0

0

TUP

0

1

0

1

ISUP

0

1

1

0

DUP

0

1

1

1

Spare

1

0

0

0

MTP Testing User Part

1

0

0

1

ⁿ



t
o

²Spare



1

1

1

1

■

TABLE 1/Q.704

Heading code allocation of signalling network management messages



Messa
ge
Group

H1

H0

00
00

00
01

00
10

00
11

01
00

01
01

01
10

01
11

10
00

10
01

10
10

10
11

11
00

11
01

11
10

11
11

00
00

CHM

00
01

C
O
O

C
O
A

C
B
D

C
B
A

ECM

00
10

E
C
O

E
C
A

FCM

00
11

R
C
T

TF
C

TFM

01
00

TF
P

*

TF
R

TF
A

*

RSM

01
01

R
ST

R
S
R

MIM

01
10

LI
N

L
U
N

LI
A

L
U
A

LI
D

LF
U

L
LT

L
RT

TRM

01
11

T
R
A

DLM

10
00

D
L
C

C
SS

C
N
S

C
N
P

10
01

UFC

10
10

U
P
U

10
11

11
00

11
01

11
10

11
11

Note ù Values marked * should not be used (codes used in the YellowBook
for TFP and TFA acknowledgement).
CBA    Changebackùacknowledgement signal
CBD    Changebackùdeclaration signal
CHM    Changeover and changeback messages
CNP    Connectionùnotùpossible signal
CNS    Connectionùnotùsuccessful signal
COA    Changeoverùacknowledgement signal
COO    Changeoverùorder signal
CSS    Connectionùsuccessful signal
DLC    Signallingùdataùlinkùconnectionùorder signal
DLM    Signallingùdataùlinkùconnectionùorder message
ECA    Emergencyùchangeoverùacknowledgement signal
ECM    Emergencyùchangeover message

ECO    Emergencyùchangeoverùorder signal
FCM    Signallingùtrafficùflowùcontrol messages
RCT    Signallingùrouteùsetùcongestionùtest signal
RSM    Signallingùrouteùsetùtest message
RSR    Signallingùrouteùsetùtest signal for restricted destination
(national option)
RST    Signallingùrouteùsetùtest signal for prohibited destination
TFR    Transferùrestricted signal (national option)
TFA    Transferùallowed signal
TFC    Transferùcontrolled signal
TFM    Transferùprohibitedùtransferùallowedùtransferùrestricted mes-
sages
TFP    Transferùprohibited signal
TRA    Trafficùrestartùallowed signal
TRM    Trafficùrestartùallowed message
MIM    Management inhibit messages
LID    Link inhibit denied signal
LFU    Link forced uninhibit signal
LIN    Link inhibit signal
LIA    Link inhibit acknowledgement signal
LUA    Link uninhibit acknowledgement signal
LUN    Link uninhibit signal
LLT    Link local inhibit test signal
LRT    Link remote inhibit test signal
UFC    User part flow control messages
UPU    User part unavailable signal

16    State transition diagrams

16.1    General

    º 16 contains the description of the signalling network functions
described in ºº 2 to 13 in the form of state transition diagrams according to
the CCITT Specification and Description Language (SDL).

    A set of diagrams is provided for each of the following major func-
tions:

ù    signalling message handling (SMH), described in º 2;

ù    signalling traffic management (STM), described in ºº 4 to 11;

ù    signalling route management (SRM), described in º 13;

ù    signalling link management (SLM), described in º 12.

16.1.1    For each major function a figure illustrates a subdivision into func-
tional specification blocks, showing their functional interactions as well as
the interactions with the other major functions. In each case this is followed
by figures showing state transition diagrams for each of the functional spec-
ification blocks.

    The detailed functional breakdown shown in the following diagrams is
intended to illustrate a reference model and to assist interpretation of the
text in the earlier sections. The state transition diagrams are intended to
show precisely the behaviour of the signalling system under normal and
abnormal conditions as viewed from a remote location. It must be empha-
sized that the functional partitioning shown in the following diagrams is
used only to facilitate understanding of the system behaviour and is not
intended to specify the functional partitioning to be adopted in a practical
implementation of the signalling system.

16.2    Drafting conventions

16.2.1    Each major function is designated by its acronym (e.g. SMH = signal-
ling message handling).

16.2.2    Each functional block is designated by an acronym which identifies it
and also identifies the major function to which it belongs (e.g. HMRT = sig-
nalling message handlingùmessage routing; TLAC = signalling traffic
managementùlink availability control).

16.2.3    External inputs and outputs are used for interactions between different
functional blocks. Included within each input and output symbol in the state
transition diagrams are acronyms which identify the functions which are the
source and destination of the message, e.g.:

L2 « L3            indicates that the message is sent between functional levels:

        from:    functional level 2,

        to:    functional level 3.

RTPC « TSRC    indicates that the message is sent within a functional
level (3 in this case):

        from:    signalling route managementùtransfer prohibited con-
trol,

        to:    signalling traffic managementùsignalling routing control.

16.2.4    Internal inputs and outputs are only used to indicate control of timeù
outs.

16.2.5    Notations for national operations

    National options are included in the main body of the state transition
diagrams (STDs) with dotted or dashed lines; if their use should exclude or
modify some of the international logic, the relevant sections are marked ôtö
and a note is added to the figure. Also, the options are marked as follows:

    Transfer restricted ù dashed lines.

    Multiple congestion states ù dotted lines (with the hatched symbols
removed where shown).

16.3    Signalling message handling

    Figure 23/Q.704 shows a subdivision of the signalling message han-
dling (SMH) function into smaller functional specification blocks and also
shows the functional interactions between them. Each of these functional
specification blocks is described in detail in a state transition diagram as fol-
lows:

a)    message discrimination (HMDC) is shown in Figure 24/Q.704;

b)    message distribution (HMDT) is shown in Figure 25/Q.704;

c)    message routing (HMRT) is shown in Figure 26/Q.704;

d)    handling of messages under signalling link congestion is shown in
Figure 26a/Q.704.

16.4    Signalling traffic management

    Figure 27/Q.704 shows a subdivision of the signalling traffic manage-
ment (STM) function into smaller functional specification blocks and also
shows functional interactions between them. Each of these functional speci-
fication blocks is described in detail in a state transition diagram as follows:

a)    link availability control (TLAC) is shown in Figure 28/Q.704;

b)    signalling routing control (TSRC) is shown in Figure 29/Q.704;

c)    changeover control (TCOC) is shown in Figure 30/Q.704;

d)    changeback control (TCBC) is shown in Figure 31/Q.704;

e)    forced rerouting control (TFRC) is shown in Figure 32/Q.704;

f)    controlled rerouting control (TCRC) is shown in Figure 33/Q.704;

g)    signalling traffic flow control (TSFC) is shown in Figure 34a/
Q.704;

h)    signalling route set congestion control (TRCC) is shown in Figure
29a/Q.704;

i)    signalling point restart control (TPRC) is shown in Figure 34b/
Q.704.

16.5    Signalling link management

    Figure 35/Q.704 shows a subdivision of the signalling link manage-
ment function (SLM) into smaller functional specification blocks and also
shows functional interactions between them. Each of these functional speci-
fication blocks is described in detail in a state transition diagram as follows:

a)    link set control (LLSC) is shown in Figure 36/Q.704;

b)    signalling link activity control (LSAC) is shown in Figure 37/
Q.704;

c)    signalling link activation (LSLA) is shown in Figure 38/Q.704;

d)    signalling link restoration (LSLR) is shown in Figure 39/Q.704;

e)    signalling link deactivation (LSLD) is shown in Figure 40/Q.704;

f)    signalling terminal allocation (LSTA) is shown in Figure 41/Q.704;

g)    signalling data link allocation (LSDA) is shown in Figure 42/Q.704.

16.6    Signalling route management

    Figure 43/Q.704 shows a subdivision of the signalling route manage-
ment (SRM) function into smaller functional specification blocks and also
shows functional interactions between them. Each of these functional speci-
fication blocks is described in detail in a state transition diagram as follows:

a)    transfer prohibited control (RTPC) is shown in Figure 44/Q.704;

b)    transfer allowed control (RTAC) is shown in Figure 45/Q.704;

c)    transfer restricted control (RTRC) is shown in Figure 46c/Q.704;

d)    transfer controlled control (RTCC) is shown in Figure 46a/Q.704;

e)    signalling route set test control (RSRT) is shown in Figure 46/
Q.704;

f)    signallingùrouteùsetùcongestionùtest control (RCAT) is shown
in Figure 46b/Q.704.

16.7        Abbreviations used in Figures 23/Q.704 onwards

BSNT    Backward sequence number of next signal unit to be transmit-
ted

DPC        Destination point code

FSNC    Forward sequence number of last message signal unit accepted
by remote level 2

HMCG    Signalling link congestion

HMDC    Message discrimination

HMDT    Message distribution

HMRT    Message routing

L1        Level 1

L2        Level 2

L3        Level 3

L4        Level 4

LLSC    Link set control

LSAC    Signalling link activity control

LSDA    Signalling data link allocation

LSLA    Signalling link activation

LSLD    Signalling link deactivation

LSLR    Signalling link restoration

LSTA    Signalling terminal allocation

MGMT    Management system

RCAT    Signallingùrouteùsetùcongestionùtest control

RSRT    Signalling route set test control

RTAC    Transfer allowed control

RTCC    Transfer controlled control

RTPC    Transfer prohibited control

RTRC    Transfer restricted control

SLM    Signalling link management

SLS        Signalling link selection

SLTC    Signalling link test control

SMH    Signalling message handling

SRM    Signalling route management

STM    Signalling traffic management

TCBC    Changeback control

TCOC    Changeover control

TCRC    Controlled rerouting control

TFRC    Forced rerouting control

TLAC    Link availability control

TPRC    Signalling point restart control

TRCC    Signalling route set congestion control

TSFC    Signalling traffic flow control

TSRC    Signalling routing control

16.8        Timers and timer values

    The following timers have been defined. The ranges are given below.
The values, in brackets, are the minimum values for use when routes with
long propagation delays are used (e.g., routes including satellite sections).

T1    Delay to avoid message misùsequencing on changeover.

500 (800) to 1200 ms.

T2    Waiting for changeover acknowledgement.

700 (1400) to 2000 ms.

T3    Time controlled diversionùdelay to avoid misùsequencing on
changeback.

500 (800) to 1200 ms.

T4    Waiting for changeback acknowledgement (first attempt).

500 (800) to 1200 ms.

T5    Waiting for changeback acknowledgement (second attempt).

500 (800) to 1200 ms.

T6    Delay to avoid message misùsequencing on controlled rerouting.

500 (800) to 1200 ms.

T7    Waiting for signalling data link connection acknowledgement.

1 to 2 seconds.

T8    Transfer prohibited inhibition timer (transient solution).

800 to 1200 ms.

T9    Not used.

T10    Waiting to repeat signalling route set test message.

30 to 60 seconds.

T11    Transfer restricted timer. (This is one way of implementing the
function described in º 13.4 and mainly intended to simplify
STPs.)

30 to 90 seconds.

T12    Waiting for uninhibit acknowledgement.

800 to 1500 ms.

T13    Waiting for force uninhibit.

800 to 1500 ms.

T14    Waiting for inhibition acknowledgement.

2 to 3 seconds.

T15    Waiting to start signalling route set congestion test.

2 to 3 seconds.

T16    Waiting for route set congestion status update.

1.4 to 2 seconds.

T17    Delay to avoid oscillation of initial alignment failure and link
restart.

800 to 1500 ms.

T18    Timer at restarting STP, waiting for signalling links to become
available.

20 seconds (provisional value).

T19    Timer at restarting STP, started after T18, waiting to receive all
traffic restart allowed messages.

4 seconds (provisional value).

T20    Timer at restarting STP, started after T19, waiting to broadcast
traffic restart allowed messages, and restart remaining traffic.

4 seconds (provisional value).

T21    Timer at restarting signalling point having no STP function, wait-
ing to restart traffic routed through adjacent SP;

AND timer at STP adjacent to restarting STP, waiting for traffic
restart allowed message;

AND timer at SP having no STP function adjacent to restarting SP,
waiting to restart any traffic to route through adjacent SP.

30 seconds (provisional value).

T22    Local inhibit test timer.

3 min to 6 min (provisional value).

T23    Remote inhibit test timer.

3 min to 6 min (provisional value).

T24    Stabilising timer after removal of local processor outage, used in
LPO latching to RPO (national option).

500 ms (provisional value).