EINDHOVEN UNIVERSITY OF TECHNOLOGYDepartment of Electrical EngineeringDigital Systems Group ( EB )

REQUIREMENTS MODEL FOR LEVEL 2OF THE MESSAGE TRANSFER PART OF

SIGNALLING SYSTEM NO.7

by I.W.J. van Dreumel

Master ThesisEindhoven, May 1991

Supervisors: Prof. Ir. M.P.J. StevensIr. M.J.M. van Weert

The Department of Electrical Engineering of the Eindhoven University of Technology does not accept any responsibilityregarding the contents of student project and graduation reports

SUMMARY

At the Digital Systems Group ( EB ) of the Department of Electrical Enginee­

ring at the Eindhoven University of Technology a digital telephone exchange is

being developed. When this telephone exchange is put into use, it will have to

exchange signalling information ( e.g. information about setting up and breaking

down connections between subscribers) with other telephone exchanges. To

manage this exchange of signals a signalling system is needed.

This report contains an overview of such a system: Signalling System NO.7

of the CCITT ( SS7 ) [CCITT, 1989]. SS7 is a common channel signalling system,

which means that signalling data for a number of traffic circuits is carried over a

separate signalling channel.

The main part of SS7 is the Message Transfer Part ( MTP ), the transport

mechanism that exists of three levels. It takes care of delivering the signalling

messages without loss or duplication, and in the correct order. The MTP is

discussed in detail.

Further a structured analysis of level 2 of the MTP is done, using the formal

method that is described by D.J. Hatley and I.A. Pirbhai [Hatley, 1987]. The CASE­

tool ProMod, which supports this method, is used to state a requirements model of

level 2. This model, that is described in [Dreumel, 1991], satisfies the requirements

of level 2 of the MTP as is described in the Blue Books, recommendations 0.700­

0.703.

Development of the architecture model of level 2, as well as its implementa­

tion are still to be done.

1

CONTENTS

SUMMARY , 1

1. INTRODUCTION 4

2. SIGNALLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5

2.1. Introduction to signalling 5

2.2. Signalling network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5

2.2.1. Signalling points 7

2.2.2. Signalling links 8

2.2.3. Signalling modes 8

2.2.4. Signalling routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9

2.3. Signalling System NO.7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9

2.3.1. Message Transfer Part ( MTP) 9

2.3.2. User Parts ( UP) 10

2.3.3. Signalling Connection Control Part ( SCCP) . . . . . . . . .. 10

2.4. Problem description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11

3. THE MESSAGE TRANSFER PART 12

3.1. Overview MTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12

3.2. Level 1, the signalling data link . . . . . . . . . . . . . . . . . . . . . . . . .. 13

3.3. Level 2, the signalling link functions 13

3.3.1. Signal Units 13

3.3.2. Error detection and correction 15

3.3.3. Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17

3.3.4. Delimitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17

3.3.5. Processor outage . . . . . . . . . . . . . . . . . . . .. 17

3.3.6. Signalling link error monitoring , 18

3.3.7. Flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 18

3.4. Level 3, the signalling network functions 19

2

4. STRUCTURED SYSTEM DEVELOPMENT 21

4.1. Overview 21

4.2. Hatley & Pirbhai 21

4.2.1. The overall strategy , 21

4.2.2. The requirements model 22

4.2.3. The architecture model 26

4.3. The CASE-tool ProMod " 28

4.3.1. Requirements analysis and definition 29

5. THE REQUIREMENTS MODEL OF MTPs LEVEL 2 . . . . . . . . . . . . . . . . .. 31

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 31

5.2. The recommendations on SS7 .. . . . . . . . . . . . . . . . . . . . . . . .. 31

5.2.1. SOL, Specification and Description Language 32

5.3. Structural description of MTPs level 2 .. . . . . . . . . . . . . . . . . . .. 34

5.3.1. Division of the MTP into functional blocks . . . . . . . . . . .. 34

5.3.2. First level partitioning . . . . . . . . . . . . . . . . . . . . . . . . . .. 37

5.3.3. Lower level partitioning 38

5.4. Functional description of MTPs level 2 39

5.4.1. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39

5.4.2. Processes 39

5.4.3. CSP-bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 40

5.4.4. Stores 42

5.4.5. Terminators 42

6. CONCLUSIONS AND RECOMMENDATIONS . . . . . . . . . . . . . . . . . . . . .. 43

REFERENCES 44

ABBREVIATIONS 46

ANNEX A: CONTEXT DIAGRAMS LEVEL 0 . . . . . . . . . . . . . . . . . . . . . . . .. 47

ANNEX 8: FLOW DIAGRAMS LEVEL 1 50

ANNEX C: HOW TO PRINT FDs USING THE LASER PRINTER . . . . . . . . . .. 53

3

1. INTRQDUCTION

At the Digital Systems Group ( EB ) of the department of Electrical Enginee­

ring at the Eindhoven University of Technology, a digital telephone exchange is

being developed. Since 1986 a project group consisting of five students on average

( trainees or graduates ) has been working on this project. First under supervision

of Prof. Ir. A. Heetman and later taken over by Ir. M.J.M. van Weert and Prof. Ir.

M.P.J. Stevens.

In August 1990 the first implementation of the exchange was completed and

tested. The next thing to do was to analyse and implement a system that serves

the transfer of control signals between two or more of those digital exchanges. This

system, which is called a signalling system, had to correspond to the software of

the exchange control that was implemented before [Verhoof, 1990][Ligtenberg,

1990]. The Signalling System described in this report is CCITIs Signalling System

NO.7 ( SS7 ) [CCITI, 1989].

Analysis of that system was done using the CASE-tool ProMod according to

the formal method proposed in [Hatley, 1987]. Because time was limited, my

graduation project was confined to develop the requirements model of one of the

main parts of SS7, the Message Transfer Part. This requirements model is the first

of two models to be developed before the Message Transfer Part may be implem­

ented.

The purpose of this report is to help the system designer who has to imple­

ment level 2. Chapter 2 describes the subject of signalling. It also contains an

overview of SS7s most important functional blocks. Chapter 3 contains a complete

overview of the Message Transfer Part, which is the main subject of this report. In

chapter 4 the formal method that is used to develop the requirements model

[Hatley, 1987] will be discussed. It also describes the CASE-tool ProMod [ProMod,

1989] which supports this method. Chapter 5 describes the development of the

requirements model of level 2 of the Message Transfer Part. The partitioning of this

level will be discussed. This partitioning results in a satisfying requirements model

[Dreumel, 1991] of level 2.

4

2. SIGNALLING

2.1. Introduction to signalling

To set up and release telephone connections there has to be an exchange

of control information between the subscriber and the telephone exchange and

between the telephone exchanges themselves. This exchange of control signals is

called signalling. At the time when the first telephone exchanges were put into use,

signalling took place in a very simple way. Most of the control information was

exchanged verbal. The introduction of semi-automatic an automatic switching

systems, based on electromechanical switching technics have lead to the develop­

ment of a number of optimized signalling systems.

Because of the use of stored-program controlled exchanges and digital

transmission networks a digital telecommunication network comes into existence.

This digital network supports a lot of new services, including many that are based

on the Integrated Services Digital Network ( ISDN ). For this reason the need for

signalling will increase. To satisfy this need an 'intelligent' signalling system is

developed by the CCITT: Signalling System No. 7 ( SS7 ).

2.2. Signalling network

SS7 is a Common-Channel Signalling ( CCS ) system, which means that

signalling data for a number of traffic circuits is carried over a separate signalling

channel [Ronayne, 1986]. This concept is shown in figure 2.1.

