home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-22 | 164.9 KB | 4,765 lines |
-
-
-
- 5i'
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- FASCICLE VI.7
-
-
-
-
-
-
- Recommendations Q.700 to Q.716
-
-
-
- SPECIFICATIONS OF
-
- SIGNALLING SYSTEM No. 7
-
-
-
- Blanc
-
-
-
- MONTAGE: PAGE 2 = PAGE BLANCHE
-
-
-
-
-
-
-
-
-
-
-
- SECTION 1
-
- GENERAL
-
-
-
- Recommendation Q.700
-
-
- INTRODUCTION TO CCITT SIGNALLING SYSTEM No. 7
-
-
-
-
- 1 General
-
-
- This Recommendation provides an overview of the Signalling
- System by describing the various functional elements of CCITT No. 7
- and the relationship between these functional elements. This Recom-
- mendation provides a general description of functions and capabili-
- ties of the Message Transfer Part (MTP), Signalling Connection Con-
- trol Part (SCCP), Telephone User Part, ISDN User Part (ISDN-UP),
- Transaction Capabilities (TC), and the Operations, Maintenance and
- Administration Part (OMAP) which are covered elsewhere in the Q.700
- to Q.795 series of Recommendations. However, in the case of con-
- tradiction between the specifications and Q.700, the Q.700 to Q.795
- specification shall apply.
-
- Supplementary Services in CCITT S.S. No.7 ISDN applications
-
-
-
-
-
-
-
-
-
- are described in the Q.73x series of Recommendations.
-
- In addition to these functions in the CCITT No. 7 signalling
- system, the Q.700 to Q.795 series of Recommendations describes the
- CCITT No. 7 network structure, and also specifies the Tests and
- Measurements applicable to CCITT No. 7.
-
- This Recommendation is also a specification of those aspects
- such as CCITT S.S. No. 7 Architecture, Flow Control and general
- compatibility rule which are not specified in separate Recommenda-
- tions, and are applicable to the overall scope of S.S. No. 7.
-
- The remainder of this Recommendation describes:
-
- - S 2: Signalling network concepts components and
- modes;
-
- - S 3: The functional blocks within CCITT Signal-
- ling System No. 7 and the services provided by them;
-
- - S 4: CCITT Signalling System No. 7 protocol
- layering and its relationship to OSI modelling;
-
- - S 5: Node, application entity and user part
- addressing;
-
- - S 6: Operations, administration and maintenance
- aspects of CCITT S.S. No. 7;
-
- - S 7: Performance aspects of the functional blocks
- within CCITT S.S. No. 7;
-
- - S 8: Flow control for both the signalling network
- and within nodes;
-
- - S 9: Rules for evolving CCITT S.S. No. 7 proto-
- cols while preserving compatibility with earlier versions;
-
- - S 10: A cross-reference to a glossary of terms.
-
-
- 1.1 Objectives and fields of application
-
-
- The overall objective of Signalling System No. 7 is to provide
- an internationally standardised general purpose common channel sig-
- nalling (CCS) system:
-
- - optimised for operation in digital telecommunica-
- tions networks in conjunction with stored program controlled
- exchanges;
-
- - that can meet present and future requirements of
- information transfer for inter-processor transactions within
- telecommunications networks for call control, remote control, and
- management and maintenance signalling;
-
-
-
-
-
-
-
-
-
-
- - that provides a reliable means for transfer of
- information in correct sequence and without loss or duplication.
-
-
- The signalling system meets requirements of call control sig-
- nalling for telecommunication services such as the telephone, ISDN
- and circuit switched data transmission services. It can also be
- used as a reliable transport system for other types of information
- transfer between exchanges and specialised centres in telecommuni-
- cations networks (e.g. for management and maintenance purposes).
- The system is thus applicable for multipurpose uses in
-
- networks that are dedicated for particular services and in
- multiservices networks. The signalling system is intended to be be
- applicable in international and national networks.
-
- The scope of CCITT S.S. No. 7 encompasses both circuit related
- and non-circuit related signalling.
-
- Examples of applications supported by CCITT S.S. No. 7 are:
-
- - PSTN,
-
- - ISDN,
-
- - Interaction with Network Databases, Service Con-
- trol Points for service control,
-
- - Mobiles (Public Land Mobile Network),
-
- - Operations Administration and Maintenance of Net-
- works.
-
- The signalling system is optimized for operation over
- 64-kbit/s digital channels. It is also suitable for operation over
- analogue channels and at lower speeds. The system is suitable for
- use on point-to-point terrestrial and satellite links. It does not
- include the special features required for use in
- point-to-multipoint operation but can, if required, be extended to
- cover such an application.
-
-
- 1.2 General characteristics
-
-
- Common channel signalling is a signalling method in which a
- single channel conveys, by means of labelled messages, signalling
- information relating to, for example, a multiplicity of circuits,
- or other information such as that used for network management. Com-
- mon channel signalling can be regarded as a form of data communica-
- tion that is specialised for various types of signalling and infor-
- mation transfer between processors in telecommunications networks.
-
- The signalling system uses signalling links for transfer of
- signalling messages between exchanges or other nodes in the
- telecommunication network served by the system. Arrangements are
- provided to ensure reliable transfer of signalling information in
-
-
-
-
-
-
-
-
-
- the presence of transmission disturbances or network failures.
- These include error detection and correction on each signalling
- link. The system is normally applied with redundancy of signalling
- links and it includes functions for automatic diversion of signal-
- ling traffic to alternative paths in case of link failures. The
- capacity and reliability for signalling may thus be dimensioned by
- provision of a multiplicity of signalling links according to the
- requirements of each application.
-
-
- 1.3 Components of CCITT S.S. No. 7
-
-
- CCITT S.S. No. 7 consists of a number of components or func-
- tions which are defined as a series of Q.700 to Q.795 Recommenda-
- tions.
-
- CCITT S.S. No. 7 function Recommendations
-
- Message Transfer Part (MTP) Q.701-Q.704, Q.706,
- Q.707
-
- Telephone User Part (TUP) Q.721-Q.725
-
- (including supplementary services)
-
- Supplementary services Q.730
-
- Data User Part (DUP) Q.741 (note 1)
-
- ISDN User Part (ISDN-UP) Q.761-Q.764, Q.766
-
- Signalling Connection Control Part (SCCP)
- Q.711-Q.714, Q.716
-
- Transaction Capabilities (TC) Q.771-Q.775
-
- Operations Maintenance and Administration Part (OMAP)
- Q.795
-
- Note 1 - Functions of the DUP are fully specified in
- Recommendation X.61.
-
-
- Other Q.700 to Q.795 series Recommendations which describe
- other aspects of the signalling system but not part of the CCITT
- S.S. No. 7 signalling interfaces are:
-
- Title Recommendations
-
- Signalling Network Structure Q.705
-
- Numbering of International Signalling Point Codes
- Q.708
-
- Hypothetical signalling reference connection Q.709
-
-
-
-
-
-
-
-
-
-
- PABX application Q.710
-
- CCITT S.S. No. 7 Test Specification (General) Q.780
-
- MTP Level 2 Test Specification Q.781
-
- MTP Level 3 Test Specification Q.782
-
- TUP Test Specification Q.783
-
- Monitoring and measurements for the CCITT S.S. No.7 network
- Q.791
-
- S 3 of Q.700 describes the relationship between these com-
- ponents.
-
-
- 1.4 Description techniques in the Q.700 to Q.795 series of
- Recommendations
-
-
- The CCITT S.S. No. 7 Recommendation series define the signal-
- ling system using prose description which is complemented by SDL
- diagrams and state transition diagrams. Should any conflict arise
- between the text and the SDL definition, the textual description is
- taken as definitive.
-
- Message sequence charts or arrow diagrams are used to illus-
- trate examples of signalling procedures, but are not considered
- definitive.
-
-
- 2 CCITT S.S. No. 7 signalling network
-
-
-
- 2.1 Basic concepts
-
-
- A telecommunications network served by common channel signal-
- ling is composed of a number of switching and processing nodes
- inter-connected by transmission links. To communicate using CCITT
- No. 7, each of these nodes requires to implement the necessary
- "within node" features of CCITT S.S. No. 7 making that node a sig-
- nalling point within the CCITT S.S. No. 7 network. In addition,
- there will be a need to interconnect these signalling points such
- that CCITT S.S. No. 7 signalling information (data) may be conveyed
- between them. These data links are the signalling links of CCITT
- S.S. No. 7 signalling network.
-
- The combination of signalling points and their interconnecting
- signalling links form the CCITT S.S. No. 7 signalling network.
-
-
- 2.2 Signalling network components
-
-
-
-
-
-
-
-
-
-
-
- 2.2.1 Signalling points
-
-
- In specific cases there may be a need to partition the common
- channel signalling functions at such a (physical) node into logi-
- cally separate
-
- entities from a signalling network point of view; i.e., a
- given (physical) node may be defined as more than one signalling
- point. One example is an exchange at the boundary between interna-
- tional and national signalling networks.
-
- Any two signalling points, for which the possibility of com-
- munication between their corresponding User Part function exists,
- are said to have a signalling relation.
-
- The corresponding concept for a given User Part is called a
- user signalling relation.
-
- An example is when two telephone exchanges are directly con-
- nected by a bundle of speech circuits. The exchange of telephone
- signalling relating to these circuits then constitutes a user sig-
- nalling relation between the Telephone User Part functions in those
- exchanges in their role as signalling points.
-
- Another example is when administration of customer and routing
- data in a telephone exchange is remotely controlled from an opera-
- tion and maintenance centre by means of communication through a
- common channel signalling system.
-
-
- Examples of nodes in a signalling network that constitutes
- signalling points are:
-
- - exchanges (switching centres),
-
- - operation, administration and maintenance cen-
- tres,
-
- - service control points,
-
- - signalling transfer points.
-
- All signalling points in a CCITT S.S. No. 7 network are iden-
- tified by a unique code known as a point code (Recommendation Q.704
- refers).
-
-
- 2.2.2 Signalling links
-
-
- The common channel signalling system uses signalling links to
- convey the signalling messages between two signalling points. A
- number of signalling links that directly interconnect two signal-
- ling points which are used as a module constitute a signalling
- link-set. Although a link set typically includes all parallel sig-
- nalling links, it is possible to use more than one link set in
-
-
-
-
-
-
-
-
-
- parallel between two signalling points. A group of links within a
- link set that have identical characteristics (e.g., the same data
- link bearer rate) is called a link group.
-
- Two signalling points that are directly interconnected by a
- signalling link are, from a signalling network structure point of
- view, referred to
-
- as adjacent signalling points. Correspondingly, two signalling
- points that are not directly interconnected are non-adjacent sig-
- nalling points.
-
-
- 2.2.3 Signalling modes
-
-
- The term "signalling mode" refers to the association between
- the path taken by a signalling message and the signalling relation
- to which the message refers.
-
- In the associated mode of signalling, the messages relating to
- a particular signalling relation between two adjacent points are
- conveyed over a link set, directly interconnecting those signalling
- points.
-
- In the non-associated mode of signalling, the messages relat-
- ing to a particular signalling relation are conveyed over two or
- more linksets in tandem passing through one or more signalling
- points other than those which are the origin and the destination of
- the messages.
-
- The quasi-associated mode of signalling is a limited case of
- the non-associated mode where the path taken by the message through
- the signalling network is pre-determined and, at a given point in
- time, fixed.
-
- Signalling System No. 7 is specified for use in the associated
- and quasi-associated modes. The Message Transfer Part does not
- include features
-
- to avoid out-of-sequence arrival of messages or other problems
- that would typically arise in a fully non-associated mode of sig-
- nalling with dynamic message routing.
-
- Examples of signalling modes are illustrated in Figure
- 1/Q.700.
-
-
- Figure 1/Q.700, p.
-
-
-
-
-
- 2.3 Signalling point modes
-
-
-
-
-
-
-
-
-
-
-
- A signalling point at which a message is generated, i.e., the
- location of the source User Part function, is the originating point
- of that message.
-
- A signalling point to which a message is destined, i.e., the
- location of the receiving User Part function, is the destination
- point of that message.
-
- A signalling point at which a message is received on a signal-
- ling link is transferred to another link, i.e., neither the loca-
- tion of the source nor the receiving User part function, is a Sig-
- nal Transfer Point (STP).
-
- For a particular signalling relation, the two signalling
- points thus function as originating and destination points for the
- messages exchanged in the two directions between them.
-
- In the quasi-associated mode, the function of a signalling
- transfer point is typically located in a few signalling points
- which may be dedicated to this function, or may combine this func-
- tion with some other (e.g., switching) function. A signalling
- point serving as a signalling transfer point functions as an ori-
- ginating and destination point for the messages generated and
- received by the level 3 function of the Message Transfer Point also
- in cases when no user functions are present.
-
-
- 2.4 Signalling routes
-
-
- The pre-determined path, consisting of a succession of signal-
- ling points/signalling transfer points and the interconnecting sig-
- nalling links, that a message takes through the signalling network
- between the origination point and the destination point is the sig-
- nalling route for that signalling relation.
-
- All the signalling routes that may be used between an ori-
- ginating point and a destination point by a message traversing the
- signalling network is the signalling route set for that signalling
- relation.
-
-
- 2.5 Signalling network structure
-
-
- The signalling system may be used with different types of sig-
- nalling network structures. The choice between different types of
- signalling network structures may be influenced by factors such as
- the structure of the telecommunication network to be served by the
- signalling system and administrative aspects.
-
- In the case when the provision of the signalling system is
- planned purely on a per signalling relation basis, the likely
- result is a signalling network largely based on associated signal-
- ling, typically supplemented by a limited degree of
- quasi-associated signalling for low volume signalling relations.
- The structure of such a signalling network is mainly determined by
-
-
-
-
-
-
-
-
-
- the patterns of the signalling relations.
-
- Another approach is to consider the signalling network as a
- common resource that should be planned according to the total needs
- for common channel signalling. The high capacity of digital signal-
- ling links in combination with the needs for redundancy for relia-
- bility then typically leads to a signalling network based on a high
- degree of quasi-associated signalling with some
-
- provision for associated signalling for high volume signalling
- relations. The latter approach to signalling network planning is
- more likely to allow exploitation of the potential of common chan-
- nel signalling to support network features that require communica-
- tion for purposes other than the switching of connections.
-
- The worldwide signalling network is structured into two func-
- tionally independent levels, namely the international and national
- levels. This structure makes possible a clear division of responsi-
- bility for signalling network management and allows numbering plans
- of signalling points of the international network and the different
- national networks to be independent of one another.
-
- Further considerations about the structure of the signalling
- network are given in Recommendation Q.705, and the impact on the
- message transfer part in Recommendation Q.701.
-
-
- 3 CCITT S.S. No. 7 functional blocks
-
-
-
- 3.1 Basic functional division
-
-
- The Blue Book CCITT Signalling System No. 7 comprises the fol-
- lowing functional blocks:
-
- - Message Transfer Part (MTP)
-
- - Telephone User Part (TUP)
-
- - ISDN User Part (ISDN-UP)
-
-
- - Signalling Connection Control Part (SCCP)
-
- - Transaction Capabilities (TC)
-
- - Application-Entity (AE) Note 1
-
- - Application-Service-Elements (ASEs) Note
- 1
-
- Note 1 - The glossary shows these as hyphenated terms but the
- usual convention used in this Recommendation will be unhyphenated.
-
- The fundamental principle of the signalling system structure
-
-
-
-
-
-
-
-
-
- is the division of functions into a common Message Transfer Part
- (MTP) on one hand, and separate User Parts for different users on
- the other. This is illustrated in Figure 2/Q.700.
-
- The overall function of the Message Transfer Part is to serve
- as a transport system providing reliable transfer of signalling
- messages between the locations of communicating user functions.
-
- User functions in CCITT S.S. No. 7 MTP terms are:
-
- - the ISDN User Part (ISDN-UP)
-
- - the Telephone User Part (TUP)
-
- - the Signalling Connection Control Part
- (SCCP)
-
- - the Data User Part (DUP)
-
- The term "User" in this context refers to any functional
- entity that utilises the transport capability provided by the Mes-
- sage Transfer Part.
-
- A User Part comprises those functions of, or related to, a
- particular type of user that are part of the common channel signal-
- ling system, typically because those functions need to be specified
- in a signalling context.
-
- The SCCP also has Users. These are:
-
- - the ISDN User Part (ISDN-UP)
-
- - Transaction Capabilities (TC)
-
-
- Figure 2/Q.700, p.
-
-
-
-
-
- 3.2 CCITT S.S. No. 7 architecture
-
-
-
- 3.2.1 General
-
-
- Figure 2/Q.700 shows the Architecture of CCITT S.S. No. 7 and
- illustrates the functional relationship between the various func-
- tional blocks of the Blue Book CCITT S.S. No. 7. Figure 5/Q.700
- shows the relationship between CCITT No. 7 levels and the OSI
- Reference Model Layers. This level/layer relationship is described
- in the following sections.
-
- The initial specification of CCITT No. 7 was based on
- circuit-related telephony control requirements. To meet these
-
-
-
-
-
-
-
-
-
- requirements, CCITT No. 7 was specified in four functional levels,
- the Message Transfer Part comprising levels 1-3, and the User Parts
- as level 4.
-
- Figure 3/Q.700 shows the Functional Levels of CCITT S.S.
- No. 7. As new requirements have emerged, e.g., for non-circuit
- related information transfer, CCITT S.S. No. 7 has also evolved to
- meet these new requirements. There has been a need to align certain
- elements in CCITT No. 7 to the OSI 7 Layer Reference Model.
-
- The result of this evolution is that Functional Levels and OSI
- layers co-exist in CCITT No. 7. For example, the SCCP is a level 4
- User Part in MTP terms, but also provides an OSI Network layer 3
- service. Subsequent sections describe the various functional ele-
- ments of CCITT S.S. No. 7 in terms of levels and layers.
-
-
- Figure 3/Q.700, p.
-
-
- It should be noted that the approach proposed for ISDN archi-
- tecture is to define two orthogonal planes, User and Control, each
- of which has its own 7-layer protocol reference model.
-
- From the perspective of an end user, the service provided by a
- telecommunications network may be regarded as a Network Layer Ser-
- vice (User Plane).
-
- Within the telecommunications network, the techniques of the
- ISDN Protocol Reference Model are applied, and the 7-layer protocol
- structure of the OSI Model can also be used for inter-nodal commun-
- ication to the end user.
-
-
- 3.2.2 Message Transfer Part (MTP) levels 1-3
-
-
- An overview of the MTP is given in Recommendation Q.701. The
- MTP is defined in Recommendations Q.701-Q.704, Q.706 and Q.707.
-
-
-
- 3.2.2.1 Signalling data link functions (level 1)
-
-
- Level 1 defines the physical, electrical and functional
- characteristics of a signalling data link and the means to access
- it. The level 1 element provides a bearer for a signalling link.
-
- In a digital environment, 64-kbit/s digital paths will nor-
- mally be used for the signalling data link. The signalling data
- link may be accessed via a switching function, providing a poten-
- tial for automatic reconfiguration of signalling links. Other types
- of data links, such as analogue links with modems, can also be
- used.
-
- The detailed requirements for signalling data links are
-
-
-
-
-
-
-
-
-
- specified in Recommendation Q.702.
-
-
- 3.2.2.2 Signalling link functions (level 2)
-
-
- Level 2 defines the functions and procedures for and relating
- to the transfer of signalling messages over one individual signal-
- ling data link.
-
- The level 2 functions together with a level 1 signalling data
- link as a bearer, and provides a signalling link for reliable
- transfer of signalling messages between two points.
-
- A signalling message delivered by the higher levels is
- transferred over the signalling link in variable length signal
- units. For proper operation of the signalling link, the signal unit
- comprises transfer control information in addition to the informa-
- tion content of the signalling message.
-
- The detailed requirements for signalling functions are given
- in Recommendation Q.703.
-
-
- 3.2.2.3 Signalling network functions (level 3)
-
-
- Level 3 in principle defines those transport functions and
- procedures that are common to and independent of the operation of
- individual signalling links. These functions fall into two major
- categories:
-
- a) Signalling message handling functions - These
- are functions that, at the actual transfer of the message, direct
- the message to the proper signalling link or User Part.
-
- b) Signalling network management functions - These
- are functions that, on the basis of predetermined data and informa-
- tion about the status of the signalling network, control the
- current message routing and configuration of the signalling network
- facilities. In the event of changes in the status, they also con-
- trol the reconfigurations and other actions to preserve or restore
- the normal message transfer capability.
-
- The detailed requirements for signalling network functions are
- given in Recommendation Q.704.
-
-
- 3.2.3 Level 4: MTP User functions
-
-
- Level 4 consists of the different User Parts. Each User Part
- defines the functions and procedures of the signalling system that
- are particular to a certain type of user of the system. the follow-
- ing entities are defined as User Parts in CCITT S.S. No. 7.
-
-
-
-
-
-
-
-
-
-
-
- 3.2.3.1 Signalling Connection Control Part (SCCP)
-
-
- The SCCP is defined in Recommendations Q.711-Q.716. This
- Recommendation series defines the SCCP capabilities, layer inter-
- faces to MTP
-
- and SCCP users signalling messages, their encoding and signal-
- ling procedures, and cross-office performance. The SCCP provides
- additional functions to the Message Transfer Part to provide such
- connectionless and connection-oriented network services to transfer
- circuit-related, and non-circuit-related signalling information.
-
- The SCCP provides the means to:
-
- - control logical signalling connections in a CCITT
- No. 7 network;
-
- - Transfer Signalling Data Units across the CCITT
- No. 7 network with or without the use of logical signalling connec-
- tions.
-
- SCCP provides a routing function which allows signalling mes-
- sages to be routed to a signalling point based on, for example,
- dialled digits. This capability involves a translation function
- which translates the global title (e.g., dialled digits) into a
- signalling point code and a subsystem number.
-
-
- SCCP also provides a management function, which controls the
- availability of the "subsystems", and broadcasts this information
- to other nodes in the network which have a need to know the status
- of the "subsystem".
-
- The combination of the MTP and the SCCP is called "Network
- Service Part" (NSP). The Network Service Part meets the require-
- ments for layer 3 services as defined in the OSI-Reference Model,
- CCITT Recommendation X.200.
-
-
- 3.2.3.2 Telephone User Part (TUP)
-
-
- The CCITT S.S. No. 7 Telephone User Part is defined in
- Recommendations Q.721-725. The TUP Recommendations define the
- necessary telephone signalling functions for use of S.S. No. 7 for
- international telephone call control signalling. This Recommenda-
- tion series defines the telephone signalling messages, their encod-
- ing and signalling procedures, and cross-office performance.
-
- Supplementary Services handled by the CCITT S.S. No. 7 TUP
- applications are described in Recommendation Q.724, S 10. These
- supplementary services embody TUP signalling messages and pro-
- cedures.
-
-
- 3.2.3.3 Data User Part (DUP)
-
-
-
-
-
-
-
-
-
- The Data User Part is defined in Recommendation Q.741, and the
- functionality fully defined in Recommendation X.61. It defines the
- protocol to control interexchange circuits used on data calls, and
- data call facility registration and cancellation.
-
-
- 3.2.3.4 ISDN User Part (ISDN-UP)
-
-
- The ISDN User Part is defined in Recommendations Q.761-Q.764
- and Q.766. This Recommendation series defines the ISDN network sig-
- nalling messages, their encoding and signalling procedures, and
- cross-office performance. This Recommendation series deals with the
- basic services only.
-
- The ISDN-UP encompasses signalling functions required to pro-
- vide switched services and user facilities for voice and non-voice
- applications in the ISDN.
-
- The ISDN-UP is also suited for application in dedicated tele-
- phone and circuit-switched data networks and in analogue, and mixed
- analogue/digital networks.
-
- The ISDN-UP has an interface to the SCCP (which is also a
- level 4 User Part) to allow the ISDN-UP to use the SCCP for
- end-to-end signalling.
-
- Supplementary Services handled by the CCITT S.S. No. 7 ISDN
- application are described in Recommendation Q.730. These supplemen-
- tary services embody ISDN-UP signalling messages and procedures. In
- some cases these services also include application protocol which
- uses TC and SCCP, as, for example, centralised Closed User Group
- (CUG).
-
-
- 3.2.3.5 Transaction Capabilities
-
-
- Transaction Capabilities is defined in Recommendations
- Q.771-Q.775. This Recommendation series defines the Transaction
- Capabilities signalling messages, their encoding and signalling
- procedures.
-
- Transaction Capabilities consists of two elements. These are:
-
- - Transaction Capabilities Application Part (TCAP);
-
- - Intermediate Service Part (ISP) [The ISP is for
- further study (see Note 1, Figure 5/Q.700)].
-
- The TCAP entity is a functional block residing above the ISP
- in layer 7. TCAP consists of two sub-layers: the Transaction
- sub-layer, and the Component sub-layer. Further details are given
- in Recommendation Q.771.
-
- TC, as currently specified, provides services based on a con-
- nectionless network service. In this case, no ISP layers 4-6
-
-
-
-
-
-
-
-
-
- functions are involved. Connection-oriented TC services, and the
- layer functions of layers 4-6 are for further study.
-
- TC provides the means to establish non-circuit-related commun-
- ication between two nodes in the signalling network.
-
- TC provides the means to exchange operations and replies via a
- dialogue. The X.229 Remote Operations protocol has been extended to
- provide added functionality in order to accommodate specific user
- needs. The operations and parameters are part of the Application
- protocol between TC users.
-
-
-
- 3.2.3.6 Application Entities and Application Service Ele-
- ments
-
-
- In an OSI environment, communication between application
- processes is modelled by communication between "Application Enti-
- ties (AEs)". An Application Entity represents the communication
- functions of an Application process. There may be multiple sets of
- OSI communication functions in an application process, so a single
- application process may be represented by multiple AEs. However,
- each Application Entity is a set of communication capabilities
- whose components are "Application Service Elements". An Application
- Service Element (ASE) is a coherent set of integrated functions.
-
-
- 3.2.3.6.1 Application Entities in a CCITT S.S. No. 7
- environment
-
-
- Figure 4/Q.700 shows the relationship between Application
- Processes and Application Entities, and Application Service Ele-
- ments.
-
- An "Application Process" is considered to be a range of func-
- tions and features which support a particular network requirement.
- For example, an application process in the context of CCITT S.S.
- No. 7 provides the co-ordination across circuit-related protocols
- where required.
-
- An Application Process can be considered as:
-
- a) a co-ordinator of specific aspects of network
- operation (e.g., ISDN Call Control, Mobiles, OA&M);
-
- b) an individual service or supplementary service
- control function (e.g., CUG).
-
- In the CCITT S.S. No. 7 context, the various functional ele-
- ments of the signalling system provide the signalling protocols
- (information elements, messages, and procedures) necessary to sup-
- port the service between nodes.
-
- In a CCITT No. 7 environment, Application Entities (AEs) are
-
-
-
-
-
-
-
-
-
- the elements representing the communication functions of the appli-
- cation process, which are pertinent to inter-nodal communication
- using layer 7 application protocols.
-
- The options for the relationship between an application pro-
- cess, AEs and ASEs can take several forms at a CCITT No. 7 signal-
- ling point. Some examples are shown in Figure 4/Q.700.
-
-
- Figure 4/Q.700 , p.
-
-
-
-
-
- 3.2.3.6.2 Application Service Elements in a CCITT No. 7
- environment
-
-
- Application Service Elements (ASEs) reside in the CCITT S.S.
- No. 7 Architecture Model within layer 7 above TCAP. In the context
- of OSI, TCAP could also be considered to be an ASE.
-
- OMAP has an Application Entity currently containing the TCAP
- ASE and one other ASE. Other ASEs are under study. OMAP is
- described further in S 6.
-
- The Mobile Application Part (MAP) is another example of an
- Application Entity (AE) (see Recommendation Q.1051).
-
- An ASE can include a number of signalling procedures for a
- single service (e.g., Freephone), where this single service is the
- application.
-
- Alternatively, an ASE can include a number of signalling pro-
- cedures for any number of services or functions, encompassed by an
- application (e.g., MAP, OMAP).
-
- Thus, an ASE can define an individual service protocol
- (e.g., CUG), or a complete application protocol (e.g., MAP).
-
- An ASE can only communicate with a compatible peer ASE. The
- operations defined in an ASE may be either symmetrically invoked by
- each entity involved in the dialogue, or asymmetrically invoked by
- one entity only (i.e., on a
-
- "client/server" basis). An example of the former is a "look
- ahead if free" procedure; an example of the latter is a database
- enquiry.
-
-
- 3.2.3.6.3 Addressing for Application Entities (AEs)
-
-
- The SCCP provides a mechanism for addressing "subsystems"
- using Subsystem Numbers (SSNs). The Application Entity is con-
- sidered, in the connectionless mode, equivalent to an SCCP
-
-
-
-
-
-
-
-
-
- subsystem.
-
-
- 3.2.3.6.4 Management of AEs
-
-
- The SCCP provides a mechanism for managing "subsystems" and
- signalling points and informing other nodes of relevant availabil-
- ity status.
-
-
- 4 OSI layering and CCITT S.S. No. 7
-
-
-
- 4.1 General
-
-
- Evolution of the CCITT Signalling System No. 7 architecture
- has been based on the Open Systems Interconnection (OSI) Reference
- Model.
-
- The purpose of the Reference Model of Open Systems Intercon-
- nection for CCITT Applications (Recommendation X.200) is to provide
- a well-defined structure for modelling the interconnection and
- exchange of information between users in a communications system.
- This approach allows standardised procedures
-
- to be defined not only to provide an open systems interconnec-
- tion between users over a single network, but also to permit inter-
- working between networks to allow communication between users over
- several networks in tandem.
-
- At present, OSI only considers connection-oriented protocols,
- that is, protocols which establish a logical connection before
- transferring data. In CCITT S.S. No. 7, the ISDN-UP uses the SCCP
- connection-oriented protocol. The CCITT S.S. No. 7 Network Service
- Part (NSP) provides both connectionless and connection-oriented
- protocol.
-
- The approach taken in the OSI reference model is to partition
- the model used to describe this interconnection and exchange infor-
- mation between users in a communications system into seven layers.
-
- From the point of view of a particular layer, the lower layers
- provide a "transfer service" with specific features. The way in
- which the lower layers are realised is immaterial to the next
- higher layers. Correspondingly, the lower layers are not concerned
- with the meaning of the information coming from higher layers or
- the reasons for its transfer.
-
- The characteristics of each layer are described below.
-
-
-
- 4.1.1 Physical Layer
-
-
-
-
-
-
-
-
-
-
- The Physical Layer (layer 1) provides transparent transmission
- of a bit stream over a circuit built in some physical communica-
- tions medium. It furnishes the interface to the physical media and
- is responsible for relaying bits (i.e., interconnects
- data-circuits). A 64 kbit/s link is assumed for the CCITT S.S.
- No. 7 Physical Layer.
-
-
- 4.1.2 Data Link Layer
-
-
- The Data Link Layer (layer 2) overcomes the limitations
- inherent in the physical circuits and allows errors in transmission
- to be detected and recovered, thereby masking deficiencies in
- transmission quality.
-
-
- 4.1.3 Network Layer
-
-
- The Network Layer (layer 3) transfers data transparently by
- performing routing and relaying of data between end users. One or
- more of the sub-networks may interwork at the Network Layer to pro-
- vide an end user to end user network service. A connectionless net-
- work provides for the transfer of data between end users, making no
- attempt to guarantee a relationship between two or more data mes-
- sages from the same user.
-
-
- 4.1.4 Transport Layer
-
-
- The Transport Layer (layer 4) provides end user to end user
- transfer optimising the use of resources (i.e., network service)
- according to the type and character of the communication, and
- relieves the user of any concern for the details of transfer. The
- Transport Layer always operates end-to-end, enhancing the Network
- Layer when necessary to meet the quality of service objectives of
- the users.
-
-
- 4.1.5 Session Layer
-
-
- The Session Layer (layer 5) co-ordinates the interaction
- within each association between communicating application
- processes. Full and half duplex dialogues are examples of possible
- Session Layer modes.
-
-
- 4.1.6 Presentation Layer
-
-
- The Presentation Layer (layer 6) transforms the syntax of the
- data which is to be transferred into a form recognizable by the
- communicating application processes. For example, the Presentation
- Layer may convert a data stream from ASCII to EBCDIC.
-
-
-
-
-
-
-
-
-
- 4.1.7 Application Layer
-
-
- The Application Layer (layer 7) specifies the nature of the
- communication required to satisfy the users' needs. This is the
- highest layer in the Model and so does not have a boundary with a
- higher layer. The Application Layer provides the sole means for the
- application processes to access the OSI environment.
-
-
- 4.2 Relationship between CCITT S.S. No. 7 layering and the
- OSI model
-
-
- Layers 1-3 comprise functions for the transportation of infor-
- mation from one location to another, possibly via a number of com-
- munication links in tandem. These functions provide the basis on
- which a communication network can be built.
-
- - The SCCP provides, with the MTP, OSI layer ser-
- vices 1-3.
-
- Layers 4-7 define functions relating to end-to-end communica-
- tion. These layers are so defined that they are independent of the
- internal structure of the communication network.
-
- - Transaction Capabilities provides layer 4-7 ser-
- vices.
-
- Layer 7 represents the semantics of a communication, whereas
- layers 1-6 comprise the means by which the communication may be
- realised.
-
- - Application Entities/Application Service Elements
- provide the appropriate Application Layer Protocols in layer 7.
-
-
- Figure 5/Q.700 shows the relationship between SCCP, TC, and
- ASEs to the OSI 7 Layer Reference Model.
-
-
- Figure 5/Q.700, p.
-
-
- The aspect of the SMAP which is then involved with communica-
- tion is the Systems Management Application Entity (SMAE). The SMAE
- is also known as the OMAP AE.
-
-
- 4.3 Primitive Interfaces between CCITT No. 7 Functions
-
-
-
- 4.3.1 General
-
-
- Interfaces between the functional elements of CCITT S.S. No. 7
-
-
-
-
-
-
-
-
-
- are specified using interface primitives. Primitive interface
- definition does not assume any specific implementation of a ser-
- vice.
-
-
- 4.3.2 OSI service primitives
-
-
- Where the functional element of CCITT No. 7 is modelled on the
- OSI 7 layer reference model, e.g., SCCP, TC, service primitives are
- defined in line with Recommendation X.210.
-
-
- In line with Recommendation X.210, Figure 6/Q.700 illustrates
- the relationship between the terms "service", "boundary", "service
- primitives", "peer protocol" and "peer entities". The term "boun-
- dary" applies to boundaries between layers, as well as to boun-
- daries between sub-layers.
-
-
- Figure 6/Q.700, p.
-
-
-
- 4.3.2.1 Service primitives
-
-
- The user of primitives does not preclude any specific imple-
- mentation of a service in terms of interface primitives.
-
- A service primitive consists of a name and one or more parame-
- ters which are passed in the direction of service primitive.
-
- The name of a service primitive contains three elements, as
- defined in Recommendation X.210:
-
- a) a type indicating the direction of the primi-
- tive flow. Four types of service primitives are identified
- (Figure 7/Q.700):
-
- - request a primitive issued by a service
- user to invoke a service element,
-
- - indication a primitive issued by a ser-
- vice provider to advise that a service element has been invoked by
- the service user at the peer service access point or by the service
- provider,
-
- - response a primitive issued by the ser-
- vice user to complete at a particular service access point some
- service element whose invocation has been previously indicated at
- that service access point,
-
- - confirmation a primitive issued by a ser-
- vice provider to complete at a particular service access point some
- service element previously invoked by a request at that service
- access point.
-
-
-
-
-
-
-
-
-
- Not all four types can be associated with all service
- names.
-
- b) a name which specifies the action to be per-
- formed;
-
- c) An initial (or initials) which specifies the
- (sub-)layer providing the service:
-
- - OM for the Operations Management primitives asso-
- ciated with OMAP;
-
- - TC for the TCAP Component sub-layer,
-
- - TR for the TCAP Transaction sub-layer,
-
- - P, S, T, respectively for the Presentation, Ses-
- sion, and Transport layers in the ISP,
-
- - N for the Network Service Part (MTP + SCCP), as
- defined in Recommendation Q.711.
-
-
-
- Figure 7/Q.700, p.
-
-
- Figure 8/Q.700 provides an overview of the primitives used
- between the various functional elements of CCITT No. 7.
-
- The MTP primitives apply to all level 4 users of the MTP.
-
- Similarly, the SCCP Management Primitives N-STATE, N-COORD,
- N-PCSTATE apply to all SCCP subsystems/AEs via TC.
-
- The TC primitives between the ASE and TC provide control of
- connectionless TCAP transactions. Service primitives for
- connection-oriented TC transactions are for further study.
-
-
- Figure 8/Q.700, p.
-
-
-
-
-
- 5 Addressing
-
-
- Addressing of CCITT S.S. No. 7 messages has to be considered
- on a number of levels. For example, the message transfer part uses
- the destination point code to route the message to the appropriate
- signalling point. The called party address field in TUP, or ISUP
- called party number field, in the Initial Address Message is used
- to route the call to the appropriate called destination. The capa-
- bilities of the various CCITT S.S. No. 7 addressing mechanisms are
- illustrated by the signalling message structure.
-
-
-
-
-
-
-
-
-
- 5.1 Signalling message structure
-
-
- A signalling message is an assembly of information, defined at
- level 3 or 4, pertaining to a call, management transaction, etc.,
- that is transferred as an entity by the message transfer function.
-
- Each message contains service information including a service
- indicator identifying the source User Part and possibly additional
- information such as an indication whether the message relates to
- international or national application of the User Part.
-
- The signalling information of the message includes the actual
- user information, such as one or more telephone or data call con-
- trol signals, management and maintenance information, etc., and
- information identifying the type and format of the message. It also
- includes a label that provides information enabling the message to
- be:
-
- - routed by the level 3 functions and thorugh a
- signalling network to its destination; and (This part of the label
- is known as the Routing label. This is shown in Figure 9/Q.700.)
-
- - directed at the receiving User Part to the par-
- ticular circuit, call, management or other transaction to which the
- message is related.
-
- Further details are given in Q.700, S 5.2.
-
-
- Figure 9/Q.700 [T1.700], p. (Traiter comme tableau MEP)
-
-
- There are four types of label:
-
- - type A for MTP management messages;
-
- - type B for TUP;
-
- - type C for ISDN-UP (circuit related) messages;
-
- - type D for SCCP messages.
-
- These are shown in Figure 10/Q.700.
-
- The circuit identification code is used as a label for circuit
- related signalling messages, e.g., TUP or ISDN-UP. The least signi-
- ficant 4 bits of this field (in the TUP) is the Signalling Link
- Selection (SLS) field, which is used, where appropriate, to perform
- load sharing (see Q.704). In the ISDN-UP, the SLS is a separate
- field to the circuit identification code.
-
- The CCITT No. 7 MTP signalling messages at level 2, which
- carry user information, are called Message Signal Units (MSUs).
- Figure 11/Q.700 shows the basic format of the MSU (refer also to
- Q.703) and the breakdown of the MSU. Signalling Information Field
- (SIF) when transporting circuit-related (ISDN-UP, TUP) messages and
-
-
-
-
-
-
-
-
-
- non-circuit-related messages (SCCP, TC based). Further details are
- given on message formats in Recommendations Q.704, Q.713, Q.723,
- Q.763, Q.773.
-
-
-
- Figure 10/Q.700, p.10
-
-
-
- Figura 11/Q.700, p.
-
-
-
-
-
- 5.2 MTP addressing
-
-
- There is a two part addressing mechanism in the MTP, one part
- of the mechanism uses the point code which is incorporated in the
- routing label of every message signal unit, the other part of the
- mechanism makes use of the service indicator and network indicator
- within the service information octet. The point code is used for
- inter-node addressing and the SIO addresses signalling system users
- on an intra-node basis.
-
-
- 5.2.1 Point codes
-
-
- Every signalling point (SP) and signalling transfer point
- (STP), when integrated in an SP, will be allocated its own unique
- point code. This is used by the MTP routing function to direct out-
- going messages towards their destination in the network as indi-
- cated by the inclusion of the appropriate point code in the routing
- label. This point code is known as the destination point code
- (DPC). The routing label also contains the point code of the SP
- originating the message signal unit, therefore, the combination of
- this
-
- originating point code (OPC) and DPC will determine the sig-
- nalling relation (i.e., the network points between which MTP "User"
- information is exchanged). The DPC is used by the receiving SP/STP
- discrimination function to determine whether the message is
- addressed to that SP or requires to be onward routed by means of
- the signal transfer capability of the STP.
-
- The DPC will always be determined and inserted in the routing
- label by the level 4 MTP "User". This will also generally be the
- same for the OPC but it is possible that since the OPC might be
- constant it could be inserted by the MTP.
-
-
- 5.2.2 Service indicator and network indicator
-
-
-
-
-
-
-
-
-
-
-
- The 4 bit service indicator (SI) and 2 bit network indicator
- (NI) are included in the service information octet (SIO) and are
- used within an SP's distribution function to determine the "User"
- the incoming message should be delivered to.
-
- The SI will determine the "User", e.g., TUP, SCCP, ISUP and
- the NI will determine which network is concerned,
- e.g., international or national.
-
- The NI will also in conjunction with the OPC/DPC determine
- whether a national or international signalling relation/routing is
- involved.
-
- The NI, together with the standard 14 bit point code, allows
- for a max 16 | 84 point codes to be allocated in a signalling net-
- work.
-
-
- 5.3 SCCP addressing
-
-
- Addressing within the SCCP of S.S. No. 7 makes use of three
- separate elements:
-
- - DPC
-
- - Global Title (GT)
-
- - Sub-System Number (SSN)
-
- One, two or all of the elements may be present in the Called
- and Calling Party Address, the main options are:
- H.T. [T2.700]
-
- _________________________________________________________________
- GT DPC + SSN {
- When transferring SCCP messages
- }
- _________________________________________________________________
- SSN GT SSN + GT {
- When receiving messages from MTP
- }
- _________________________________________________________________
- {
- DPC
- DPC + (SSN or GT or both)
- GT
- GT + SSn
- } {
- When receiving messages from connectionless or
- connection-orientated control for SCCP Routing.
- }
- _________________________________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Table [T2.700], p.
-
-
-
-
-
-
-
-
-
-
-
- The form of address used will depend on the service, applica-
- tion and underlying network.
-
-
-
- 5.3.1 Global Title (GT)
-
-
- The Global Title (GT) may comprise of dialled digits or
- another form of address that will not be recognized in the
- S.S. No. 7 network, therefore, if the associated message requires
- to be routed over the S.S. No. 7 network, translation is required.
-
- Translation of the GT will result in a DPC being produced and
- possibly also a new SSN and GT. A field is also included in the
- address indicator to identify the format of the global title.
-
-
- 5.3.2 Destination Point Code (DPC)
-
-
- The DPC in an address requires no translation and will merely
- determine if the message is destined for that in SP (incoming mes-
- sage) or requires to be routed over the S.S. No. 7 signalling net-
- work via the MTP. For outgoing messages this DPC should be inserted
- in the MTP routing label. On an incoming message the DPC in the MTP
- routing label should correspond to the DPC in the called address.
-
-
- 5.3.3 Subsystem Number (SSN)
-
-
- The SSN will identify a subsystem accessed via the SCCP within
- a node and may be a User Part, e.g., ISUP, SCCP management or an AE
- via TC. TC, however, will be invisible to the SCCP.
-
- When examination of the DPC in an incoming message has deter-
- mined that the message is for that SP, examination of the SSN will
- identify the concerned SCCP "User". The presence of an SSN without
- a DPC will also indicate a message which is addressed to that SP.
-
- The SSN field has an initial capacity of 255 codes with an
- extension code for future requirements.
-
-
- 5.4 User Part addressing
-
-
-
- 5.4.1 Telephone User Part addressing
-
-
- The Telephone User Part is capable of handling E.164 (incor-
- porating E.163) addresses in the calling and called party address
- information elements.
-
-
-
-
-
-
-
-
-
-
-
- 5.4.2 ISDN User Part addressing
-
-
- The ISDN User Part address structure is capable of handling
- E.164 addresses in the calling and called number, and re-directing
- address information elements.
-
-
- 5.4.3 Signalling connection control part addresses
-
-
- The signalling connection control part is capable of handling
- E.164 (incorporating E.163), X.121, F.69, E.210, E.211, E.212,
- E.213, addresses, and the mobile hybrid E.214 address in the cal-
- ling and called party address information elements.
-
- The handling of OSI NSAP addresses in SCCP is for further
- study.
-
-
- 5.5 Labelling
-
-
- A variety of methods to label signalling messages is used to
- allow the signalling system and users of the signalling system to
- relate a received message to a particular call or transaction.
-
- For circuit-related messages, (e.g., on a simple telephone
- call), the TUP (and the ISUP) use the circuit identification code
- (CIC) to label the message.
-
- For certain ISUP procedures, call reference are used to asso-
- ciate messages with calls.
-
- SCCP also uses local references on connection oriented proto-
- cols.
-
- Transaction capabilities use transaction and invoke identities
- to associate transaction messages and components respectively.
-
-
-
- 6 Operations administration and maintenance
-
-
-
- 6.1 Management
-
-
- Management within S.S. No. 7 is partitioned into two main
- areas:
-
- - Signalling network management;
-
- - Signalling system management.
-
-
-
-
-
-
-
-
-
-
-
- 6.1.1 Signalling network management
-
-
- These are functions contained within the MTP and SCCP which,
- by means of automatic procedures, maintain the required signalling
- network performance (e.g., changeover of faulty links, forced
- re-routing, subsystem availability, etc.).
-
-
- 6.1.2 Signalling system management
-
-
- This may be considered as the actions taken by the operator
- (or by an external automatic mechanism) to maintain the signalling
- system performance when problems are identified.
-
-
- 6.1.3 Signalling System No. 7 and TMN
-
-
- The TMN concept identifies CCITT S.S. No. 7 as a candidate to
- act as a data communications network (DCN) for some TMN functions.
- The protocols that will be needed for this purpose are intended to
- be defined as ASEs, as part of OMAP. This topic is for further
- study.
-
-
- 6.1.4 Signalling System No. 7 and OSI management
-
-
- This subject is for further study.
-
-
- 6.2 Maintenance and testing
-
-
- The maintenance administration and management functions of the
- signalling system themselves use the signalling system as a data
- carrying mechanism. When regarded in the data transport mode, how-
- ever, any management or maintenance information is regarded as sig-
- nalling traffic. Those functions having direct impact on S.S. No. 7
- are included in OMAP Recommendation Q.795.
-
- Testing within Signalling System No. 7 is:
-
- - instigated automatically as a part of a signal-
- ling system management procedures (e.g., signalling route set test
- in MTP) or
-
- - applied as a result of external activity,
- e.g., human-machine (MMI).
-
- The first form is described in the appropriate Q.700 to Q.795
- Recommendation dealing with MTP or SCCP, etc. The second form
- includes some MMI initiated procedures (initiation of MRVT
- (Q.795)), and also pre-in service testing using test cases speci-
- fied in Recommendations for S.S. No. 7 tests (Q.780 to Q.783). A
-
-
-
-
-
-
-
-
-
- testing user part has been agreed to be necessary for pre-in ser-
- vice testing, this topic is for further study.
-
-
- 6.2.1 Operations Maintenance and Administration Part (OMAP)
-
-
- Recommendation Q.795 provides procedures and protocols related
- to operations and maintenance information. These procedures and
- protocols use TCAP and are invoked by the system management appli-
- cation process (SMAP). Recommendation Q.795 includes the following:
-
- - MTP Routing Verification Test (MRVT)
-
- - SCCP Routing Verification Test (SRVT) - for
- further study
-
- - Circuit Validation Test
-
- The protocol for the MRVT contained in Q.795 forms part of the
- OMAP AE which in turn uses the services provided by transaction
- capabilities.
-
- ASEs needed to support the TMN functions are for further
- study.
-
-
-
- 6.2.2 Testing
-
-
- Test specifications for Signalling System No. 7 are contained
- in Recommendations Q.780-783 and cover MTP level 2, level 3 and the
- TUP together with an overview of testing.
-
- A Testing User Part is for further study.
-
-
- 6.3 CCITT S.S. No. 7 measurements
-
-
- Recommendation Q.791 specifies the monitoring and measurements
- appropriate to the MTP and SCCP.
-
-
- 7 Signalling system performance
-
-
- The performance requirements of Signalling System No. 7 must
- take account of the performance requirements of the services that
- are being supported. Each functional component of Signalling
- System No. 7 has its performance criteria specified in a
- self-contained Recommendation. An overall performance target is
- specified in the form of a Hypothetical Signalling Reference Con-
- nection (HSRC).
-
-
-
-
-
-
-
-
-
-
-
- 7.1 Hypothetical Signalling Reference Connection (HSRC)
-
-
- The HSRC for Signalling System No. 7 (Recommendation Q.709),
- identifies components that are used in a signalling relation
- between signalling end points, signalling points, signalling
- transfer points, and signalling points with SCCP relay functions,
- and gives the values for the signalling delays and unavailability
- parameters. The values used are derived from the figures contained
- in the individual performance Recommendations for MTP, TUP, SCCP
- and ISUP.
-
-
- 7.2 MTP
-
-
- The MTP signalling performance requirements are specified in
- Recommendation Q.706. This Recommendation includes:
-
- - the parameters route-set unavailability, MTP mal-
- function (loss of messages and mis-sequencing), and message
- transfer times;
-
- - factors affecting performance, for example sig-
- nalling traffic characteristics (e.g., loading potential,
- security, etc.) and parameters related to transmission characteris-
- tics (e.g., bit rates of signalling data links);
-
- - those parameters which have greatest influence on
- the signalling network queueing delays for example, error control,
- security arrangements, failures and priorities.
-
- It should be noted that management functions affect MTP per-
- formance.
-
-
- 7.3 SCCP
-
-
- The SCCP signalling performance requirements are contained in
- Recommendation Q.716. Parameters identified are signal connection
- delays (establishment, unsolicited reset, reset and release signal-
- ling connection, reset and release failure probability, data mes-
- sage transmit delay, data message delay failure and error probabil-
- ity and SCCP unavailability).
-
- It should be noted that management functions affect SCCP per-
- formance.
-
-
- 7.4 TUP
-
-
- The TUP signalling performance requirements are contained in
- Recommendation Q.725. Parameters contained in this Recommendation
- are cross office performance for TUP supported circuit connection
- control application under normal and abnormal traffic loads. Also
-
-
-
-
-
-
-
-
-
- specified is the probability of failure of calls due to signalling
- malfunction.
-
-
- 7.5 ISDN-UP
-
-
- The ISDN-UP signalling performance requirements are contained
- in Recommendation Q.766. Parameters contained in this Recommenda-
- tion are cross office performance for ISDN-UP supported circuit
- connection control under normal and abnormal traffic loads. Also
- specified is the probability of failure of an ISDN call due to sig-
- nalling function.
-
-
-
- 8 Flow control
-
-
- Signalling System No. 7 in common with other transport mechan-
- isms, needs to limit the input of data when congestion onset is
- detected. Failure to do so can create overload situations. The
- nature of CCITT S.S. No. 7 will lead to SP/STP overload congestion
- being spread through the signalling network if no action is taken.
- This will result in impaired signalling performance. In addition to
- signalling network congestion within a node, congestion will also
- require action to prevent signalling performance from deteriorat-
- ing. There is thus a need for flow control within the signalling
- system to maintain the required signalling performance.
-
-
- 8.1 Signalling network flow control
-
-
- This is achieved by incorporating a flow control mechanism in
- the MTP. On detection of congestion, MTP "Users" are informed by
- the means of a special primitive; the "User" should then reduce
- signalling traffic towards the congested part of the network. If
- the User is at a remote SP, the information is carried across the
- network in an appropriate signalling network management message.
-
-
- 8.2 Signalling node (congestion) flow control
-
-
- In addition to network congestion, nodal congestion also
- requires the remedial action of flow control to prevent the signal-
- ling performance from being impaired. Nodal congestion can occur
- both within the MTP and the MTP "User".
-
-
- 8.2.1 MTP nodal flow control
-
-
- A similar activity to that to combat signalling network
- congestion is required, i.e., on detection, the "User" is informed
- so that traffic can be reduced.
-
-
-
-
-
-
-
-
-
- 8.2.2 "User" flow control
-
-
- As well as taking action to reduce MTP congestion, mechanisms
- are also required within the User to detect the onset of congestion
- and to take appropriate action.
-
-
- 8.3 Automatic congestion control
-
-
- The ISUP and TUP provide signalling procedures which aim to
- reduce the new calls offered to an exchange which is experiencing
- processor overload.
-
- Automatic congestion control provides the means to inform
- adjacent exchanges of the current workload, and to request that
- only priority calls are offered to the exchange experiencing over-
- load.
-
-
- 9 Compatibility mechanisms and rules in CCITT S.S. No. 7
-
-
-
- 9.1 Modularity
-
-
- The wide scope of the signalling system requires that the
- total system include a large diversity of functions and that
- further functions can be added to cater for extended future appli-
- cations. As a consequence only a subset of the total system may
- need to be used in an individual application.
-
- A major characteristic of the signalling system is that it is
- specified with a functional structure to ensure flexibility and
- modularity for diverse applications within one system concept. This
- allows the system to be realized as a number of functional modules
- which could ease adaptation of the functional content of an operat-
- ing Signalling System No. 7 to the requirements of its application.
-
- The CCITT specifications of the signalling system specify
- functions and their use for international operation of the system.
- Many of those functions are also required in typical national
- applications. Furthermore, the system to some extent includes
- features that are particular to national applications. The CCITT
- specifications thus form an internationally standardized base for a
- wide range of national applications of common channel signalling.
-
-
- CCITT S.S. No. 7 is one common channel signalling system. How-
- ever, as a consequence of its modularity and its intended use as a
- standard base for national applications the system may be applied
- in many forms. In general, to define the use of the system in a
- given national application, a selection of the CCITT specified
- functions must be made and the necessary additional national func-
- tions must be specified depending on the nature of the application.
-
-
-
-
-
-
-
-
-
- CCITT S.S. No. 7 is an evolutionary signalling system which
- has undergone a number of enhancements. To allow ease of evolution
- it has been necessary to incorporate a number of compatibility
- mechanisms in various functional elements of CCITT No. 7, and to
- apply a number of compatibility rules to protocol enhancement.
- Detailed specification of the compatibility mechanisms in each
- functional element of CCITT S.S. No. 7 are given in the appropriate
- Q.700 to Q.795 Recommendations. Hence an overview is given in this
- Recommendation.
-
- Compatibility rules which apply to all functional elements of
- CCITT S.S. No. 7 are detailed in the following text.
-
-
- 9.2 Evolutionary requirements
-
-
- In application protocols (e.g., ISDN-UP, ASEs), the main evo-
- lutionary requirement is the ability to add new subscriber ser-
- vices, new administration and network services to the protocol.
-
- In the SCCP and MTP, the evolutionary requirements are dif-
- ferent in that initial versions provide basic transport functions
- which are generally stable. The main enhancements have been in the
- management protocols.
-
- Although the evolutionary requirements are different across
- the elements of CCITT S.S. No. 7, it is possible to incorporate
- certain common mechanisms in the various functional elements.
-
-
- 9.3 Forward and backward compatibility
-
-
- Compatibility mechanisms can be considered as being either:
-
- - Forward compatibility mechanisms
-
- - Backward compatibility rules
-
- Forward compatibility mechanisms are defined as a scheme to
- enable a version of a protocol to communicate effectively and
- interwork with future versions of the protocol.
-
- Backward compatibility rules are defined as a scheme to ensure
- that future versions of the protocol will be able to send protocol
- messages to the previous version which will be understood and fully
- processed by the node supporting the previous version.
-
-
- 9.4 Compatibility rules for CCITT S.S. No. 7
-
-
- The following compatibility rules are applied to each element
- of CCITT S.S. No. 7 (e.g., ISDN-UP) when protocols are enhanced.
-
-
-
-
-
-
-
-
-
-
-
- 9.4.1 Addition of a new value to an existing field (e.g., a
- cause value)
-
-
- New values to an existing field can be added. The processing
- of these new values at nodes supporting an earlier version of the
- protocol will be defined in their version specifications.
-
-
- 9.4.2 Addition of a new parameter to an existing message
-
-
- Any new parameters added to an existing message must not be
- added as mandatory parameters. If a new parameter, must be added,
- and it must be a mandatory parameter, then a new message type must
- be created.
-
-
- 9.4.3 Handling of unrecognized information
-
-
- When a new protocol, message or information element is
- created, a rule is required on a per message and information ele-
- ment basis, to define the action on receipt of unrecognized infor-
- mation. This rule needs to be applied to both unrecognized mes-
- sages, unrecognized information elements within messages, and
- unrecognized values within recognized information elements.
-
-
- The actions defined for receipt of an unrecognized
- message/information element could be:
-
- - Discard message/information element.
-
- - Discard/ignore information element within a
- recognized message.
-
- - Default to a known general value (e.g., on
- receipt of an ISDN-UP IAM with an unrecognized calling party
- category could be defaulted to "Unknown").
-
- - Send a "Confusion" message.
-
- - Terminate the call/transaction.
-
- - Information management.
-
-
- 9.4.4 Increase in the length of optional parameters
-
-
- If a parameter is used as an optional parameter in all mes-
- sages that it appears, the length of the parameter can be
- increased. The older version of the protocol would be able to func-
- tion as it does today, assuming it ignores the extra bits or a
- suitable extension method has been defined. The newer version would
- have to check the length of the parameter to determine if the added
-
-
-
-
-
-
-
-
-
- information was present.
-
- Protocols which use coding rules which are based on X.409
- (e.g., TC) are not subject to this rule.
-
-
- 9.4.5 Processing of messages with unrecognized SIO informa-
- tion
-
-
- To enable signalling points implemented to the Blue Book to
- interwork with signalling points implemented to earlier Recommenda-
- tions when a message containing an unrecognized service information
- octet (see Q.704, S 14.2) is received, the message is discarded.
-
-
- 9.4.6 Unacknowledged messages
-
-
- Where a function requires an acknowledgement to a message in
- order to continue, if no response is received the function sends
- the message for only a limited number of times. The sending signal-
- ling point should assume that the function is not available, and
- inform local management.
-
-
- 9.4.7 Processing of spare fields
-
-
- For those CCITT S.S. No. 7 functions which define fields or
- sub-fields in signalling messages as spare or reserved, the follow-
- ing rules for processing of these fields apply.
-
- At a node generating a signalling message, all spare and
- reserved fields are set to zero. At transit nodes, spare or
- reserved fields may be passed on transparently. At the destination
- node, the spare and reserved fields are not examined.
-
-
- 10 Glossary
-
-
- A Glossary of terms in CCITT S.S. No. 7 is contained at the
- back of the Fascicles VI.7, VI.8 and VI.9.
-
-
- BLANC
-
-
-
-
-
-
-
- SECTION 2
-
- MESSAGE TRANSFER PART (MTP)
-
-
-
-
-
-
-
-
-
-
-
-
- Recommendation Q.701
-
- FUNCTIONAL DESCRIPTION OF THE
-
-
-
- MESSAGE TRANSFER PART (MTP) OF SIGNALLING SYSTEM No. 7
-
-
- 1 Introduction
-
-
-
- 1.1 General
-
-
- The Message Transfer Part (MTP) provides the functions that
- enable User Part significant information passed to the MTP to be
- transferred across the Signalling System No. 7 network to the
- required destination. In addition, functions are included in the
- MTP to enable network and system failures that would affect the
- transfer of signalling information to be overcome. This constitutes
- a sequenced connectionless service for the MTP user.
-
- The Message Transfer Part together with one of its "users",
- the Signalling Connection Control Part (SCCP), described in
- Recommendations Q.711-716, forms the Network Service Part (NSP).
-
- The Network Service Part meets the requirement for Layer 3
- services as defined in the OSI - Reference Model CCITT
- Recommendation X.200. The relationship of the MTP with this model
- and to other parts of S.S. No. 7 is described in
- Recommendation Q.700.
-
-
- 1.2 Objectives
-
-
- The overall objectives of the Message Transfer Part are to
- provide the means for:
-
- a) the reliable transport and delivery of "User
- Part" signalling information across the S.S. No. 7 network.
-
- b) the ability to react to system and network
- failures that will affect a), and take the necessary action to
- ensure that a) is achieved.
-
- The "Users" of MTP are the SCCP, Telephone User Part (TUP)
- [Recommendation Q.721-725 Data User Part (DUP)
- [Recommendation Q.741] and ISDN User Part (ISUP)
- [Recommendation Q.761-766]. The MTP Testing User Part is for
- further study.
-
-
- 1.3 General characteristics
-
-
-
-
-
-
-
-
-
-
- 1.3.1 Method of description
-
-
- - functions provided by each level within the MTP
-
- - services provided by the MTP
-
- - interaction with the signalling network
-
- - interaction with the MTP "User"
-
- - the message transfer capability of the MTP
-
-
- The functions of each level of the MTP are performed by means
- of the level protocol between two systems which provides a "level
- service" to the upper levels, (i.e., Level 1 Signalling Data Link,
- Level 2 Signalling Link and Level 3 Signalling network) as
- described in Recommendations Q.702, 703 and 704 respectively.
-
- The service interface to the Level 4 "User" of MTP is
- described by means of primitives and parameters.
-
-
- 1.3.2 Primitives
-
-
- Primitives consist of commands and their respective responses
- associated with the services requested of the SCCP and of the MTP,
- see Figure 1/Q.701. The general syntax of a primitive is shown
- below:
- H.T. [T1.701]
-
- _______________________________________________
- X Generic name Specific name Parameter
- _______________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
- Table [T1.701], p.
-
-
- - "X" designates the functional block providing the
- service ("MTP" for MTP).
-
- - "Generic name" describes the action that should
- be performed by the addressed layer.
-
- - "Specific name" indicates the direction of the
- primitive flow.
-
- - "Parameters" are the elements of information
- which are to be transmitted between layers.
-
- Four Specific Names exist in general:
-
- - request
-
- - indication
-
-
-
-
-
-
-
-
-
- Not all generic names contain all four specific names
- (Figure 2/Q.701).
- - response
-
- - confirmation
-
-
- Figure 1/Q.701, p.
-
-
-
-
-
- Figure 2/Q.701, p.
-
-
- Primitives and parameters of the Messsage Transfer Part ser-
- vice are listed and described in Section 8 of this Recommendation.
-
-
- 1.3.3 Peer-to-peer communication
-
-
- Exchange of information between two peers of the MTP is per-
- formed by means of a protocol. The protocol is a set of rules and
- formats by which the control information and MTP "User" data is
- exchanged between the two peers. The protocol caters for
-
- - the transfer of "User" data in Message Signal
- Units (MSUs);
-
- - level 2 control by use of Link Status Signal
- Units (LSSUs);
-
- - testing and maintenance of signalling links by
- means of the signalling link test message carried in an MSU.
-
-
- 1.3.4 Contents of Recommendations Q.701 to Q.707 Series
- relating to the MTP
-
-
- Recommendation Q.701 contains a functional description and
- overview of the Message Transfer Part of CCITT S.S. No. 7.
-
- Recommendation Q.702 details the requirements of a signalling
- data link to support CCITT S.S. No. 7.
-
- Recommendation Q.703 describes the signalling link functions.
-
- Recommendation Q.704 describes signalling network functions
- and messages.
-
- Recommendation Q.706 defines and specifies values for MTP per-
- formance parameters.
-
-
-
-
-
-
-
-
-
-
-
- Recommendation Q.707 describes the testing and maintenance
- functions applicable to the MTP.
-
-
- 2 Signalling system structure
-
-
-
- 2.1 Basic functional division
-
-
- The fundamental principle of the signalling system structure
- is the division of functions into a common Message Transfer Part
- (MTP) on one hand and separate User Parts for different users on
- the other. This is illustrated in Figure 3/Q.701.
-
-
-
- Figure 3/Q.701 p.
-
-
- The overall function of the Message Transfer Part is to serve
- as a transport system providing reliable transfer of signalling
- messages between the locations of communicating user functions.
-
- The term user | in this context refers to any functional
- entity that utilizes the transport capability provided by the Mes-
- sage Transfer Part. A User Part comprises those functions of, or
- related to, a particular type of user that are part of the common
- channel signalling system, typically because those functions need
- to be specified in a signalling context.
-
- The basic commonality in signalling for different services
- resulting from this concept is the use of a common transport sys-
- tem, i.e., the Message Transfer Part. Also, a degree of commonality
- exists between certain User Parts, e.g., the Telephone User Part
- (TUP) and the Data User Part (DUP).
-
-
- 2.2 Functional levels
-
-
-
- 2.2.1 General
-
-
- As a further separation, the necessary elements of the signal-
- ling system are specified in accordance with a level concept in
- which:
-
- - the functions of the Message Transfer Part are
- separated into three functional levels, and
-
- - the User Parts constitute parallel elements at
- the fourth functional level.
-
- The level structure is illustrated in Figure 4/Q.701. The
-
-
-
-
-
-
-
-
-
- system structure shown in Figure 4/Q.701 is not a specification of
- an implementation of the system. The functional boundaries B, C
- and D may or may not exist as interfaces in an implementation. The
- interactions by means of controls and indications may be direct or
- via other functions. However, the structure shown in Figure 4/Q.701
- may be regarded as a possible model of an implementation.
-
-
- 2.2.2 Signalling data link functions (level 1)
-
-
- Level 1 defines the physical, electrical and functional
- characteristics of a signalling data link and the means to access
- it. The level 1 element provides a bearer for a signalling link.
-
- In a digital environment, 64-kbit/s digital paths will nor-
- mally be used for the signalling data link. The signalling data
- link may be accessed via a switching function, providing a poten-
- tial for automatic reconfiguration of signalling links. Other types
- of data links, such as analogue links with modems, can also be
- used.
-
- The detailed requirements for signalling data links are speci-
- fied in Recommendation Q.702.
-
-
-
- Figure 4/Q.701, p.17
-
-
-
- 2.2.3 Signalling link functions (level 2)
-
-
- Level 2 defines the functions and procedures for and relating
- to the transfer of signalling messages over one individual signal-
- ling data link. The level 2 functions together with a level 1 sig-
- nalling data link as a bearer provides a signalling link for reli-
- able transfer of signalling messages between two points.
-
- A signalling message delivered by the higher levels is
- transferred over the signalling link in variable length signal
- units . For proper operation of the signalling link, the signal
- unit comprises transfer control information in addition to the
- information content of the signalling message.
-
- The signalling link functions include:
-
- - delimitation of signal unit by means of flags;
-
- - flag imitation prevention by bit stuffing;
-
- - error detection by means of check bits included
- in each signal unit;
-
- - error correction by retransmission and signal
- unit sequence control by means of explicit sequence numbers in each
-
-
-
-
-
-
-
-
-
- signal unit and explicit continuous acknowledgements;
-
- - signalling link failure detection by means of
- signal unit error rate monitoring and signalling link recovery by
- means of special procedures.
-
- The detailed requirements for signalling link functions are
- given in Recommendation Q.703.
-
-
-
- 2.2.4 Signalling network functions (level 3)
-
-
- Level 3 in principle defines those transport functions and
- procedures that are common to and independent of the operation of
- individual signalling links. As illustrated in Figure 4/Q.701 these
- functions fall into two major categories:
-
- a) signalling message handling functions - these
- are functions that, at the actual transfer of a message, direct the
- message to the proper signalling link or User Part;
-
- b) signalling network management functions - these
- are functions that, on the basis of predetermined data and informa-
- tion about the status of the signalling network, control the
- current message routing and configuration of signalling network
- facilities. In the event of changes in the status they also control
- reconfigurations and other actions to preserve or restore the nor-
- mal message transfer capability.
-
- The different level 3 functions interact with each other and
- with the functions of other levels by means of indications and con-
- trols as illustrated in Figure 4/Q.701. This figure also shows that
- the signalling network management as well as the testing and
- maintenance actions may include exchange of signalling messages
- with corresponding functions located at other signalling points.
- Although not User Parts these parts of level 3 can be seen as
- serving as "User Parts of the Message Transfer Part". As a conven-
- tion in these specifications, for each description, general refer-
- ences to User Parts as sources or sinks of a signalling message
- implicitly include these parts of level 3 unless the opposite is
- evident from the context or explicitly stated.
-
- A description of the level 3 functions in the context of a
- signalling network is given in S 3 below. The detailed requirements
- for signalling network functions are given in Recommendation Q.704.
- Some means for testing and maintenance of the signalling network
- are provided and the detailed requirements are given in
- Recommendation Q.707.
-
-
- 2.2.5 User Part functions (level 4)
-
-
- Level 4 consists of the different User Parts. Each User Part
- defines the functions and procedures of the signalling system that
-
-
-
-
-
-
-
-
-
- are particular to a certain type of user of the system.
-
- The extent of the User Part functions may differ significantly
- between different categories of users of the signalling system,
- such as:
-
- - users for which most user communication func-
- tions are defined within the signalling system. Examples are tele-
- phone and data call control functions with their corresponding
- Telephone and Data User Parts;
-
- - users for which most user communication func-
- tions are defined outside the signalling system. An example is the
- use of the signalling system for transfer of information for some
- management or maintenance purpose. For such an "external user" the
- User Part may be seen as a "mailbox" type of interface between the
- external user system and the message transfer function in which,
- for example, the user information transferred is assembled and
- disassembled to/from the applicable signalling message formats.
-
-
- 2.3 Signalling message
-
-
- A signalling message is an assembly of information, defined at
- level 3 or 4, pertaining to a call, management transaction, etc.,
- that is transferred as an entity by the message transfer function.
-
- Each message contains service information | ncluding a ser-
- vice indicator | dentifying the source User Part and possibly
- additional information such as an indication whether the message
- relates to international or national application of the User Part.
-
- The signalling information | f the message includes the
- actual user information, such as one or more telephone or data call
- control signals, management and maintenance information, etc., and
- information identifying the type and format of the message. It also
- includes a label | hat provides information enabling the message:
-
- - to be routed by the level 3 functions and
- through a signalling network to its destination; and
-
- - to be directed at the receiving User Part to the
- particular circuit, call, management or other transaction to which
- the message is related.
-
- On the signalling link, each signalling message is packed into
- Message Signal Units (MSUs) which also includes transfer control
- information related to the level 2 functions of the link.
-
-
-
- 2.4 Functional interface
-
-
- The following functional interface between the Message
- Transfer Part and the User Parts can be seen as a model
-
-
-
-
-
-
-
-
-
- illustrating the division of functions between these parts. The
- interface (see Figure 5/Q.701) is purely functional and need not
- appear as such in an implementation of the system.
-
-
- Figure 5/Q.701, p.
-
-
- The main interaction between the Message Transfer Part and the
- User Parts is the transfer of signalling messages across the inter-
- face, each message consisting of service information and signalling
- information as described above. Message delimitation information is
- also transferred across the interface with the message.
-
- In addition to the transfer of messages and associated infor-
- mation, the interaction may also include flow control information,
- e.g., an indication from the Message Transfer Part that it is
- unable to serve a particular destination.
-
- A description of the characteristics of the Message Transfer
- Part as seen from the functional interface and the requirements to
- be met by potential users of the message transfer function is given
- in S 4.
-
-
- 3 Message transfer part and the signalling network
-
-
-
- 3.1 General
-
-
- Since the Message Transfer Part forms the interface at a node
- with the rest of the signalling network, the signalling network
- will have significant impact on the MTB. The MTP must however be
- independent of the signalling network in that it has to be capable
- of performing its set functions and attaining its objectives no
- matter what network structure or status prevails.
-
- The MTP has therefore to contain the necessary functions to
- ensure any impact that the network has does not impair MTP perfor-
- mance.
-
-
- 3.1.1 Signalling network components
-
-
- A full description of signalling network components is con-
- tained in Recommendation Q.700, the components that must be con-
- sidered by the MTP are:
-
- - signalling points (including signalling transfer
- points);
-
- - signalling relations between two signalling
- points;
-
-
-
-
-
-
-
-
-
-
- - signalling links;
-
- - signalling link sets (including link groups);
-
- - signalling routes;
-
- - signalling route-sets.
-
-
- 3.1.2 Signalling modes
-
-
- Signalling modes are described in Recommendations Q.700 and
- Q.705 (signalling network structures). The modes applicable to
- CCITT S.S. No. 7 MTP are:
-
- - associated mode;
-
- - quasi-associated mode.
-
-
-
- 3.1.3 Signalling point modes
-
-
- A signalling point can be an originating point, a destination
- point or a signalling transfer point in a signalling relation. All
- three modes must be considered in the MTP.
-
-
- 3.1.4 Message labelling
-
-
- Each message contains a label. In the standard label the por-
- tion that is used for routing is called the routing label . This
- routing label includes:
-
- a) explicit indications of destination and ori-
- ginating points of the message, i.e., identification of the signal-
- ling relation concerned;
-
- b) a code used for load sharing which may be the
- least significant part of a label component that identifies a user
- transaction at level 4.
-
- The standard routing label assumes that each signalling point
- in a signalling network is allocated a code according to a code
- plan, established for the purpose of labelling, that is unambiguous
- within its domain. Messages labelled according to international and
- national code plans are discriminated by means of an indication in
- the service information octet included in each message.
-
- The standard routing label is suitable for national applica-
- tions also. However, the signalling system includes the possibility
- for using different routing labels nationally.
-
-
-
-
-
-
-
-
-
-
-
- 3.2 Signalling message handling functions
-
-
- Figure 6/Q.701 illustrates the signalling message handling
- functions.
-
-
- Figure 6/Q.701, p.
-
-
-
-
-
- 3.2.1 Message routing
-
-
- Message routing | is the process of selecting, for each sig-
- nalling message to be sent, the signalling link to be used. In gen-
- eral, message routing is based on analysis of the routing label of
- the message in combination with predetermined routing data at the
- signalling point concerned.
-
- Message routing is destination-code dependent with typically
- an additional load-sharing element allowing different portions of
- the signalling traffic to a particular destination to be distri-
- buted over two or more signalling links. This traffic distribution
- may be limited to different links within a link set or applied to
- links in different link sets.
-
- Each succession of signalling links that may be used to convey
- a message from the originating point to the destination point con-
- stitutes a message route . A signalling route is the corresponding
- concept for a possible path referring to a succession of link sets
- and signalling transfer points, between a given signalling point
- and the destination point.
-
- In Signalling System No. 7, message routing is made in a
- manner by which the message route taken by a message with a partic-
- ular routing label is predetermined and, at a given point in time,
- fixed. Typically, however, in the event of failures in the signal-
- ling network, the routing of messages, previously using the failed
- message route, is modified in a predetermined manner under control
- of the signalling traffic management function at level 3.
-
- Although there are in general advantages in using a uniform
- routing of messages belonging to different User Parts, the service
- indicator included in each message provides the potential for using
- different routing plans for different User Parts.
-
-
- 3.2.2 Message distribution
-
-
- Message distribution | is the process which, upon receipt of
- a message at its destination point, determines to which User Part
- or level 3 function the message is to be delivered. This choice is
- made on analysis of the service indicator.
-
-
-
-
-
-
-
-
-
- 3.2.3 Message discrimination
-
-
- Message discrimination | is the process which, upon receipt
- of a message at a signalling point, determines whether or not the
- point is the destination point of that message. This decision is
- based on analysis of the destination code in the routing label in
- the message. If the signalling point is the destination point the
- message is delivered to the message distribution function. If it is
- not the destination point, and the signalling point has the
- transfer capability, the message is delivered to the routing func-
- tion for further transfer on a signalling link.
-
-
- 3.3 Signalling network management functions
-
-
- Figure 6/Q.701 illustrates the signalling network management
- functions.
-
-
- 3.3.1 Signalling traffic management
-
-
- The tasks of the signalling traffic management | function
- are:
-
- a) to control message routing; this includes modif-
- ication of message routing to preserve, when required, accessibil-
- ity of all destination points concerned or to restore normal rout-
- ing;
-
- b) in conjunction with modifications of message
- routing, to control the resulting transfer of signalling traffic in
- a manner that avoids irregularities in message flow;
-
- c) flow control.
-
- Control of message routing is based on analysis of predeter-
- mined information about all allowed potential routing possibilities
- in combination with information, supplied by the signalling link
- management | nd signalling route management | unctions, about the
- status of the signalling network (i.e., current availability of
- signalling links and routes).
-
- Changes in the status of the signalling network typically
- result in modification of current message routing and thus in
- transfer of certain portions of the signalling traffic from one
- signalling link to another. The transfer of signalling traffic is
- performed in accordance with specific procedures. These procedures
- - changeover, changeback, forced rerouting and controlled rerouting
- - are designed to avoid, as far as the circumstances permit, such
- irregularities in message transfer as loss, mis-sequencing or mul-
- tiple delivery of messages.
-
-
- The changeover and changeback procedures involve communication
-
-
-
-
-
-
-
-
-
- with other signalling point(s). For example, in the case of change-
- over from a failing signalling link, the two ends of the failing
- link exchange information (via an alternative path) that normally
- enables retrieval of messages that otherwise would have been lost
- on the failing link. However, as further explained later, these
- procedures cannot guarantee regular message transfer in all cir-
- cumstances.
-
- A signalling network has to have a signalling traffic capacity
- that is higher than the normal traffic offered. However, in over-
- load conditions (e.g., due to network failures or extremely high
- traffic peaks) the signalling traffic management function takes
- flow control actions to minimize the problem. An example is the
- provision of an indication to the local user functions concerned
- that the Message Transfer Part is unable to transport messages to a
- particular destination in the case of total breakdown of all sig-
- nalling routes to that destination point. If such a situation
- occurs at a signalling transfer point, a corresponding indication
- is given to the signalling route management function for further
- dissemination to other signalling points in the signalling network.
-
-
- 3.3.2 Signalling link management
-
-
- The task of the signalling link management function is to con-
- trol the locally connected link sets. In the event of changes in
- the availability of a local link set it initiates and controls
- actions aimed at restoring the normal availability of that link
- set.
-
- The signalling link management function also supplies informa-
- tion about the availability of local links and link sets to the
- signalling traffic management function.
-
- The signalling link management function interacts with the
- signalling link function at level 2 by receipt of indications of
- the status of signalling links. It also initiates actions at
- level 2 such as, for example, initial alignment of an
- out-of-service link.
-
- The signalling system can be applied with different degrees of
- flexibility in the method of provision of signalling links. A sig-
- nalling link may for example consist of a permanent combination of
- a signalling terminal device and a signalling data link. It is also
- possible to employ an arrangement in which any switched connection
- to the remote end may be used in combination with any local signal-
- ling terminal device. It is the task of the signalling link manage-
- ment function in such arrangements to initiate and control reconfi-
- gurations of terminal devices and signalling data links to the
- extent such reconfigurations are automatic. In particular, this
- involves interaction, not necessarily direct, with a switching
- function at level 1.
-
-
- 3.3.3 Signalling route management
-
-
-
-
-
-
-
-
-
-
- Signalling route management is a function that relates to the
- quasi-associated mode of signalling only. Its task is to transfer
- information about changes in the availability of signalling routes
- in the signalling network to enable remote signalling points to
- take appropriate signalling traffic management actions. Thus a sig-
- nalling transfer point may, for example, send messages indicating
- inaccessibility of a particular signalling point via that signal-
- ling transfer point, thus enabling other signalling points to stop
- routing messages to an incomplete route.
-
-
- 3.4 Testing and maintenance functions
-
-
- Figure 6/Q.701 illustrates that the signalling system includes
- some standard testing and maintenance functions that use level 3
- messages. Furthermore, any implementation of the system typically
- includes various implementation-dependent means for testing and
- maintenance of equipment concerned with the other levels.
-
-
- 3.5 Use of the signalling network
-
-
-
- 3.5.1 Signalling network structure
-
-
- The signalling system may be used with different types of sig-
- nalling network structures. The choice between different types of
- signalling network structures may be influenced by factors such as
- the structure of the telecommunication network to be served by the
- signalling system and administrative aspects.
-
- In the case when the provision of the signalling system is
- planned purely on a per-signalling relation basis, the likely
- result is a signalling network largely based on associated signal-
- ling, typically supplemented by a limited degree of
- quasi-associated signalling for low volume signalling relations.
- The structure of such a signalling network is mainly determined by
- the patterns of the signalling relations. International signalling
- is an example of an application for which this approach is suit-
- able.
-
-
- Another approach is to consider the signalling network as a
- common resource that should be planned according to the total needs
- for common channel signalling. The high capacity of digital signal-
- ling links in combination with the need for redundancy for relia-
- bility, typically leads to a signalling network based on a high
- degree of quasi-associated signalling with some provision for asso-
- ciated signalling for high-volume signalling relations. The latter
- approach to signalling network planning is more likely to allow
- exploitation of the potential of common channel signalling to sup-
- port network features that require communication for purposes other
- than the switching of connections.
-
-
-
-
-
-
-
-
-
-
- Further considerations about the use of a signalling network
- are given in Recommendation Q.705.
-
-
- 3.5.2 Provision of signalling facilities
-
-
- In general, the most important factor in the dimensioning of
- the signalling network is the need for reliability by means of
- redundancy. Depending on the signalling network structure and the
- potential for reconfiguration of signalling equipment, the required
- redundancy may be provided by different combinations of:
-
- - redundancy in signalling data links
- (e.g., nominated reserves or switched connections);
-
- - redundancy in signalling terminal devices
- (e.g., a common pool of terminals for the whole signalling point);
-
- - redundancy of signalling links within a link set
- (typically operating with load sharing);
-
- - redundancy in signalling routes for each desti-
- nation (possibly operating with load sharing).
-
- The loading capacity of a digital signalling link is high in
- relation to the signalling traffic generated for call control sig-
- nalling. Therefore, in many typical applications the links will be
- lightly loaded and signalling traffic volume will be a secondary
- factor in the dimensioning of the signalling network. However, in
- high signalling traffic applications or when analogue links with
- lower speeds are used, it may be necessary to dimension the traffic
- capacity by provision of additional signalling links. The message
- routing principles adopted for the signalling system allow parti-
- tioning of the total signalling traffic into different portions
- based on load sharing, destination point code and service informa-
- tion. Such partitioning provides a useful means of controlling the
- load and dimensioning of the capacity of different sections of a
- signalling network as it allows distribution of different portions
- of the signalling traffic. It can also be used to dedicate certain
- parts of a signalling network to signalling traffic related to a
- particular user.
-
-
- 3.5.3 Application of signalling network functions
-
-
- The signalling network functions provided by the signalling
- system are designed to cater for a range of signalling network con-
- figurations. It is
-
- not necessary that all of those functions be present at all
- signalling points. The necessary functional content at level 3 at a
- particular signalling point depends for example on what signalling
- mode(s) are used, whether or not it is a signalling transfer point,
- what type of signalling equipment redundancy is employed, etc. It
- is thus feasible to implement level 3 functions with modularity for
-
-
-
-
-
-
-
-
-
- different capabilities corresponding to different signalling net-
- work configurations. As a special case, it is even possible to
- apply the signalling system without using the level 3 element at
- all, e.g., in a small exchange or private automatic branch exchange
- which can only be reached via one primary pulse code modulation
- system.
-
-
- 4 Message transfer capability
-
-
-
- 4.1 General
-
-
- The Message Transfer Part recommendations specify methods by
- which different forms of signalling networks can be established.
- The requirements for the Message Transfer Part have been determined
- primarily by the requirements of call control signalling for the
- telephone and circuit switched data transmission services. However,
- the Message Transfer Part is also intended to have the ability to
- serve as a transport system for other types of information
- transfer. The following summarises the typical characteristics of
- the transport service that may be offered by the Message Transfer
- Part to a potential user of this ability.
-
-
- All information to be transferred by the Message Transfer Part
- must be assembled into messages. The linking of the source and sink
- of a message is inherent in the label in combination with the sig-
- nalling routes existing between the two locations. From a transpor-
- tation point of view each message is self-contained and handled
- individually. The nature of the transport service offered by the
- Message Transfer Part is therefore similar to that offered by a
- packet switched network. In addition, all messages containing the
- same label constitute a set of messages that is handled in a uni-
- form manner by the Message Transfer Part, thus ensuring, in normal
- circumstances, regular delivery in the correct sequence.
-
-
- 4.2 User location in system structure
-
-
- A potential user of the transport service is typically
- included in the system structure by provision of a separate User
- Part. This requires allocation of a service indicator code, the
- specification of which is part of both the Message Transport Part
- and User Part concerned.
-
- As an alternative, a potential user may be catered for,
- together with other similar users, by an already existing or new
- User Part. In such a case the discrimination between messages
- belonging to this potential user and the other similar users is an
- internal matter within the User Part concerned. It then follows
- that all messages belonging to such a User Part are necessarily
- handled, e.g., as regards routing, in a uniform manner by the Mes-
- sage Transfer Part.
-
-
-
-
-
-
-
-
-
- 4.3 Message content
-
-
-
- 4.3.1 Code transparency
-
-
- Information with any code combination generated by a user can
- be transferred by the Message Transfer Part provided that the mes-
- sage respects the requirements described below.
-
-
- 4.3.2 Service information
-
-
- Each message must contain service information coded in accor-
- dance with the rules specified in Recommendation Q.704, S 14.
-
-
- 4.3.3 Message label
-
-
- Each message must contain a label consistent with the routing
- label of the signalling network concerned. See also
- Recommendation Q.704, S 2.
-
-
- 4.3.4 Message length
-
-
- The information content of a message should be an integral
- number of octets.
-
- The total amount of signalling information transferable in one
- message is limited by some parameters of the signalling system; the
- signalling system can accept transfer of user information blocks in
- the order of 256 octets in single messages.
-
- Depending on the signalling traffic characteristics of a user
- and of other users sharing the same signalling facilities, there
- may be a need to limit message lengths below the system limit based
- on queueing delay considerations.
-
- In the case when information blocks generated by a user func-
- tion exceed the allowed message length, it is necessary to imple-
- ment means for segmentation and blocking of such information blocks
- within the User Part concerned.
-
-
- 4.4 User accessibility
-
-
- The accessibility of user functions through a signalling net-
- work depends on the signalling modes and routing plan employed in
- that network.
-
- In the case when only the associated mode of signalling is
-
-
-
-
-
-
-
-
-
- employed, only user functions located at adjacent signalling points
- may be accessed.
-
- In the case when quasi-associated signalling is employed, user
- functions located at any signalling point may be accessed provided
- that the corresponding message routing data is present.
-
-
-
- 4.5 Transport service performance
-
-
- Further detailed information is provided in
- Recommendation Q.706.
-
-
- 4.5.1 Message transfer delay
-
-
- The normal delay for transfer of messages between user loca-
- tions depends on factors such as distance, signalling network
- structure, signalling data link type and bit rate and processing
- delays.
-
- A small proportion of messages will be subject to additional
- delay because of transmission disturbances, network failures, etc.
-
-
- 4.5.2 Message transfer failures
-
-
- The Message Transfer Part has been designed to enable it to
- transfer messages in a reliable and regular manner even in the
- presence of network failures. However, inevitably some failures
- will occur the consequences of which cannot be avoided with
- economic measures. The types of failures
-
- that may occur and some typical probabilities of their
- occurrence are described below. Recommendation Q.706 provides
- further detailed information that can be used to estimate failure
- rates for particular cases.
-
- In the case when a potential user function requires a relia-
- bility of the transport service that cannot be guaranteed by the
- Message Transfer Part, the reliability of that user may be enhanced
- by adoption of appropriate level 4 procedures, possibly including
- some means of supplementary end-to-end error control.
-
- The following types of message transfer failures are possible,
- and the expected probabilities for such failures in typical appli-
- cations are indicated (see also Recommendation Q.706).
-
- a) Unavailability of the transport service to one
- or more locations - the availability of the message transfer capa-
- bility depends on the redundancy provided in the signalling net-
- work; the availability can therefore be dimensioned.
-
-
-
-
-
-
-
-
-
-
- b) Loss of messages - the probability of loss of
- messages mainly depends on the reliability of signalling equipment;
- typically it is expected to be lower than 10DlF2617.
-
- c) Mis-sequencing of messages - may in certain
- configurations of quasi-associated signalling occur with rare com-
- binations of independent failures and disturbances. The probabil-
- ity, in such configurations, of a message being delivered
- out-of-sequence depends on many factors but is expected to be lower
- than 10DlF26110.
-
- d) Delivery of false information - undetected
- errors may lead to the delivery of false information; the possibil-
- ity of an error in a message delivered is expected to be lower than
- 10DlF26110.
-
-
- 5 Differences from the Red Book
-
-
- The ongoing development of the MTP during this study period
- has resulted in a number of differences occurring between the
- Recommendations as documented in the Red Book and these current
- Recommendations (Blue Book). In order to limit interworking prob-
- lems, a backwards compatibility mechanism is required (see S 6). As
- an initial step towards producing such a mechanism, this section
- identifies the new items and items changed because of operational
- considerations, that have been included in the Blue Book. This sec-
- tion does not consider editorial or technical corrections.
-
-
- 5.1 Signalling Information Field length
-
-
- The maximun length of the Signalling Information Field has
- been increased to 272 octets. This was previously a National only
- option. Networks using both signalling terminals with 62 octet max-
- imum SIF length handling capability and signalling terminals with
- 272 octet maximum SIF length handling capability must ensure that
- messages with SIFs longer than 62 octets cannot be routed to sig-
- nalling links that are unable to handle them (see S 7).
-
-
- 5.2 Signalling Point Restart
-
-
- The Signalling Point Restart procedure (see Q.704 S 9) has
- been included together with a definition of Signalling Point avai-
- lability. This procedure allows a graceful increase in message
- traffic at a restarting Signalling Point.
-
-
-
- 5.3 Management Blocking
-
-
- The Management Blocking procedure for Signalling links has
-
-
-
-
-
-
-
-
-
- been deleted. No interworking problems are foreseen in networks
- where some Signalling Points still incorporate this procedure and
- others are implemented in accordance with the Blue Book.
-
-
- 5.4 Signalling Link Test
-
-
- The Signalling Link Test has been enhanced to check that both
- ends of the link agree as to which signalling link is being tested.
- No interworking problems are foreseen (see Q.707 S 2.2).
-
-
- 5.5 Compatibility mechanism
-
-
- General principles have been incorporated in the Message
- Transfer Part that will allow implementations to the Blue Book to
- be compatible with implementations to Red/Yellow Books and future
- issues of the Recommendations (see S 6).
-
-
- 5.6 Timer values
-
-
- The values of existing Q.703 and Q.704 Timers have been final-
- ized (see S 7).
-
-
- 5.7 Processor Outage
-
-
- The actions related to Processor Outage have been clarified
- (see Q.703 S 8 and Q.704 S 4, 5 and 6). No interworking problems
- are foreseen.
-
-
- 5.8 User flow control
-
-
- Procedures for Message Transfer Part User Flow Control have
- been adopted for use at a Signalling Point when an MTP user has
- become unavailable (see Q.704 S 11 and Q.701 S 7).
-
-
- 5.9 Management Inhibiting and Management Inhibiting test
- procedure
-
-
- The time-controlled changeover procedure is now used to divert
- traffic from a management inhibited link.
-
- To verify the inhibited status of a link, test procedures have
- been introduced into management inhibiting (see Q.704 S 10
- and Q.701 S 7).
-
-
-
-
-
-
-
-
-
-
-
- 5.10 Signalling point/signalling transfer point congestion
-
-
- Procedures to detect and handle signalling point/signalling
- transfer point congestion have now been identified (see
- Q.704 S 11.2.6). No interworking problems are foreseen.
-
-
- 6 Compatibility in the message transfer part
-
-
- To enable implementations of Signalling System No. 7 to this
- issue (Blue Book) of the Recommendations to achieve compatibility
- with implementations to other issues, e.g., Yellow, Red and
- 1992 Books, a set of appropriate procedures and guidelines has been
- concluded in Recommendation Q.700. This section identifies the
- action that is required within the Message Transfer Part to ensure
- both forward and backwards compatibility. The areas considered are
- the treatment of spare fields, spare values, lack of acknowledge-
- ments and unreasonable information.
-
-
- 6.1 Unreasonable Information
-
-
- The following actions occur in the MTP when messages are
- received containing unreasonable information.
-
-
-
- 6.1.1 Messages containing an unallocated SIO value
-
-
- When messages containing an unallocated SIO value are received
- at either a terminating Signalling Point or an STP that employs
- message routing based on both DPC and SIO, they should be dis-
- carded. If required, a report should be made to management.
-
-
- 6.1.2 Messages containing an unallocated H0/H1 code
-
-
- When messages containing an unallocated H0/H1 code are
- received at the appropriate functional block within the MTP, they
- are discarded. There should be no impact on any protocol and, if
- required, a report should be made to management.
-
-
- 6.1.3 Messages containing an unallocated value in a recog-
- nized field
-
-
- When massages are received at an owning function within the
- MTP containing a field with an unallocated value they are discarded
- and, if required, a report made to management. There should be no
- impact on any current protocol.
-
-
-
-
-
-
-
-
-
-
- (An owning function is a function to which a received message
- pertains.)
-
-
- 6.2 Treatment of spare fields
-
-
- The MTP will handle spare fields in MTP messages in the fol-
- lowing manner:
-
- i) Spare fields are set to zero on message crea-
- tion, and are not examined on reception at the destination owning
- function.
-
- ii) Spare subfields are set to zero on message
- creation, and are not examined on reception at the destination own-
- ing function.
-
- iii) Implementations of the STP function should
- transit all messages unchanged, including spare fields and spare
- subfields.
-
-
- 6.3 Lack of acknowledgement
-
-
- Should a message that requires an acknowledgement not receive
- one within a specified time, the message will be repeated, unless
- the protocol specifies otherwise. However, subsequent failures to
- receive the acknowledgement should not cause indefinite repeat
- attempts.
-
-
- 7 Interworking of Yellow, Red and Blue MTP implementations
-
-
- There have been a number of changes introduced into this issue
- (Blue Book) of Recommendations Q.701-707 from the previous issue
- (Red Book). The changes have been identified in S 5 and although in
- the majority of cases there will be no interworking problems
- between a Signalling Point/STP implemented to the Red Book and one
- implemented to a Blue Book, there are some instances where problems
- will arise. This section gives guidance on the appropriate action
- that can be taken in the MTP to overcome interworking problems and
- also considers Yellow to Red Book and Yellow to Blue Book inter-
- working.
-
-
- 7.1 Yellow Book to Red Book interworking
-
-
- There were four areas where changes from the Yellow Book to
- the Red Book introduced interworking problems:
-
- i) Level 2 flow control, LSSU SIB introduced.
-
- ii) Transfer Restricted (TRF) and Transfer
-
-
-
-
-
-
-
-
-
- Controlled (TFC) messages and procedures were introduced into the
- Red Book.
-
- iii) Transfer Allowed (TAA) and Transfer Prohibited
- (TPA) acknowledgements were deleted from the Red Book.
-
- iv) Management inhibiting procedures were intro-
- duced into the Red Book.
-
- The suggested action required at the Yellow and/or Red Book
- SP/STP to enable interworking is contained in the following point
- items.
-
-
-
- 7.1.1 Level 2 Flow control
-
-
- The Red Book SP/STP should apply normal level 2 flow control
- action (i.e., acknowledgements are withheld and SIBs sent). The
- Yellow Book SP/STP should ignore the LSSU SIB when received. It is
- recognized that although flow control is not performed in this
- case, interworking is possible. However, a possible option would be
- to set the congestion threshold at the Red Book SP/STP, such that
- flow control is not triggered on that signalling relation.
-
-
- 7.1.2 Transfer restricted and Transfer controlled pro-
- cedures
-
-
- The Yellow Book SP/STP should ignore TFR and TFC messages when
- received.
-
-
- 7.1.3 Transfer allowed/Transfer prohibited acknowledgements
-
-
- The Yellow Book SP/STP should limit the repetition of the
- TFA/TFP message to once only. The Red Book SP/STP should ignore the
- acknowledgement messages when they are received.
-
-
- 7.1.4 Management inhibiting procedure
-
-
- The Yellow Book SP/STP should ignore the Link Inhibit (LIN)
- and Link Uninhibit (LUN) messages when received. The Red Book
- SP/STP should limit the repetition of the LIN/LUN message.
-
-
- 7.2 Red Book to Blue Book interworking
-
-
- The changes in this issue (Blue Book) from the Red Book
- Q.701-707 Recommendations are identified in S 5. There are five
- areas where changes have resulted in interworking problems:
-
-
-
-
-
-
-
-
-
- i) Signalling Point Restart procedure has intro-
- duced the Traffic Restart Allowed (TRA) message.
-
- ii) Timer values have been confirmed in this issue,
- previous values were provisional.
-
- iii) User Flow Control procedure has introduced
- the User Part Unavailable (UPU) message.
-
- iv) Signalling Information Field length increase
- will require action to prevent overlength messages being sent on a
- link that is not capable of handling them.
-
- v) Management-inhibiting test procedure has intro-
- duced Link Local inhibit test message (LLT) and Link Remote inhibit
- test message (LRT).
-
- The suggested actions required at the Red and/or Blue Book
- SP/STP to enable interworking are contained in the following point
- items.
-
-
- 7.2.1 Signalling Point Restart
-
-
- The Red Book SP/STP should ignore the Traffic Restart Allowed
- messages when received.
-
-
- 7.2.2 Q.703 and Q.704 timer values
-
-
- Where possible, an SP/STP implemented to the Red Book should
- adopt the timer values specified in the Blue Book when interworking
- with a Blue Book SP/STP. For timer values (see Q.703 S 12
- and Q.704 S 16).
-
-
- 7.2.3 User flow control
-
-
- The Red Book SP/STP should ignore the User Part Unavailable
- (UPU) message if received.
-
-
- 7.2.4 Management inhibit test procedure
-
-
- The Red Book SP/STP should ignore the Link Local inhibit test
- (LLT) and Link Remote inhibit test (LRT) messages. A report to
- local management should also be made.
-
-
-
- 7.2.5 SIF length increase
-
-
-
-
-
-
-
-
-
-
-
- The SP/STP with 272 octet SIF length handling capability
- should prevent overlength messages from being routed over signal-
- ling links that only have a 62 octet SIF handling capability.
-
-
- 7.2.6 SIF length increase (National networks option)
-
-
- In the international Signalling System No. 7 network, it
- should be possible to identify signalling links/routes with a lim-
- ited SIF length handling capability and prevent overlength messages
- being transmitted over them by administrative action based on the
- exchange of operational data. However, with some national networks
- due to the rapid change in status of SP/STP
-
- implementation level (e.g., 62 to 272 SIF capability) and the
- number of SP/STPs in the network, this administrative action and
- data exchange may not be adequate. In this situation, a mechanism
- based on the following MTP activities may be more appropriate.
-
- i) Detection of a link with 272 SIF capability may
- be achieved by coding the "D" bit of LSSUs sent during alignment
- as 1 (with 62 octet SIF links it would be 0). On receipt of this
- LSSU, a Blue Book SP/STP would mark the link/route as having
- 272 SIF capability. A Red Book SP/STP would ignore the coding of
- the "D" bit and treat the LSSU in the normal manner.
-
- ii) When a Blue Book SP/STP receives a message for
- onward routing, it will check if the message (SIF) is greater than
- 62 octets. If the SIF is greater than 62 octets, it will verify
- that the link/route can handle a message of this length. Should the
- link/route not have the SIF length capability, the message will be
- discarded and an indication sent to the message origin. A Red Book
- SP/STP should not receive a message with an SIF > 62 octets.
-
- iii) If the message originator is a local MTP User,
- an MTP PAUSE primitive will be returned by the MTP in response to
- an overlength message (see S 8). Should the originator be at a
- remote SP, a TFA coded to indicate that only 62 octet SIF messages
- can be transferred will be returned by the MTP in response to an
- overlength message (see Q.704 S 15).
-
- In national networks using an SIF compatibility mechanism, the
- two spare bits in the TFA (see Q.704 S 15.8.2) may be coded as an
- SIF compatibility indicator as follows:
-
- bit B A
-
- 0 0 Allow 62 octet SIFs/Prohibit 272, X and Y octet
- SIFs
-
- 0 1 Allow 62 and 272 octet SIFs/Prohibit X and
- Y octet SIFs
-
- 1 0 Allow 62, 272 and X octet SIFs Prohibit Y octet
- SIFs.
-
-
-
-
-
-
-
-
-
-
- 1 1 Allow 62, 272, X and Y octet SIFs.
-
- Note - 272 < X < Y octets, the values of X and Y are for
- further study.
-
-
- 7.3 Yellow Book to Blue Book Interworking
-
-
- The changes between Yellow and Blue Books have taken place in
- two stages: Yellow to Red and Red to Blue. Therefore, to achieve
- interworking between Yellow and Blue Book implementations, the
- actions specified in SS 7.1 and 7.2 should be applied. In S 7.1 Red
- Book SP/STP should be read as Blue Book SP/STP and in S 7.2 Red
- Book SP/STP should be read as Yellow Book SP/STP.
-
- There is one change from the Red Book in the Blue Book that
- will have an additional impact on interworking with the Yellow
- Book, and that is the deletion of the blocking procedure. This
- means that while a Yellow Book implementation can block a signal-
- ling link, a Blue Book node can neither inhibit nor block the link
- in the opposite direction.
-
-
-
- 8 Primitives and Parameters of the Message Transfer Part
-
-
- The primitives and parameters are shown in Table 1/Q.701.
- H.T. [T2.701]
- TABLE 1/Q.701
- Message transfer part service primitives
-
- ____________________________________________________________________
- Primitives
- Generic Name Specific Name Parameters
- ____________________________________________________________________
- MTP-TRANSFER Request Indication {
- OPC (see Q.704 S 2.2)
- DPC (see Q.704 S 2.2)
- SLS (see Q.704 S 2.2) (Note 1)
- SIO (see Q.704 S 14.2)
- User data (see Q.703 S 2.3.8)
- }
- ____________________________________________________________________
- MTP-PAUSE (Stop) Indication Affected DPC
- ____________________________________________________________________
- MTP-RESUME (Start) Indication Affected DPC
- ____________________________________________________________________
- MTP-STATUS Indication
- Affected DPC Cause (Note 2)
- ____________________________________________________________________
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
- |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Note 1 - The MTP users should take into account that this parame-
- ter is used for load sharing by the MTP, therefore, the SLS values
-
-
-
-
-
-
-
-
-
- should be distributed as equally as possible. The MTP guarantees
- (to a high degree of probability) an in-sequence delivery of mes-
- sages which contain the same SLS code.
-
- Note 2 - The Cause parameter has, at present, two values:
-
- i) Signalling network congested (level)
-
- This parameter value is included if national options with conges-
- tion priorities and multiple signalling link states without conges-
- tion priorities as in Recommendation Q.704 are implemented.
-
- ii) Remote User unavailable.
- Table 1/Q.701 [T2.701], p.
-
-
-
- 8.1 Transfer
-
-
- The primitive "MTP-TRANSFER" is used between level 4 and level
- 3 (SMH) to provide the MTP message transfer service.
-
-
- 8.2 Pause
-
-
- The primitive "MTP-PAUSE" indicates to the "Users" the total
- inability of providing the MTP service to the specified destina-
- tion.
-
-
- 8.3 Resume
-
-
- The primitive "MTP-RESUME" indicates to the "User" the total
- ability of providing the MTP service to the specified destination.
-
- This primitive corresponds to the destination accessible state
- as defined in Recommendations Q.704.
-
-
-
- 8.4 Status
-
-
- The primitive "MTP-STATUS" indicates to the "Users" the par-
- tial inability of providing the MTP service specified destination.
- The primitive is also used to indicate to a User that a remote
- corresponding User is unavailable (see Q.704 S 11.2.7).
-
- In the case of national option with congestion priorities or
- multiple signalling link congestion states without priorities as in
- Recommendation Q.704 are implemented, this "MTP-STATUS" primitive
- is also used to indicate a change of congestion level.
-
- This primitive corresponds to the destination congested/User
-
-
-
-
-
-
-
-
-
- Part unavailable state as defined in Recommendation Q.704.
-
-
- 8.5 Restart
-
-
- The MTP indicates to the "Users" at the restarting SP that the
- MTP is commencing or ending the signalling point restart procedure
- (see Recommendation Q.704, S 9).
-
- The indication may have the following qualifiers:
-
- i) Begin
-
- ii) End
-
- The qualifier "Begin" indicates to the "Users" that all desti-
- nations should be marked as accessible (but that the resumption of
- signalling traffic must await the reception of MTP-RESUME primitive
- or MTP restart indication "End").
-
- The qualifier "End" indicates to the "Users" that signalling
- traffic may be restarted, taking into account any MTP-PAUSE primi-
- tives previously received.
-
- The means of conveying the MTP restart indication to the MTP
- "Users", is for further study.
-
-
- Recommendation Q.702
-
-
- SIGNALLING DATA LINK
-
-
-
-
- 1 General
-
-
- 1.1 A signalling data link | is a bidirectional transmission
- path for signalling, comprising two data channels operating
- together in opposite directions at the same data rate. It consti-
- tutes the lowest functional level (level 1) in the Signalling Sys-
- tem No. 7 functional hierarchy.
-
-
- 1.2 Functional configuration of a signalling data link is
- shown in Figure 1/Q.702.
-
- The terms transmission channel | and transmission link | are
- used in Signalling System No. 7 instead of transfer channel and
- transfer link used in Signalling System No. 6.
- 1.3 A digital signalling data link is made up of digital transmis-
- sion channels and digital switches or their terminating equipment
- providing an interface to signalling terminals. The digital
-
-
-
-
-
-
-
-
-
-
- transmission channels may be derived from a digital multiplex sig-
- nal at 1544, 2048 or 8448 kbit/s having a frame structure as
- defined in Recommendation G.704 [1], or from digital multiplex
- streams having a frame structure specified for data circuits
- (Recommendations X.50 [4], X.51 [5], X.50 | fIbis [6], X.51 |
- fIbis [7]).
-
- 1.4 An analogue signalling data link is made up of
- voice-frequency analogue transmission channels either 4 kHz or
- 3 kHz spaced, and modems.
-
- 1.5 Signalling System No. 7 is capable of operating over both
- terrestrial and satellite transmission links .
-
-
-
- Figure 1/Q.702, p.21
-
-
- 1.6 The operational signalling data link shall be exclusively
- dedicated to the use of a Signalling System No. 7 signalling link
- between two signalling points. No other information should be car-
- ried by the same channel together with the signalling information.
-
- 1.7 Equipment such as echo suppressors, digital pads, or A/u
- law convertors attached to the transmission link must be disabled
- in order to assure full duplex operation and bit integrity of the
- transmitted data stream.
-
- 1.8 64-kbit/s digital signalling channels entering a digital
- exchange via a multiplex structure shall be switchable as
- semi-permanent channels in the exchange.
-
-
- 2 Signalling bit rate
-
-
-
- 2.1 General
-
-
- 2.1.1 The standard bit rate on a digital bearer will be 64
- kbit/s.
-
-
- 2.1.2 Lower bit rates may be adopted for each application,
- taking into account the User Part requirements and the capability
- of available transmission links.
-
- 2.1.3 The minimum signalling bit rate for telephone call con-
- trol applications will be 4.8 kbit/s. For other applications such
- as network management, bit rates lower than 4.8 kbit/s can also be
- used.
-
-
- 2.2 Use of bit rates lower than 64 kbit/s
-
-
-
-
-
-
-
-
-
-
- 2.2.1 For national telephone call control applications, use of
- Signalling System No. 7 at bit rates lower than 64 kbit/s shall
- take account of the requirement to minimize the answer signal delay
- when in-band line signalling systems are involved
- (Recommendation Q.27 [8]).
-
-
- 2.2.2 Signalling System No. 7 can be used for direct interna-
- tional application at bit rates lower than 64 kbit/s between coun-
- tries which have no in-band line signalling systems in their
- national extension networks (see S 2.1.3).
-
- 2.2.3 The possible use of Signalling System No. 7 at bit rates
- lower than 64 kbit/s between countries which have in-band line sig-
- nalling systems in their national extension networks is for further
- study.
-
-
- 3 Error characteristics and availability
-
-
- Error characteristics and availability requirements will con-
- form to relevant Recommendations (for example,
- Recommendation G.821 [9] on digital circuits). No additional
- characteristics or requirements will be specified in this Recommen-
- dation.
-
-
- 4 Interface specification points
-
-
- 4.1 Interface requirements may be specified at one of three
- points, A, B or C in Figure 2/Q.702. The appropriate point depends
- on the nature of transmission links used and the approach toward
- the implementation of interface equipment adopted by each Adminis-
- tration.
-
-
- 4.2 For the international application, interface requirements
- at either Point B or Point C will apply.
-
- 4.3 Interface requirements for an international digital sig-
- nalling data link will be specified at Point C in accordance with
- the specific multiplex structure used (see S 5.)
-
- 4.4 Interface requirements for an international analogue sig-
- nalling data link will be specified at Point B on a single channel
- basis, and thus are independent of multiplex equipment used. (See
- S 6.)
-
- 4.5 Interface at Point A may or may not appear in particular
- implementations, as each Administration may adopt different
- approaches towards the implementation of interface equipment. If it
- does appear in implementations, then the interface requirements
- specified in Recommendations V.10 [10], V.11 [11], V.24 [12],
- V.28 [13], V.35 [14], V.36 [15], X.24 [16] and G.703 [17] (for
- 64-kbit/s interface) should be followed as appropriate.
-
-
-
-
-
-
-
-
-
- 4.6 Implementations which do not follow all the requirements
- in the relevant Recommendations cited above should nevertheless
- take into account those requirements that are specified for testing
- and maintenance actions which require communication between the two
- ends of a data link. Interface requirements for testing and mainte-
- nance are specified in Recommendation Q.707.
-
-
-
- Figure 2/Q.702 p.22
-
-
-
- 5 Digital signalling data link
-
-
-
- 5.1 Signalling data link derived from the 2048-kbit/s digi-
- tal path
-
-
- When a signalling data link is to be derived from a
- 2048-kbit/s digital path, the following shall apply:
-
- a) The interface requirements, specified at Point C
- in Figure 2/Q.702, should comply with Recommendations G.703 [17]
- for the electrical characteristics and G.704 [1] for the functional
- characteristics, in particular the frame structure.
-
- b) The signalling bit rate shall be 64 kbit/s.
-
- c) The standard channel time slot for the use of a
- signalling data link is time slot 16. When time slot 16 is not
- available, any channel time slot available for 64-kbit/s user
- transmission may be used.
-
- d) No bit inversion is performed.
-
-
- 5.2 Signalling data link derived from the 8448-kbit/s digi-
- tal path
-
-
- When a signalling data link is to be derived from a
- 8448-kbit/s digital link, the following shall apply:
-
- a) The interface requirements, specified at Point C
- in Figure 2/Q.702, should comply with Recommendations G.703 [23]
- for the electrical characteristics and G.704 [1] for the functional
- characteristics, in particular the frame structure.
-
- b) The signalling bit rate shall be 64 kbit/s.
-
- c) The standard channel time slots for the use of
- a signalling data link are time slots 67 to 70 in descending order
- of priority. When they are not available, any channel time slot
- available for 64-kbit/s user transmission may be used.
-
-
-
-
-
-
-
-
-
- d) No bit inversion is performed.
-
-
-
- 5.3 Signalling data link derived from the 1544-kbit/s digi-
- tal path
-
-
- (For further study.)
-
- Note - When a signalling bit rate of 64 kbit/s is adopted,
- the values of bits should be inverted within the signalling termi-
- nal or the interface equipment in order to meet the minimum mark
- density requirements of the Recommendation G.733 [2] based PCM sys-
- tems.
-
-
- 5.4 Signalling data link established over a digital path
- made up by digital sections based on different digital hierarchies
-
-
- When a signalling data link is to be established between net-
- works based on different digital hierarchies and speech encoding
- laws, the following shall apply:
-
- a) The interface requirements, specified at Point C
- in Figure 2/Q.702, should comply with Recommendations G.703 [17]
- for the electrical characteristics and G.802 [3] for other aspects,
- e.g., for interworking arrangements.
-
- b) The signalling bit rate shall be 64 kbit/s.
-
- c) No bit inversion is performed.
-
-
- 5.5 Signalling data link established over data circuits
-
-
- When a signalling data link is to be established over data
- circuits derived from a 64-kbit/s digital stream having a frame
- structure as specified in such Recommendations as X.50 [10],
- X.51 [11], X.50 | fIbis [12] and X.51 | fIbis [13] the following
- shall apply:
-
- a) The interface requirements, specified at Point C
- in Figure 2/Q.702, should comply with relevant requirements in one
- of the above-mentioned Recommendations, applicable to the environ-
- ment of the intended use.
-
- b) When 64-kbit/s multiplexed streams are carried
- on 2048-kbit/s or 1544-kbit/s digital links,
- Recommendation G.704 [1], should apply.
-
- 6 Analogue signalling data link
-
-
-
-
-
-
-
-
-
-
-
-
- 6.1 Signalling bit rate
-
-
- 6.1.1 Applications of the analogue signalling data link must
- take account of the delay requirements described in S 2.2.
-
-
- 6.1.2 For telephone call control applications, the signalling
- bit rate over an analogue signalling data link shall be higher or
- equal to 4.8 kbit/s.
-
-
- 6.2 Interface requirements
-
-
- In case of 4.8-kbit/s operation, interface requirements speci-
- fied at the interface point B in Figure 2/Q.702 should comply with
- relevant requirements specified for 4.8-kbit/s modems in
- Recommendations V.27 [18] and V.27 | fIbis [19]. In addition, the
- following shall apply:
-
- a) Application of either Recommendations V.27 [18]
- or V.27 | fIbis [19] depends on the quality of the analogue
- transmission channels used. Recommendation V.27 [18] shall apply
- only to transmission channels conforming to
- Recommendation M.1020 [20], while Recommendation V.27 | fIbis [19]
- to transmission channels conforming to Recommendation M.1020 [20]
- or of lower quality.
-
- b) Full duplex operation over a 4-wire transmission
- link should be adopted.
-
- c) If a separate modem is to be used, the interface
- requirements specified in Recommendations V.10 [10], V.11 [11],
- V.24 [12] and V.28 [13], applicable at Point A in Figure 2/Q.702,
- should be followed as much as possible.
-
-
-
- References
-
-
- [1] CCITT Recommendation Functional characteristics of
- interfaces associated with network nodes , Vol. III, Rec. G.704.
-
- [2] CCITT Recommendation Characteristics of primary PCM
- multiplex equipment operating at 1544 kbit/s , Vol. III,
- Rec. G.733.
-
- [3] CCITT Recommendation Interconnection of digital paths
- using different techniques , Vol. III, Rec. G.802.
-
- [4] CCITT Recommendation Fundamental parameters of a mul-
- tiplexing scheme for the international interface between synchro-
- nous data networks , Vol. VIII, Rec. X.50.
-
- [5] CCITT Recommendation Fundamental parameters of a
-
-
-
-
-
-
-
-
-
- multiplexing scheme for the international interface between syn-
- chronous data networks , Vol. VIII, Rec. X.51.
-
- [6] CCITT Recommendation Fundamental parameters of a
- 48-kbit/s user data signalling rate transmission scheme for the
- international interface between synchronous data networks ,
- Vol. VIII, Rec. X.50 | fIbis .
-
- [7] CCITT Recommendation Fundamental parameters of a
- 48-kbit/s user data signalling rate transmission scheme for the
- international interface between synchronous data networks using
- 10-bit envelope structure , Vol. VIII, Rec. X.51 | fIbis .
-
- [8] CCITT Recommendation Transmission of the answer signal
- , Vol. VI, Rec. Q.27.
-
- [9] CCITT Recommendation Error performance on an interna-
- tional digital connection forming part of an integrated services
- digital network , Vol. III, Rec. G.821.
-
- [10] CCITT Recommendation Electrical characteristics for
- unbalanced double-current interchange circuits for general use with
- integrated circuit equipment in the field of data communications ,
- Vol. VIII, Rec. V.10.
-
- [11] CCITT Recommendation Electrical characteristics for
- balanced double-current interchange circuits for general use with
- integrated circuit equipment in the field of data communications ,
- Vol. VIII, Rec. V.11.
-
- [12] CCITT Recommendation List of definitions for inter-
- change circuits between data-terminal equipment and data
- circuit-terminating equipment , Vol. VIII, Rec. V.24.
-
- [13] CCITT Recommendation Electrical characteristics for
- unbalanced double-current interchange circuits , Vol. VIII,
- Rec. V.28.
-
- [14] CCITT Recommendation Data transmission at 48 kbit/s
- per second using 60-108 kHz group band circuits , Vol. VIII,
- Rec. V.35.
-
- [15] CCITT Recommendation Modems for synchronous data
- transmission using 60-108 kHz group band circuits , Vol. VIII,
- Rec. V.36.
-
- [16] CCITT Recommendation List of definitions for inter-
- change circuits between data terminal equipment (DTE) and data
- circuit-terminating equipment (DCE) on public data networks ,
- Vol. VIII, Rec. X.24.
-
- [17] CCITT Recommendation Physical/electrical characteris-
- tics of hierarchical digital interfaces , Vol. III, Rec. G.703.
-
- [18] CCITT Recommendation 4800 bit/s per second modems with
- manual equalizer standardized for use on leased telephone-type cir-
- cuits , Vol. VIII, Rec. V.27.
-
-
-
-
-
-
-
-
-
- [19] CCITT Recommendation 4800/2400 bit/s per second modem
- with automatic equalizer standardized for use on leased
- telephone-type circuits , Vol. VIII, Rec. V.27 | fIbis .
-
- [20] CCITT Recommendation Characteristics of special qual-
- ity international leased circuits with special bandwidth condition-
- ing , Vol. IV, Rec. M.1020.
-
-
- BLANC
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-