Before the introduction of CCS , the signalling systems were based on

Channel Associated Signalling ( CAS ): the signalling information for a small

number of traffic circuits is carried over that particular circuit. This is done at fixed

moments, even when a traffic circuit is not in use. Therefore CAS is relatively

expensive. On the other hand CAS is rather slow because of the fact that signalling

data is transmitted at the same speed as e.g. speech signals. The stored-program

5

controlled exchanges however are capable of working at much higher speeds. A

CCS system doesn't have these problems.

GJ--------\GSignalling drcult

Traffic drcults

Figure 2.1. Common Channel Signalling

Because of the fact that CCS uses separate channels for signalling data and traffic

it is necessary to identify the signalling data by including a label. Further error

detection and error correction are required.

The telecommunications network served by common-channel signalling

( SS? ) is composed of a number of switching and processing nodes interconnec­

ted by transmission links. To transfer signalling information between these nodes

using SS? signalling, each of these nodes requires to comprise the necessary 'in

node' features, making that node a signalling point ( SP ) in the SS? signalling

network. A SP is able to serve its users ( e.g. the telephone network) as well as to

pass signalling information to other SPs

In addition, there is a need to interconnect these SPs so that signalling

information can be exchanged between them. These data links are the signalling

links of the signalling network.

The combination of SPs and their interconnecting signalling links form the

SS? signalling network.

6

2.2.1. Signalling points

Any two signalling points for which the possibility of communication between

them exists, are said to have a signalling relation. Examples of nodes in a signalling

network are:

exchanges,

operation, administration and maintenance centres,

intelligent network databases, and

signalling transfer points.

All SPs in a SS? signalling network are identified by a unique code known as

a point code.

A signalling point at which a message is generated is known as the origina­

ting point of that message. A signalling point to which a message is destined is

known as the destination point of that message. A signalling point at which a

message is received on a signalling link and then transferred to another link is

known as a signal transfer point ( STP ) ( figure 2.2. ). A STP is a signalling point to

which no signalling users are connected.

Ortglnatlng Point

Destination Point

----ft----t> Signal Transfer Point

Figure 2.2. Signalling point modes

?

2.2.2. Signalling links

The common-channel signalling system uses signalling links to exchange the

signalling messages between two 5Ps. A number of signalling links that directly

interconnect two 5Ps form a signalling link-set.

2.2.3. Signalling modes

The term signalling modes 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 are transferred between

two 5Ps over a single link that directly interconnects those 5Ps.

In the non-associated mode of signalling, the messages are transferred

between two 5Ps over two or more links in tandem, passing through one or more

5Ps. Those 5Ps are not the originating point or the destination point. This mode of

signalling is not specified for 557.

The quasi-associated mode of signalling is a limited case of the non-associa­

ted mode. The path taken by the message through the signalling network is

predetermined and, at a given point in time, fixed (figure 2.3. ).

AssocIated comm.

G~~G

~STPI BOUasl·assocIated comm.

Figure 2.3. Associated vs quasi-associated

8

2.2.4. Signalling routes

The predetermined path, consisting of a succession of SPs and the intercon­

necting signalling links, that a message takes through the signalling network

between the origination point and the destination point is the signalling route for

that signalling relation.

All the signalling routes that may be used between an originating point and a

destination point by a message is known as the signalling route set for that

signalling relation.

2.3. Signalling System No.7

The CCITI Signalling System No. 7 ( SS7 ) is a common-channel signalling

system in which information can be transported between two stored-program con­

trolled exchanges over a single high-speed communications channel ( 64 kbitjs )

by means of labelled messages. The signalling information relates to a large

number of circuits and it provides the capability to implement a variety of new

services. When CCITIs SS7 was first specified, its main purpose was to set up and

release physical circuits between digital exchanges for telephony-type services. To

take account of the wide range of applications that were foreseen for the signalling

system, it was designed on a very modular functional basis. The transport mecha­

nism, the Message Transfer Part, is application independent, and it is this feature

that is one of the principal strengths of SS7. Figure 2.4. shows schematically the

structure of SS7. The separate parts of SS7 will be discussed in the following

sections.

2.3.1. Message Transfer Part ( MTP )

The MTP [CCITI, 1989, rec. a.703] is common for all applications. It is a

reliable transport mechanism that transfers signalling messages over the network

and performs functions such as error control. The MTP has a three-level hierarch­

ical structure which will be discussed in Chapter 3.

9

Level 1-3

Signalling System No.7

~~EJI

SCCP U 1 ----'1 Level 4

I ~--~~~--___jll------------+-L- ~ .

I ~TP I

MTP - Message Transfer Part

SCCP - Signalling Connection Control Part

UP - User Part

Figure 2.4. Structure of SS?

2.3.2. User Parts ( UP )

The UPs are application dependent. They are the users of the MTP and the

SCCP ( see section 2.3.3. ). Within a UP the functions and procedures used by a

specific application are defined. Some example of UPs are the Telephone User Part

( TUP ), the Data User Part ( DUP ) and the Integrated Services Digital Network

User Part ( ISDNUP ). All those UPs are users of the signalling functions. The MTP

also contains the possibility to transfer information that is not specifically signalling

information between UPs. These UPs are called exploitation user parts. Some

examples are network-management, network-maintenance, tariff-information, etc.

( see figure 2.5. ).

2.3.3. Signalling Connection Control Part ( SCCP )

The SCCP provides additional functions to the MTP. This functions allow

connectionless and connection-oriented network services to transfer circuit-related

10

Data UP

1

Telephone UP

Exploltal\on UPs

Figure 2.5. UPs in the signalling network

and non-circuit-related signalling information. The connectionless network service

enables the users of the signalling network to transfer signalling data without first

setting up a signalling connection.

In case of connection-oriented control a signalling connection has to be set up first.

The SCCP provides a routing function which allows signalling messages to

be routed to a signalling point, based on an address that is not a point code ( but

e.g. dialled digits ). This capability includes a translation function which translates

the address into a point code and a user part number.

The SCCP also provides a management function, which controls the

availability of the users of the signalling network. It sends this information to other

nodes in the signalling network which have a need to know the status of those

users.

2.4. Problem description

In the next chapter the MTP will be treated. It is this part that is the major

subject of this report. The intention is to develop a Requirements Model of a part of

this MTP so that this part can be implemented later on ( using CASE-tool ProMod ).

11

3. THE MESSAGE TRANSFER PART

3.1. Overview MTP

Communication between stored-program controlled exchanges requires a

fast reliable high-capacity signalling system, capable of operating in a digital

transmission environment. SS? is such a signalling system. The modular nature of

SS? makes it flexible and adaptable for a number of uses, but no matter what use

is made of the signalling information carried, the MTP is always required. The MTP

provides the functions that enable information, that is significant for the user parts,

passed to the MTP to be transferred across the SS? signalling network in Message

Signal Units ( MSU ) to the required destination. Mechanisms are provided in the

MTP that ensure MSUs are received in the correct sequence and without errors.

Whenever an error is detected, the corrupted MSU will be retransmitted. In addition,

further procedures ensure that the impact of network or system failures have

minimal effect on the ability of the MTP to transfer MSUs.

The MTP consists of three levels and this structure is shown in figure 3.1.

Message Transfer Part I

Signalling net· !!

work functionsSignalling link

SIgnallingmessage Sran,ng Signallinghandling Un data

tuncIIons link

SIgnallIngnetwor1< ,management 1____~I

I

~Level 3 __*=Level 2 =*Level 1 ~

i i

iIIi!,i,i

'I I

Ui,

----------;,

.__T_esting_and maintenance J

Figure 3.1. Levels of the MTP

12

The levels will be described in the next sections.

3.2. Level 1. the signalling data link

The level 1 functions provide the data link, which is a bi-directional trans­

mission path for signalling consisting of two data channels operating together in

opposite directions at the same data rate. The data rate normally chosen for SS? is

64 kbit/s, but lower rates down to 4.8 kbit/s can be used.

The transmission path could be e.g. time-slot 16 of a 32 time-slot system.

( Le. associated signalling ). The level 1 functions are not specific to the signalling

system, and are more fully documented in the appropriate transmission recommen­

dations ( CCITIs Blue Books ).

3.3. Level 2. the signalling link functions

These functions form the main subject of this report. The development of the

requirements model, discussed in Chapter 5, is based on these functions.

The MTP level 2 contains procedures, called signalling link functions, which

facilitate the reliable transfer of messages over a single signalling link. These

functions ensure that messages are delivered in the correct order, and without loss

or duplication, on a link having line error rates up to a specified limit. Error rates

higher than this limit cause the link to fail.

After the description of the signal unit format in section 3.3.1. the discussion

of those functions will follow.

3.3.1. Signal Units

Signalling information is transferred between the nodes at each end of a

signalling link in signal units ( SU ). Each SU is marked by a unique 8 bit pattern at

the beginning and at the end. This pattern is called the flag. There exist three types

of SUs:

13

Fill In Signal Units ( FISU ) which are normally sent when no messa­

ges are available for transmission,

Link Status Signal Units ( LSSU ) which are used in the control of the

link, and

Message Signal Units ( MSU ) which carry the user part information.

The signal unit formats are shown in figure 3.2.

FISU

8 18 2 8 1 7 1 7 8

LSSU

8 18 8or18 2 8 1 7 7 8

MSU

8 18 an 8 2 8 1 7 7 8n>-2

Figure 3.2. Signal unit formats

The coding of the length indicator ( LI ) is the means of identifying to which

of the three types a SU belongs. This LI is common to all types. LI =0 in case of a

FISU, LI = 1 or LI =2 in case of a LSSU, and when the signal unit is a MSU then

LI > 2. The flag ( F ) is used for delimitation.

The forward indicator bit ( FIB ), backward indicator bit ( BIB ), forward

sequence number ( FSN ), and backward sequence number ( BSN ) are used in

the basic error control procedure to perform the signal unit sequence control and

acknowledgement functions. The check bits ( CK ) are used for error detection.

LSSUs have the same format as FISUs except for the addition of the status field

( SF ) which indicates the link status as follows:

14

Status indication 'out of alignment' ( SID ) is transmitted when an

initial alignment procedure has been started and none of the status

indications SID, SIN or SIE is received from the signalling point at the

far end of the link.

Status indication 'normal' ( SIN ) is transmitted when, after initial

alignment has been started, status indication SID, SIN or SIE is

received, and the terminal is in the 'normal' alignment state.

Status indication 'emergency' ( SIE ) is transmitted when, after initial

alignment has been started, status indication SID, SIN or SIE is

received, and the terminal is in the 'emergency' alignment state.

Status indication 'out of service' ( SIOS ) is transmitted to inform the

remote end of the link that the transmitting signalling link terminal

cannot, for reasons other than processor outage, receive or transmit

MSUs.

Status indication 'processor outage' ( SIPO ) is transmitted to inform

the remote end of the link that the transmitting signalling link terminal

cannot receive or transmit MSUs, owing to processor outage that is

caused by failure conditions at a functional level above level 2.

Status indication 'busy' ( SIB) is transmitted to inform the remote end

of the link that the transmitting signalling link terminal is operating

under level 2 congestion conditions.

MSUs have exactly the same format as FISUs except for the addition of a

service information octet ( SID) and the signalling information field ( SIF ) which

are used at levels above level 2 as described in the section on Level 3, section 3.4.

3.3.2. Error detection and correction

The error detection function is performed by means of 16 check bits

provided at the end of each signal unit. The check bits are generated by the

transmitting signalling link terminal by operating a specified algorithm [CCITT, 1989,

rec. a.703} on the preceding bits in the signal unit. At the receiving signalling link

15

terminal, the correspondence between the check bits and the remaining part of the

signal unit is checked. Signal units found to be in error are discarded.

Error correction is performed by retransmission. This method ensures

correct transfer of message signal units ( MSUs ) over a signalling link, in sequence

and with no double delivery. As a consequence, no resequencing or eliminating of

the received information is required within the user parts.

Positive acknowledgements are used to indicate correct transfer of MSUs,

while negative acknowledgements are used as explicit requests for retransmission

of signal units that are received in a corrupt form. To minimize the number of

retransmissions, a request for a retransmission is made only when a MSU has

been lost.

The method requires that transmitted but not yet positively acknowledged

MSUs remain available for retransmission. To maintain the correct MSU sequence

when a retransmission is made, the MSU of which the retransmission has been

requested, and any subsequently transmitted MSUs are retransmitted in the order

in which they were originally transmitted.

As part of the error correction method, each signal unit carries a forward

sequence number ( FSN ), a forward indicator bit ( FIB ), a backward sequence

number ( BSN ) and a backward indicator bit ( BIB ). The error correction procedu­

re operates independently in the two transmission directions. The FSN and the FIB

in one direction together with the BSN and the BIB in the other direction are

associated with the MSU flow in the first direction.

The receiving link terminal acknowledges the acceptance of one or more

MSUs by assigning the FSN value of the latest accepted MSU to the BSN of the

.next signal unit sent in the opposite direction. The BSN of subsequent signal units

retain this value until a further MSU is acknowledged, which will cause a change of

the BSN sent. The acknowledgement to an accepted MSU also represents an

acknowledge to all previously accepted, though not yet acknowledged MSUs.

If a negative acknowledgement is to be sent, then the BIB value of the signal

units transmitted is inverted. The new BIB value is maintained in subsequently sent

signal units until a new negative acknowledgement is to be sent. The BSN assumes

the value of the FSN of the last accepted MSU.

16

The FIB value is inverted by the transmitting signalling link terminal when a

retransmission is started. Its value therefore becomes equal to that of the BIB value

which indicated that retransmission was required.

3.3.3. Alignment

Before a link can enter service, an alignment procedure is 'used to ensure

that the link is capable of operating above a certain performance. This procedure is

used when a link is brought into service and when service is being restored after a

break. It includes a proving period which, by instruction of level 3, can be either a

'normal' proving period or an 'emergency' proving period. The 'normal' period lasts

as long as it takes to transmit 216 octets while the 'emergency' period lasts as long

as it takes to transmit 212 octets. During the proving period, the error rate of the link

is monitored.

3.3.4. Delimitation

The beginning and end of a signal unit are indicated by a unique 8-bit

pattern, called the flag. Further measurements are taken to ensure that this pattern

cannot be imitated elsewhere in the signal unit (this is called zero bit insertion ).

The specific flag pattern is 01111110. The zero bit insertion function inserts a 0 after

every sequence of five consecutive 1s before the flags are attached and the signal

unit is transmitted. At the receiving signalling link terminal, after flag detection and

removal, each 0 that follows a sequence of five consecutive 1s is deleted ( zero bit

deletion ). Figure 3.3. shows an example of this delimitation function.

3.3.5. Processor outage

The processor outage procedure operates when use of a link is precluded

owing to problems at a functional level higher than level 2 ( e.g. a centralised

processor failure ). When level 2 recognises, or is informed of this state, it transmits

SIPO on the link and discards received MSUs. The receiving level 2 at the distant

17

...•......0110011111111001001100011111111110 .

t t tInsert: o

becomes:

o 0

..........01100111110111001001100011111011111100 .

Figure 3.3. Zero bit insertion

end, if it is in its 'normal' mode sending MSUs or FISUs, notifies its level 3 and

sends FISUs continuously. When the processor outage condition changes to

normal, SIPO is withdrawn and the transmitting end transmits MSUs or FISUs. The

receiving end also returns to normal operation after informing level 3.

3.3.6. Signalling link error monitoring

Level 2 contains two link error rate monitor functions. One, the signal unit

error rate monitor, which is used when a signalling link is in service to determine

whether or not the link is fit for service. The other, the alignment error rate monitor,

is used during the proving period of the initial alignment procedure. The latter was

already mentioned in section 3.3.3.

3.3.7. Flow control

When congestion at level 2 is detected at the receiving end of the link, both

positive and negative acknowledgements are withheld and SIB is returned to the

transmitting end, so that the latter can distinguish between failure and congestion

18

conditions. A supervision timer is started on receipt of SIB and, should it expire

before normal operation of the link is restored, link failure indication is generated.

3.4. Level 3, the signalling network functions

Level 3 of the MTP provides functions and procedures to allow for the

transfer of signalling messages between signalling points which are part of the

signalling network. The level 3 functions, called the signalling network functions,

can be divided into two groups. These two groups will be discussed briefly:

Signalling message handling functions:

The purpose of these functions is to ensure that the signalling messa­

ges originated by a particular user part at a signalling point ( Le. the

originating point ) are delivered to the same user part at the destinati­

on point indicated by the sending user part. This delivery may be

made through a single signalling link that directly interconnects the

originating and destination point, or through two or more links via one

or more signalling (transfer) points.

These functions are based on the label contained in the messages.

This label is called the routing label ( figure 3.4. ).

16 2 1 7

flag

178

Routing label •Level 3 Signalling Unk Selection

!in~~_+

SLS SI OrIginating Point Code

8n 4 14 14 8 +

n>-o Destination Point Code

+8ervIce Indicator

Figure 3.4. Routing label

19

Signalling network management functions:

The purpose of these functions is to provide reconfiguration of the

signalling network in case of failure and to control traffic in case of

congestion. Such a reconfiguration is effected by use of appropriate

procedures to change the routing of signalling traffic in order to

bypass the faulty links or signalling points. When the faulty link or

signalling point is restored, the opposite actions and procedures take

place, in order to re-establish the normal configuration of the signal­

ling network.

20

4. STRUCTURED SYSTEM DEVELOPMENT

4.1. Overview

Implementing the CCITIs Signalling System No. 7 is a complicated job. The

description of the CCITI-Recommendations on SS7 include as much as almost

1500 pages [CCITI, 1989]. It will be clear that SS7 is a very complex system.

Therefore it is necessary to make use of structured methods in the system develop­

ment phase. These methods must both be standardized as well as formal. Stand­

ardized, because other people have to be able to understand, and perhaps

continue or change, the work. On the other hand the method has to be formal

because that is the only way to cope with vagueness. This is also of importance for

other people.

Today a number of methods and tools have been created to aid in every

phase of system development. An integrated set of such methods and tools is

called Computer-Aided Software Engineering tool, a CASE-tool.

The method that will be used to analyse, and later on design and implement

SS7 is described by D.J. Hatley and I.A. Pirbhai [Hatley, 1987]. Section 4.2.

explains this structured method in detail. Section 4.3. contains the description of a

CASE-tool that supports the Hatley & Pirbhai-method. This tool, which is used to

analyse SS7, is called ProMod [ProMod, 1989].

4.2. Hatley & Pirbhai

4.2.1. The overall strategy

The formal method by Hatley & Pirbhai is an adaptation of earlier methods

for structured analysis and structured design, which can be found in the so-called

Yourdon-literature [yourdon, 1978] [Ward, 1985]. E. Yourdon is the writer of one of

the first books on this subject.

21

According to the method two models have to be developed before the

system may be implemented. The first model is called the requirements model

( section 4.2.2. ) and must describe what the system must do. The second model

is called the architecture model ( section 4.2.3. ) and must describe how the

system design will be structured. The next sections will describe both models.

4.2.2. The requirements model

The requirements model is not a physical model of the design. It represents

what has to be designed, not how to design it. It must leave as much space as

possible to the designers choice how to implement the system.

The principal tools of the requirements model are flow diagrams ( FDs ):

graphical models of signal flows and processes acting on those flows. FDs consist

of data flow diagrams, DFDs, and control flow diagrams, CFDs.

The other components of the requirements model are:

Process specifications ( PSPECs ): they specify in concise terms

each detail of the system's functional requirements.

Control specifications ( CSPECs ): they specify the processing of

control flow.

Requirements dictionary: this part contains a listing of all the data­

and control-flows on the DFDs and CFDs together with their definiti­

ons.

Response timing specifications: this part defines the limits on

response time allowed between events at the system's input and the

resulting events at the system's output.

In figure 4.1. the relations of the components of the requirements model are shown.

The flow diagrams ( Le. DFDs and CFDs ) are graphical models of signal

flows ( Le. data- and control-flows) and processes acting on those flows. The

analyst decomposes the system and its functions into a hierarchical structure of

processes, and describes the requirements of the system.

22

Data Context Control Context

DiagramTIming

Diagram

~ -{) SpecIfIcatIon /1 4"~

"l~

Data Flow

h- ~Control Flow

Diagrams Diagrams

.& ~Prooes Control

Specifications SpecIfIcatIons

~ ~

I Requirements Dictionary IFigure 4.1. Components of requirements model

On the top-level, only one process exists. This process represents the

system that has to be designed. The flow diagram ( FD ) that contains this process

is called the context diagram. This diagram, which contains the Data Context

Diagram as well as the Control Context Diagram, describes the communication of

the system with the outer world. Objects belonging to this outer world may be

placed in the context diagram. These objects are called terminators.

The top-level process is functionally decomposed into smaller ( sub )

processes. This decomposition of ( sub) processes continues until, at the lowest

level, a number of primitive processes exist. A process is called a primitive process

when it can be described by a PSPEC in an unambiguous way ( e.g. using

structured English ). Each process that is not a primitive process is described by a

FD.

As been told before, a FD actually consists of two FDs, a DFD and a CFD,

but they may be drawn as one diagram. Figure 4.2. shows an example of a context

diagram, figure 4.3. shows an example of a FD at a level below the top-level.

23

Figure 4.2. Context diagram

~-------}------------;

......_------I

~ ,,/'-----_/

*bOw;*bOw

Figure 4.3. Flow diagram

The elements that may be used in the FDs are:

Processes ( circles ) are part of the hierarchical structure as descri­

bed above. A process indicates the transformation of incoming flows

24

into outgoing flows. Non-primitive processes are described by a FD

one level lower in the hierarchy, primitive processes by a PSPEC.

A Data flow ( directed arc) is a pipeline through which data of known

composition flows. It may consist of a single element or a group of

elements ( e.g. a data flow may represent a single bit, a bit stream,

but also the traffic-flow on a road ). Data flows may be split or mer­

ged.

What is stated for data flows is valid for control flows ( dashed

arcs ) too, except that they carry control information. The difference

between data and control is difficult to describe and depends on the

interpretation of the model developer.

A Store ( two horizontal lines ) is simply a flow frozen in time. The

information it contains may be used any time after that information is

stored and in any order.

A CSPEC bar ( bar, only used in a CFD ) is used on a CFD to

indicate the interface between the CFD and its CSPEC. Different bars

in the same CFD are all associated with the same CSPEC.

A Terminator ( square ) represents an entity outside the context of

the system. It shows the communication of the system with the outer

world.

A set of DFDs and CFDs is a model of the requirements of a system, not a

representation of the system's implementation. The model is highly idealized; it is

assumed to be data triggered and infinitely fast. Whenever data sufficient for a

given process to perform its task appears at its inputs, it will perform that particular

task and do so instantaneously.

Some processes are not triggered by data, but by control. This means that

the activation of the process is described in the CSPEC or PSPEC.

25

4.2.3. The architecture model

Not too much will be told about this model, because it is beyond the subject

that is discussed in this report ( Le. the requirements model of SS7 ).

The architecture model is created to model the system's design, to show the

configuration of physical modules that perform all the required data and control

processing. The requirements are mapped into an architecture model taking all the

design constraints into account. The purposes of the architecture model are listed

below:

show physical components that make up the system,

define the information flow between these physical components, and

specify the channels on which this information flows.

To fulfil these purposes, the architecture model uses a number of compo­

nents ( diagrams, textual specifications ) which are shown in figure 4.4. and

described below.

Archlteclure Context

DiagramL.;::,.

~ 'V'Architecture Row (}- rt Architecture Intercon.

Diagrams Diagrams

~ ~Architecture Module Architecture Intercon.

Specification SpecIfIC8IIon

",7 "'7

IArchitecture DIctIonary

I

Figure 4.4. The architecture model

26

Architecture model components:

An architecture flow diagram ( AFD ) is a network representation of

a system's physical configuration; it documents the information flow

between all the architecture modules, of which there can be any

number in the system. The AFD also represents the allocation of flows

and processes from the DFDs and CFDs into architecture modules.

An architecture module specification ( AMS ) is written for every

module in the architecture model to state the allocation off data flow,

control flow, and processing to be performed by that module.

The architecture dictionary consists of a listing off all the data and

control elements that flow between the architecture modules as well

as between architecture modules and external entities.

The architecture context diagram establishes the information

boundary between the system being implemented and the environ­

ment in which the system has to operate. It is the highest level dia­

gram for any system.

An architecture Interconnect diagram ( AID) is a representation of

the communication channels that exist between the architecture

modules; it shows the physical means by which the modules commu­

nicate.

The architecture interconnect specification ( AIS ) establishes the

characteristics of the communication channels on which information

travels between architectural modules. It describes the transmission

medium and the information formats.

Like in the requirements model the architecture model consists of a layered

set of AFDs and AIDs and their associated AMSs and AISs, as can be seen in

figure 4.4.

27

4.3. The CASE-tool ProMod

Promod ( version 1.17a ) is a CASE-tool which supports the Hatley & Pirbhai

method for the most part. It is a highly automated system engineering environment

enabling the analyst to generate a detailed specification for system development.

Using ProMod the analyst forms that specification in three logical steps,which are

shown in figure 4.5.

Problem Requirements System Program

Statement -----t Analysls & f------t DesIgn ~ Design --l>

DefInition

User's

Wishes

System

Model

System Program

SpecIfIcation SpecIfIcation

Figure 4.5. The ProMod project model

Those steps are listed below.

1 Using an elementary system of structured analysis, the analyst crea­

tes a basic graphic model of the required system.

2 With ProMod, utilizing information contained in the graphic model, the

analyst or designer develops a system architecture made up of

modules arranged hierarchically and with strictly defined interfaces.

3 Using a simple pseudo code, the designer refines algorithms and data

as ProMod prepares cross references for data, functions, user-selec­

ted attributes, etc, and prepares logically structured documents.

28

This results in a detailed system specification and a wide variety of valuable reports.

At each step in the development process ProMod automatically analyzes the

accumulated information to ensure consistency and completeness. This feature

prevents propagation of an error from step to step and ensure matching module

interfaces.

The three principal phases in the system development that are supported by

ProMod are:

Requirements analysis and definition.

System design.

Program design.

The first phase, requirements analysis and definition, is the only one to be discus­

sed in this report. The other two phases were no part of the analysis of SS?

4.3.1. ReqUirements analysis and definition

This first part of ProMod largely corresponds to developing a requirements

model according to Hatley & Pirbhai. A drawing editor allows the user to draw the

flow diagrams ( DFDs and CFDs ). A text editor makes it possible to enter the

control and process specifications as well as the data dictionary. Nevertheless,

ProMod has some minor disadvantages:

The program is very slow, even when it runs on an Intel 80386 MS­

dos machine. The error check procedure lasts approximately 30

minutes ( regarding my project file with a size of 3.? Mb ), even when

only a single item has been added or changed.

ProMod is extremely copy protected. I couldn't use ProMod for a

couple of weeks just because of this protection.

The internal text editor is very limited. Use of an external editor ( e.g.

WordPerfect) is possible and, when the user needs to type in a lot of

text, this is strongly recommended.

29

ProMod is not entirely compatible to the method of Hatley & Pirbhai. It

demands a specification of all processes instead of only for primitive

ones. These specifications are called mini specifications ( MSPs ).

30

5. THE REQUIREMENTS MODEL OF MTPs LEVEL 2

5.1 Introduction

This chapter discusses the design of the requirements model of level 2 of

the Message Transfer Part ( MTP ), the main subject of this report. The basis of the

design of this model are the CCITIs Recommendations and Specifications of

Signalling System No. 7 [CCITI, 1989], the so called Blue Books, especially

recommendations 0.700-0.703. This part of the Blue Books contains a specifica­

tion of the MTP in SOL ( Specification and Description Language ), described in

section 5.2.1. It is this specification that has to be transformed to the requirements

model.

At this point a major difference with regards to to the normal process of

designing the requirements model, appears. In most cases the starting point from

which such a model is developed is an idea, a thought. In this case however the

starting point is formed by recommendations 0.700-0.703, the complete SDL

specifications. At first sight it may not look very useful to transform one specificati­

on ( in SOL ) into another one ( the requirements model ) but in a further phase of

system development, the system design phase done by the system designer, the

requirements model offers more advantages than the SDL specifications does ( e.g.

support by the CASE-tool ProMod which is used at the Digital Systems Group ).

Section 5.2. contains a brief comment on the recommendations on SS7,

while sections 5.3. and 5.4. describe the phases of the design of the requirements

model using ProMod.

5.2. The recommendations on SS7

The Blue Books recommendations 0.700-0.795 contain the specifications of

Signalling System No.7, as mentioned before. This recommendations provide an

overview of the signalling system by describing the various functional elements of

SS7 and the relations between these functional elements. Some of these elements

31

are the MTP ( Message Transfer Part ), the SCCP ( Signalling Connection Control

Part ) and the UPs ( User Parts ). The part that is of importance for the require­

ments model is described in recommendation 0.703; specifications and descripti­

ons about level 2 of the MTP. Recommendation 0.703 describes the functions and

procedures for and relating to the transfer of signalling messages over one

signalling data link. These signalling link functions, together with a signalling data

link as bearer, provide a signalling link for reliable transfer of signalling messages

between two directly connected signalling points.

0.703 exists of description in text as well as descriptions in SOL-diagrams.

This diagrams show the flow of internal and external signals, they describe the

functional working of level 2. The problem is to translate this descriptions to a clear

and useful requirements model. Now a short description about SOL will follow to

make the reader familiar with this subject.

5.2.1. SOL. Specification and Description Language

The specifications of the MTP are described as state transition diagrams

according to the Specification and Description Language ( SOL) of the CCITT.

le~9m~)output

1.

) '~9mallInput I

2.D="u&

3.

)Imem~Input

4.

EJE)5. 6. 7.

Figure 5.1. SOL symbols

32

Some of the elements used in SDL are shown in figure 5.1. and listed below.

1. External outputs are used for interactions with different functional

blocks ( Le. other state transition diagrams ). The output signal can

be a control flow as well as a data flow. SDL does not distinguish

between control flows and data flows as Hatley & Pirbhai do. Hatley &

Pirbhai allow also state transition diagrams, but only with ingoing and

outgoing control flows.

2. Like external outputs, external Inputs are also used for interactions

with other functional blocks.

3. Internal outputs are used for interactions within a functional block,

e.g. an internal timer.

4. Internal Inputs have the same functions as the internal outputs.

5. Test-symbols choose one out of two possibilities ( Le. true or false ),

depending on the result of a test.

6. Action-blocks contain some kind of action that has to be taken, e.g.

a variable assignment.

7. The state-symbol represents a state. When in this state a particular

input ( external or internal ) arrives a transition to another state takes

place. Between two states it is possible to pertorm some actions

and/or tests.

Figure 5.2. shows an arbitrary example of a part of a SDL-diagram. The explanation

is listed below.

State 51 is the initial state. On Input the test will be pertormed. If the test

result is false a transition to state 51 follows. If the test result is true, the Action will

be pertormed and Output will be sent. The transition to state 52 will compete this

step.

Knowing that this brief description of CCITIs Specification and Description

Language does not cover all its functions and purposes, nothing more will be said

about it.

33

Figure 5.2. Example of SDL-diagram

5.3. Structural description of MTPs level 2

5.3.1. Division of the MTP Into functional blocks

Because of the complexity of the signalling system and its levels, the CCITT

described a division of the MTP level 2 into functional blocks. Together these

blocks take care of the signalling link functions which are stated below:

signal unit delimitation.

signal unit alignment.

error detection.

error correction.

initial alignment.

signalling link error monitoring.

flow control.

The interaction between the functional blocks is shown in figure 5.3.

All these functions, described earlier in this report, are coordinated by the Link

State Control part ( LSC ). This function provides instructions to the other signalling

link functions.

34

The partition into functional blocks as shown in figure 5.3. is very simple. It is

not clear which specific signals flow between the functional blocks. Therefore a

more detailed partition, shown in figure 5.4., has been made.

SignallinQ link control,

11.....121

MSUII

+----lSSU" R.ceptton

"'''----. ~+----

-- .. I I +Signall.1"Ig:

I I Error

network link 1tate I ICong"tlon I' detection Tranlminea SignallingI control I delimlnatlon ,nd r'cei~ data link

funC1iOM control DIrt I DIrt I ,nd bin II.....' 1111.....131 1--- I I alignment~ ~

I

----0 SU"

1+---- ~

TransmiSSion

RetrIeved MSU al "'''MSU aJ 1+----

con KDeI

MSU Mlneql Ilgnat unIt

SU Stgnal unitLSSU Link uatul ~lgn.1 units

- SignaUinv melllg, flow._ _ _ _ _ COnlr011J and indlCltlon,

Figure 5.3. Interactions of functional blocks

This partition will be used as a basis for the design of the requirements

model using ProMod. It shows ten functional blocks and the specific flows between

those blocks. As can be seen, no difference is made between data flows and

control flows. However, ProMod requires a distinction between those kind of

signals. The choice which flows are control flows or data flows will be explained in

the next sections. A brief description of the functional blocks is listed below.

The Link State Control ( LSC ) provides instructions to the other

functional blocks.

The Initial Alignment Control ( lAC) is appropriate to both first time

initialization and alignment in association with restoration after a link

failure.

35

,-__-==t:==-__....., F,ql.l'~ 11"0 70J~ lqur" 11 a.703

ux...

R"" ... ~BSNT

~~~~ISU ~Aceo,"MSU/F1SU l;l ]511ft ~

StOP

O"II"II(llIIon. ,I'gnment.nd tHO' drtee::lronIrec.lll'lnql

Se, T j to TieStlrtS'OP

SU } II:0

,n .nor ...<

Abott prOYlnG 0

...Z

'"..~ ...-g l-~ f

I

".-nOtf procltUOf Irecovered II:

Remot. proc,"orOU'OOOStepLOCiI orOCfUOrrfCo....r!ld

PrOClilOf'Loc.l orOCfPOl'ou'OI/Oou_ control

NoorOC.SlOrOU'OI/O F9'ro 10/0.703

Corrf'Cl SUSU In trror

n.2' 2'«

FSNT ....Iue

NACI( to Df sentFSNX .... IueBSNR ond BIBRSIB ffCt.yed

LSC r SI'"l Stop

Recommend.ll0n Q.7G4

lInk It.t, conUol

T"nsmtUlon control

F1VU" 13/0.703Fil)l.Ht 15/0.703

Orhmllatu:lM.•1IgntTlrnt"nd rrrOf detectIonltr.nll"ltllng)

ccm -It

Abbr~viated message names have been used in this diagram (i.e. origin - destination codes are omilled).

See the abbreviallons and timers used in this figure in § 12.

NOI~ 1

No/~ :;

Figure 5.4. Functional block diagram of level 2

36

The Congestion Control part ( CC ) takes care of the flow control

during congestion conditions.

Transmission and retransmission of level 3 messages is handled by

the Transmission Control (TXC ).

The reception of messages is handled by the Reception Control part

(RC ).

Delimitation, Alignment and Error Detection ( transm. ) ( DAEDT )

generates the check bits that are needed by the error detection

function. It also inserts zeros when needed ( this process is called

zero-bit insertion ) and it adds the flag-patterns to the messages that

have to be transmitted.

Delimitation, Alignment and Error Detection ( recelv. ) ( DAEDR )

removes the flags and the inserted zeros. It also checks the incoming

message on errors.

The Signal Unit Error Rate Monitor ( SUERM ) monitors the error

rate of the signalling link when it's in service.

The Alignment Error Rate Monitor ( AERM ) monitors the error rate

during alignment of the link.

The Processor Outage Control deals with local and/or remote

processor outage ( a processor outage situation occurs when, due to

factors at a functional level higher than level 2, use of the link is

precluded ).

All these functional blocks are specified as state transition diagrams in the Blue

Books, recommendation Q.703.

The next sections describe the partition of level 2 of the MTP using the

CASE-tool ProMod.

5.3.2. First level partitioning

In the previous section a division of the MTP level 2 was shown. This

partition will be used during the design of the requirements model because it is a

functional partition that is clear and easy to understand.

37

During the design of the requirements model the first step to be made was

defining the context diagram. This diagram contains a single process, which

represents level 2 of the Message Transfer Part, and a number of terminators. The

terminators represent the connections of level 2 with the outer world. The context

diagram ( Le. the Context Data Flow Diagram ( DFD ) as well as the Context

Control Flow Diagram ( CFD ) ) is shown in annex A.

According to the method of Hatley & Pirbhai this process must be split up

into smaller ( sub) processes. During this process of splitting, a number of factors

were taken into account, such as:

the splitting has to be logical as well as functional,

the resulting pictures need to be clear, and

only the important things have to be shown.

Splitting the context diagram process results in DFD1 and CFD1, shown in

annex B. These FDs contain three processes. The first one takes care of the

control of the link and its alignment. Process no. 2 handles the transmission and

retransmission of signal units that have to be transmitted. Process no. 3 deals with

reception of signal units. For a more detailed description of all the processes, see

[Dreumel, 1991].

5.3.3. Lower level partitioning

The partitioning of processes is continued until the processes are equal to

the functional blocks which were described in section 5.3.1. The next thing to do is

split these processes into smaller ( sub ) processes until a number of processes

exist that are easy to describe in an unambiguous way, so called primitive proces­

ses. This further splitting is done on a functional base, resulting in the requirements

model shown in [Dreumel, 1991]. This model represents the MTP level 2.

The next sections discuss the choices that were made during the design

process using ProMod.

38

5.4. Functional description of MTPs level 2

This section discusses the choices that were made during the design of the

requirements model. It describes the way in which the elements according to the

method of Hatley & Pirbhai should be interpreted.

5.4.1. Flows

Figure 5.4. makes no difference between data flows and control flows.

Because of the fact that ProMod, as well as Hatley & Pirbhai, do distinguish

between these flows, a choice had to be made: which flows should be marked as

data flows and which as control flows? The solution is as follows. All the flows that

represent real data ( Le. bits, signal units, messages, numbers: flows with values

that are different all the time ) are marked as data flows. The remaining flows (

values that are one of a few, e.g. start or stop) that are used to control functional

blocks are marked as control flows.

As can be seen in [Dreumel, 1991] the majority of the flows are control

flows. This is not very surprising because Signalling System No. 7 is a system that

'controls' the transfer of messages.

The choice to mark the flows in the way described in [Dreumel, 1991] is the

choice of the system analyst. It is not the one and only solution, but I find it clear

and functional.

5.4.2. Processes

Most of the processes described in [Dreumel, 1991] are not primitive

processes. The descriptions of their functions, the Mini Specifications ( MSP ), are

written in English and easy to understand. The primitive processes however are

described in so-called Structured English ( e.g. IF-THEN statements ). This results

in a number of descriptions that are clear and unambiguous. Figure 5.5. shows an

example of a description of a primitive process.

39

The last thing to be said about the processes is that some of them are

triggered by a CSP-bar ( see section 5.4.3. ) and some of them are triggered by

incoming data ( e.g. an incoming bit stream ).

REPEAT

IF >Proces_control - Start THEN ·Start proces·

ELSE IF >Proce8_control - Stop THEN ·Stop proces" AND

·Reset all the stores·

ELSE IF >StarLtimer THEN ·Start the timer" AND

<1lmecstatus - Started

FOREVER

Figure 5.5. Example of Mini Specification

5.4.3. eSP-bars

At first sight it looks easy to translate the SOL-specifications, in the form of

state transition diagrams, into CSPEC-bars, which can be defined as state transition

diagrams too. However there is one difference between the two methods mentio­

ned. The SOL-specifications do not distinguish between data flows and control

flows as the CSP-bar does. So the SOL-diagrams had to be split into a data flow

part and a control flow part. The first part should be defined using processes ( Le.

primitive as well as non-primitive processes ) as discussed in the previous section.

The second part should be defined as state transition diagrams ( CSP-bars ). Now

the layout of these CSP-bars is discussed.

When in a certain state, a transition to another state takes place as some

particular input ( or inputs ) arrives. This input can be a control flow as well as

40

some test result. During a transition it is possible to perform some actions. The

notation that is used in the control specifications in [Dreumel, 1991] is as follows.

STATE name of state:IF input1 LOG OP

input2 LOG=OP

THEN output1/action1,output2/action2,

GOTO name of state;IF

THEN

GOTO name of state.

This notation should be interpreted as follows:

name of state is the name that represents a particular state. In the

notation above it is possible that the three name of state fields repre­

sent three different states.

input can be an incoming control flow or a test result. In case of an

incoming flow it is preceded by a '>' mark. When it is a test result it is

placed between quote marks ( ''test result" ).

LOG_OP is the logical operator AND or OR. When there is only one

input then this LOG_OP is not needed.

output/action means that an outgoing control flow may be sent as

well as an action may be performed. In case of an output flow it is

preceded by a •<' mark. An action is placed between quote marks.

the IF-THEN-GOTO statements are obvious. When the IF condition is

true then some outputs are sent and some actions performed. Next

step is the GOTO jump to another or the same state.

For clearity an example is placed in figure 5.6.

41

STATE Idle:

IF >control - Start AND

"atatu.-.tore - lnacdve"THEN <proceturtarted,

"status-store :- active".

GOTO In_service:

IF >control - Stop AND

"atatus-store - adlve"THEN <prooe8_halted.

"status-store :- Inactive",

GOTO Idle.

STATE In_service:

IF etc.

Figure 5.6. Example of Control Specification

5.4.4. Stores

It is decided that every store that is used in the requirements model is

controlled by one process, a store-control process. This process and the store it

controls appear in the highest level flow diagram where the store is used for the

first time. Whenever the store is used at a lower level, it is not shown in the

accessory flow diagrams. Every time a process or a CSP-bar wants to use the

store to perform a read or write action, the store-control process takes care.

5.4.5. Terminators

There is not much to be said about the terminators. They are defined in the

context diagram ( top level ) and represent the connections between level 2 of the

Message Transfer Part ( MTP ) and the outer world. In this case the outer world

exists of the levels of the MTP that surround level 2, Le. levels 1 and 3. These levels

were briefly described earlier in this report. A third terminator represents the

management of the signalling system. This part does not only manage level two but

also the other levels although this can not be concluded from the context diagram.

42

6. CONCLUSIONS AND RECOMMENDATIONS

With the CASE-tool ProMod [PreMod, 1989] a requirements model of level 2

of the Message Transfer Part ( MTP ) has been developed [Dreumel, 1991] using

the formal method of Hatley & Pirbhai [Hatley, 1987]. Starting point was the

specification of the MTPs level 2 as is described in recommendations Q.703

[CCITT, 1989] ( Blue Books ). The requirements model satisfies this specification

completely. ProMod does not detect any errors, so the model is assumed to be

correct.

ProMod appeared to be very helpful in the development of the requirements

model. Disadvantageous was the fact that the tool runs very slow when the system

that has to be developed is very large. There SS7 is a very complicated and

extensive system, the limits of ProMod could be reached and some problems may

arise in the future.

Before level 2 of the MTP may be implemented, the requirements model

must be transformed into an architecture model and a suitable programming

environment must be chosen. After implementation of level 2, a structured analysis

and implementation of MTPs level 3 are still to be done. After that, the transport

mechanism of SS7 ( Le. the MTP ) is finished. The remaining parts of SS7, such as

the Signalling Connection Control Part and the User Parts, should be analyzed and

implemented in the way that is described in this report.

43

REFERENCES

CCITT.

SPECIFICATIONS OF SIGNALLING SYSTEM NO.7.

vol. 6.7. recommendations 0.700-0.716,

vol. 6.8. recommendations 0.721-0.766,

vol. 6.9. recommendations Q.771-0.795,

Geneva, 1989 ( Blue Books ).

Dreumel, I.W.J. van

REOUIREMENTS MODEL FOR LEVEL 2 OF THE MESSAGE TRANSFER PART

PART 2: PROMOD SA-REPORT.

Eindhoven University of Technology, Department of Electrical Engineering,

Digital Systems Group, May 1991.

Hatley, D.J. and Pirbhai I.A.

STRATEGIES FOR REAL-TIME SYSTEM SPECIFICATION.

New York, Dorset House, 1987.

Ligtenberg, M.F.J.

SOFTWARE DESIGN FOR THE CONTROL SYSTEM OF A DIGITAL TELEPHONE

EXCHANGE.

Eindhoven University of Technology, Department of Electrical Engineering,

Digital Systems Group, August 1990.

Master thesis report, TUE-EB271.

ProMod

COMPUTER AIDED SOFTWARE ENGINEERING USERS MANUAL.

Aachen GEl, July 1989.

44

Ronayne, J.P.

INTRODUCTION TO DIGITAL COMMUNICATIONS SWITCHING.

London, Pitman Publishing Ltd., 1986.

Verhoof, P.H.W.

REQUIREMENTS MODEL FOR THE CONTROL SYSTEM OF A DIGITAL TELE­

PHONE EXCHANGE.

Eindhoven University of Technology, Department of Electrical Engineering,

Digital Systems Group, February 1990.

Master thesis report, TUE-EB232.

Ward, P.T. and Mellor, S.J.

STRUCTURED DEVELOPMENT FOR REAL-TIME SYSTEMS.

Vol. 1-3.

New York, Yourdon Press, 1985.

Yourdon, E and Constantine, L

STRUCTURED DESIGN: FUNDAMENTALS OF A DISCIPLINE OF COMPUTER

PROGRAM AND SYSTEMS DESIGN.

New York, Yourdon, 1978 ( 1st edition: 1975 ).

45

BIB

BSN

CAS

CASE

CCS

CCITT

FIB

FISU

FSN

LSSU

MSU

MTP

SCCP

SIB

SIE

SIN

SIO

SIOS

SIPO

SP

SS7

STP

UP

ABBREVIATIONS

= Backward Indicator Bit.

= Backward Sequence Number.

= Channel Associated Signalling.

= Computer Aided Software Engineering.

= Common Channel Signalling.

= International Telegraph and Telephone Consultative Committee.

= Forward Indicator Bit.

= Fill-In Signal Unit.

= Forward Sequence Number.

= Link Status Signal Unit.

= Message Signal Unit.

= Message Transfer Part.

= Signalling Connection Control Part.

= Status Indication 'busy'.

= Status Indication 'emergency'.

= Status Indication 'normal'.

= Status Indication 'out of alignment'.

= Status Indication 'out of service'.

= Status Indication 'processor outage'.

= Signalling Point.

= Signalling System NO.7.

= Signal Transfer Point.

= User Part.

46

ANNEX A:

CONTEXT DIAGRAMS LEVEL 0

47

Messa e f

re uest

BSNT

Rece! vedJllessage

Retr ieyedJllessages

Manage~ent

Bits_for transmission

Receiyed....bits

LEVEL.

PROJECT:

oMTP~2

S S 7 Me s sag e _ T ran s fer

LAST UPDATE:

LAST ANALYSIS:

Par t

04-APR-!991 10: 52

02-MAY-1991 OB: 49

Management

Llnksongest lon_status".".,------..., Power 1

/ "- _on IRemote...processor~tatus \ I Level_3

/ - - -- - -.... / _fallure/'Retr I eyal_colp Jete ,'8/ I

/ / - -- --- -~ II __Servi~e~at~ '-: -- -

-.... -:::; MTPMTP ~er~cy _con tro J MTPLeve 1_3 - - - - >( Level..) Leyel_1-.... ;p\ .!

"- -.... LSC_controJ --- - - -- -'- I /-.... Retr ieve_BSN r - -" - - -- I"- Local...processor_status ./-.... - ---- -

S S 7 - M e s sag e _Trans f e r _ Par t

LEVEL: 0 ILAST UPDATE: 04-APR-!991 10: 52

PROJECT: MTP~2 ILAST ANAL YSIS: 02-MAY-!99! OB: 49

48

PROBLEM_DESCRIPTION SS?_Message_Transfer_Part

The context is the Message Transfer Part ( MTP ), used within Signalling

System No. ? ( SS? ). The MTP provides the functions that enables information,

that is important for user parts, passed to the MTP to be transferred across the

SS? signalling network in signal units ( SUs ) to the required destination. Mechan­

isms are provided in the MTP to ensure SUs are received in the correct sequence,

any errors detected, and, if required, messages retransmitted. In addition, further

procedures ensure that the impact of network or system failures have minimal

effect on the ability of the MTP to transfer SUs.

The MTP consists of three levels ( Level 1-3 ). The functions performed by

the MTP are specified in terms of the level in which they are located.

49

ANNEX B:

FLOW DIAGRAMS LEVEL 1

50

Retr leva l.reQuestand FSNC

Mr.ssage for t raoCjmi 55 i on

~ved essa es

Retr leva l...request ~ndJSNC.recel ved

FSNT_value

~cel vedJllessage

BSNT--------MT P Level _ 2

Recelvedj>its

LEVEl. LAST UPDATE: 29-APR-1991 OB: 59

PROJECT: MTP .../.2 LAST ANALYSIS: 02-MAY-1991 OB: 49

TXCJ:ontrol--....

Aetr Ievaliomp lete

,L.ini_congest ion_status

, , ,"- NACK \"- _to send SIB, "- j>e _SIB I .recel ved )

"- \. _sent I"- \. \ / /

"- /, "- \ I" /

--- , \I"- ,,-"- \ /

--- "- ,,\ /--- ,"

'-..

MT P Lev e

LInk failure RC_---:---

_Signal_u!0. t.r~cei!:d

---

Status_ind icatlon_IAC- -- - - - -

S~tus.-l!2>l i c.!!.iO~LSC./

Send"'processor _status_ind Ic atlon---------Send_a I ign~t~at!:!!._in_chcat~n

I I ,/' -- Send_slgnalJjnit

I -------~

I I /

\ \ 1/\ \ \ ,

/

~ergency :::.ontro J

Local...processo r~ta~ _

~tri~e_~NT

LSC_control

Leve 1_3_fai lure

~wer"'pn

/

Remote "'processor_status~-

Service status.. --- -

LEVEL: LAST UPDATE: 29-APR-1991 OB: 59

PROJECT" MTP .../.2 LAST ANALYSIS: 02-MAY-1991 OB: 49

51

MSP 1 MTP Level 2

The MTP level 2 comprises functions which facilitate the reliable transfer of

messages over a single signalling link. These functions, called the 'signalling link

functions', are:

- signal unit delimitation,

- signal unit alignment,

- error detection,

- error correction,

- initial alignment,

- signalling link error monitoring,

- flow control.

These functions ensure that messages are delivered in the correct order, and

without loss or duplication, on a link having line error rates up to a specified limit.

Error rates higher than this specified limit cause the link to fail.

The MTP_Level_2 is split into three main processes:

1. ControUink_and_alignment: controls all actions to be taken.

2. Transmit_messages: takes care of transmission and retransmission of

messages.

3. Receive messages: takes care of reception of messages.

52

ANNEX C:

HOW TO PRINT FDs USING THE LASER PRINTER

53

The pictures shown in the previous annex A and B were generated using the

HP Laserjet Plus. In this annex this possibility will be discussed.

ProMod supports two devices to show graphical representations on a piece

of paper. The first one is an IBM graphics printer, the second one is a plotter that is

able to plot so-called HPGL-files. With use of the program LP.exe ( Laser Plotter 1.2

for the HP Laserjet by Insight Development Corp. ) it is possible to print ProMods

plotter-files ( HPGL-format ) using a laser printer. This results in pictures like those

that were showed in annex A and B.

It is easy to create such HPGL-files with PreMod. Just select the Output-field

when the flow diagram you want to print is retrieved. Next field to select is the Plot­

field. A HPGL-file of the flow diagram will be created. This file is ready to be printed.

All you have to do is run LP.exe. This program is easy to understand, so nothing

more will be said about it.

54