SS7

THE SIGNALLING SYSTEM Nº 7

AND ITS APPLICATIONS

José Velez

BU NET DS22SIEMENS S.A. (PORTUGAL)

José Velez, SIEMENS SA – BU NET DS221


1. INTRODUCTION.......................................................................................................................... 4

2. THE SIGNALING SYSTEMS...................................................................................................... 5

2.1. THE DEVELOPMENT OF THE SIGNALING SYSTEMS ..................................................................... 52.2. SOME NOTES ON OSI ARCHITECTURE ....................................................................................... 5

3. THE Nº 7 SIGNALING SYSTEM................................................................................................ 8

3.1. THE SIGNALING NETWORK........................................................................................................ 83.2. THE STRUCTURE OF THE SS#7 PROTOCOLS............................................................................... 93.3. MTP (MESSAGE TRANSFER PART) ......................................................................................... 12

3.3.1. MTP: physical sublevel .................................................................................................. 123.3.2. MTP: signaling link control sub-level............................................................................ 123.3.3. MTP: network sub-level ................................................................................................. 13

3.4. SCCP (SIGNALING CONNECTION CONTROL PART)................................................................. 163.4.1. SCCP: message structure............................................................................................... 163.4.2. SCCP: addressing .......................................................................................................... 19

3.5. TCAP (TRANSACTION CAPABILITIES APPLICATION PART)..................................................... 243.5.1. “Bearer related” connections versus “bearer unrelated” connections ........................ 243.5.2. Characterization of the TCAP........................................................................................ 243.5.3. Structure of the TCAP messages .................................................................................... 253.5.4. A specific application example: the CCBS..................................................................... 273.5.5. The encoding of TCAP messages ................................................................................... 28

3.6. ASN.1 NOTATION (ABSTRACT SYNTAX NOTATION NO.1)...................................................... 303.6.1. Abstract syntax............................................................................................................... 303.6.2. Transfer syntax............................................................................................................... 363.6.3. Practical use .................................................................................................................. 39

4. USERS OF SS#7........................................................................................................................... 44

4.1. ISS (ISDN SUPPLEMENTARY SERVICES) ................................................................................ 444.2. INAP (INTELLIGENT NETWORKS APPLICATION PART) ........................................................... 464.3. MAP (MOBILE APPLICATION PART)....................................................................................... 484.4. CAP (CAMEL APPLICATION PART) ...................................................................................... 50

5. LIST OF ACRONYMS ............................................................................................................... 51

6. BIBLIOGRAPHY........................................................................................................................ 53

6.1. ITU-T RECOMMENDATIONS ................................................................................................... 536.2. OTHER DOCUMENTS................................................................................................................ 53

7. APPENDICES.............................................................................................................................. 54

7.1. APPENDIX 1: ASN.1 MODULES............................................................................................... 547.1.1. Definition of TCAP messages (standard)....................................................................... 547.1.2. Definition of the BCAP operations (SIEMENS specific)................................................ 577.1.3. Definition of the MWI service - Message Waiting Indication (standard) ...................... 60

7.2. APPENDIX 2: SCCP/TCAP DATABASE (EWSD SYSTEM) ....................................................... 64


Figures

Figure 1: Common channel signaling ........................................................................................ 5Figure 2: Application Level. Generic ASEs................................................................................ 7Figure 3: Association modes...................................................................................................... 8Figure 4: SS#7 protocols stack.................................................................................................. 9Figure 5: MTP levels ................................................................................................................ 12Figure 6: MTP frames .............................................................................................................. 12Figure 7: MTP – SIO field ........................................................................................................ 13Figure 8: MTP – SIF fields ....................................................................................................... 14Figure 9: Structure of an SPC.................................................................................................. 15Figure 10: Basic structure of the SCCP messages ................................................................. 16Figure 11: SCCP, format of the mandatory fixed part.............................................................. 16Figure 12: SCCP, format of the mandatory variable part ........................................................ 17Figure 13: SCCP, format of the optional part........................................................................... 17Figure 14: SCCP, addresses format........................................................................................ 20Figure 15: SCCP, UDT message............................................................................................. 21Figure 16: SCCP, coding of the field “address indicator” ........................................................ 21Figure 17: SCCP, coding of the field “global title indicator” ..................................................... 21Figure 18: SCCP, coding of the field “numbering plan” ........................................................... 22Figure 19: SCCP, coding of the field “encoding scheme”........................................................ 22Figure 20: SCCP, coding of the field “translation type”............................................................ 22Figure 21: Flow of the CCBS service....................................................................................... 27Figure 22: TLV sequence......................................................................................................... 36Figure 23: Tag coding (if less than 30) ................................................................................... 36Figure 24: Tag coding for values higher than 30 ..................................................................... 37

Tables

Table 1: MTP – SIO fields........................................................................................................ 14Table 2: SCCP message types................................................................................................ 18Table 3: Optional SCCP parameters ...................................................................................... 19Table 4: SSNs currently specified............................................................................................ 19Table 5: Class of operation in the TCAP ................................................................................. 26Table 6: Class coding .............................................................................................................. 37Table 7: Type coding (P/C bit) ................................................................................................. 37Table 8: Codes allocated to Universal-type classes................................................................ 38


1. Introduction

Particularly in applications developed during recent years and based on concepts such astransaction or association, No. 7 signaling has frequently been a factor that has causedconfusion. These concepts have been assuming a major role in applications developed in thelast few years, both within the area of additional services for the traditional fixed network andin areas as diverse as Intelligent Networks (IN), mobile networks and, more recently, servicesoriented towards the Internet.This document does not set out to be a treatise on these matters, rather it seeks simply to bean aid to those wishing to develop applications in this area, or merely to acquire a knowledgeof it.Caveat: this document was originally aimed at colleagues who are collaborating or who will becollaborating in the DS2 2 work-group (Siemens Portugal), so special emphasis is given tothe aspects most relevant to the work carried out there.

This document has been structured in the following way:

It begins by stating certain basic aspects of the signaling systems, moving on quickly to thestructure of No. 7 signaling (SS#7); there then follows a description of the standard languageASN.1 (Abstract Syntax Notation nº 1), as this is a pre-requisite for understanding theapplications. After this some aspects associated with the level of application are described,namely in the area of ISDN, Intelligent Networks and GSM. It ends with the inclusion of someappendices which are particularly useful for those currently working in this area.

Alfragide, September 1999

José V

2. The signaling systems

2.1. The development of the signaling systemsThe signaling network is the nervous system of any modern telecommunications system.It is present both in the access network (“subscriber signaling”, as the DSS1 used in ISDN),and in the connection of the network nodes (“trunk signaling”).It makes no sense to describe here the development of the signaling systems from the firsttelephone networks created more than one hundred years ago, but it is important to state thatall modern signaling systems are of the “out of band” type, that is, signaling is carried via thenetwork on dedicated channels (“signaling channels”), logically independent of the channelsfor carrying voice/data (“bearer channels”).

These systems, known as common channel signaling, enable not only faster transmission ofinformation, but they also have the additional advantage of enabling the establishment ofsignaling links, without previously occupying a voice channel. Being out of band systems, theyare obliged to carry out an advance check of the continuity of the voice channel (“cross-officecheck”).

Figure

In the“CommnametransmMeanknowncommpackeThe mwhichwith itMore types

2.

A lessidentifApplicused b

A B
Exchange
elez, SIEMENS SA – BU NET DS22

1: Common channel signaling

early 1970s, AT&T developed a common mode channel son Channel Interoffice Signaling”, subsequently standardize

“No. 6 Signaling System”. This system used 336-bit fraitted on analog lines at 200 bps using PSK modulation.

while, with the development of the open system concept, and o OSI levels (in parallel with packet networks based on HDLConplace), in the early eighties the ITU defined a new digital sigts, the “No. 7 Signaling System” (SS#7 for short).ain virtue of this system is the fact that that it has been desi

although not strictly following the OSI structure are, up to a c.important still: it has been divided into various “parts” which enaof connection. But we will be moving on to this later ….

2. Some notes on OSI architecture

well-known aspect of OSI architecture, beyond the well knoication of certain functional blocks in level 7 (Application). Theration Service Element (ASE) is defined as a sub-application y other applications.

s

Voice/data channels

Exchange

Signaling c hannel

5

ignaling system, calledd by the ITU with themes (?!..) which were

riginating from the well- type frames becomingnaling system based on

gned with several levelsertain point, compatible

ble it to support several

w level definition, is theefore the concept of thein level 7 which can be



This definition can be better illustrated by taking as an example a generic client-serverapplication: for the client, it is necessary to have functions that establish access to the server(establishing a connection/ association) as well as functions for interrogating its database(remote operations); in the server we’ll certainly have dedicated functions for transfer/ filemanagement, etc. The point to be emphasized is that all these functions will, in principle, beaccessible to the different applications that run on both platforms.The functions referred to quite rightly constitute the generic ASEs identified in level 7 of theOSI architecture, as follows:

ACSE (Association Control Service Element) – This defines the communication and dialogprimitives for establishing and terminating an association between remote applications.One example: let us suppose that we are trying to implement software for a TELNET likeapplication; the combination of routines responsible for controlling the association betweenthe terminal and the host constitute the ACSE.

ROSE (Remote Operations Service Element) – This defines the primitives, dialogs and statemachine for the carrying out of remote operations. The TCAP (which we will discuss later) isan example of implementation partially aligned with the ROSE.

RTSE (Robust Transfer Service Element) – This ASE defines the primitives and the dialogsfor secure data transfer between remote applications. A specific example of a RTSE is theFTAM system (IBM).

Figure 2: Application Level. Generic ASEs

Two additional notes on the OSI nomenclature:

• Basic operations (messages) exchanged between adjacent levels or between equivalentlevels between two remote points (peer levels) are designated as communicationprimitives. Examples of primitives are CONNECT, RELEASE, DATA, UNITDATA, etc.

• Blocks of information exchanged at protocol level are designated as Primitive Data Units(PDUs). When information is exchanged between the application and the lower levelsthey are designated as Application Protocol Data Units (APDUs).

Presentation Level (6)

Session Level (5)

Transport Level (4)

Network Level(3)

Data Link Level (2)

Physical Level( )

Application Level (7)

Application X Application Y

ROSEACSE RTSE

Presentation Level (6)

Session Level (5)

Transport Level (4)

Network Level( )

Data Link Level (2)

Physical Level( )

Application Level (7)

Application X Application Y

ROSEACSE RTSE

Protocols

José Velez, S

3. The Nº 7 Signaling System

3.1. The signaling network

In the terminology used in Common Channel networks and particularly in the SS#7, thefollowing network elements may be noted:

SP (Signaling Point) – Network node identified by an address (SPC-Signaling Point Code),which is always the origin or destination of signaling messages.

STP (Signaling Transfer Point) – Dedicated network node (also identified as an SPC) forsignaling message routing tasks, characterized by a high speed/capacity processing. May ormay not be the origin or destination of messages.

In SS#7, we designate as “mode of association” the relationship between the physicalconnection and the logical connection between SPs as follows:

Associated mode: signaling is carried out directly between SPs.

Quasi-associated mode: signaling between two SPs is carried out via one or more STPs,according to an initially defined fixed path.

Figure 3: Ass

(There is a thithe routing ma

A B

STP

Exchange

IEMENS SA – BU NET DS22

ociation modes

rd mode not supported by SS#7, designated as non-associatedy vary dynamically in an adaptive form, depending on the traffic

Signaling

Voice/data

SP

STP

Voice/data

g

Associated Mode

Quasi-Associated Mode

Exchange

SP

Exchange C

Signalin

8

mode in which).

SP


3.2. The structure of the SS#7 protocols

The structure of the SS#7 protocols in their initial form contained only three functional blocksknown as “parts”. The first covered the functions corresponding with the three basic OSIlevels (Physical, Data Link and Network) and the two remaining blocks, somehowequivalents to levels 4 and 7 (Transport and Application), incorporated the networkapplications existing at the time. They were the TUP (Telephone User Part) for telephone CallControl, and the DUP (Data User Part), for switched data networks.

With the appearance of ISDN and all subsequent developments in the telecommunications,new “parts” were defined until we get today’s architecture, illustrated here:

Figure 4: SS#7 protocols stack

Below is a brief description of the acronyms:

MTP (Message Transfer Part) – this includes functions till level 3 OSI. It provides aconnectionless transport mechanism between SPs in the network.

TUP (Telephone User Part) – this includes the Call Control functions for basic telephony.

ISUP (ISDN User Part) – this supports combined voice, data and video services. It is thecounterpoint in the network to ISDN’s subscriber signaling, the DSS1.

SCCP (Signaling Connection Control Part) – this completes the level 3 OSI, expanding theaddressing capabilities of the MTP and providing connectionless and connection orientedservices.

TCAP (Transaction Capabilities Application Part or TC for short) – provides support for realtime applications that involve interrogation-reply processes between SPs.It is a fundamental support for all modern applications in the area of Intelligent Networks,Mobile Networks, Network Management, etc.

INAP (Intelligent Networks Application Part) – user of the TCAP, defines the communicationprotocol between the SSP and the SCP in an Intelligent Network architecture.

MAP (Mobile Application Part) – user of the TCAP, provides support for communicationbetween the databases of the mobile networks, namely in the GSM system.

MTP

SCCP (Level 3 OSI)

TCAP (Level 7 OSI)

TUPISUP

INAP MAP OAMP ISS CAP


OAMP (Operation, Administration and Maintenance Part) – user of the TCAP, providessupport for communication networks management. Sometimes, also designated as OMAP.

In addition there are the following users of the TCAP who are not referred to explicitly in thestandard structure of the SS#7:

ISS (ISDN Supplementary Services) – supports several supplementary services for ISDN,namely the CCBS (Call Completion to Busy Subscriber) and the CCNR (Call Completion onNo Reply).

CAP (CAMEL Application Part) – provides support for the implementation of the I.N. in themobile networks, designated as CAMEL (Customized Application for Mobile Enhanced Logic).The CAP itself uses a part of the INAP and defines new operations for specific use in mobilenetworks. The INAP is expected to evolve in the direction of incorporating CAMEL.

Some of these functional blocks will be described in greater detail in the following chapters,with special emphasis being given to the MTP-SCCP-TCAP sequence and respective usersINAP, ISS, etc.



3.3. MTP (Message Transfer Part)

The MTP provides functions that are equivalent to the first three OSI levels (Physical, DataLink and Network) and its internal structure coincides exactly with this division:

Figure 5: MTP levels

The main features of these three levels are described briefly below:

3.3.1. MTP: physical sublevel

The physical sublevel of the MTP is refined as a full-duplex channel with the followingfeatures:

• Standard binary output = 64 KBPS

• Maximum bit error rate = 10E-6

• In the European system it occupies slot 16 in the 2048 KBPS PCM links

3.3.2. MTP: signaling link control sub-level

This sub-level is equivalent to level 2 OSI (Data Link). The transfer of information is carriedout via HDLC type frames and as such the frames are signaled by flags filled 01111110; thetechnique of “bit stuffing” is used to avoid the accidental appearance of this pattern in theframe and the polynomial used for calculating the FCS is CRC-16.

The frames do not contain address fields (addressing is carried out by the upper level, thenetwork level) and there are three types only, differentiated by the content of the user part,which are the following:

Figure 6: MTP frames

flag BSN BIB FSN FIB LI spare CRC

flag BSN BIB FSN FIB LI spare STATUS CRC

flag BSN BIB FSN FIB LI spare SIO CRCSIF

FISU

LSSU

MSU

MTP - Level 1 (physical)

MTP - Level 2 (data link)

MTP - Level 3 (network)


Key:

flag synchronization flag, 01111110 8 bitsBSN Backward Sequence Number 7 bitsBIB Backward Indicator Bit 1 bitFSN Forward Sequence Number 7 bitsFIB Forward Indicator Bit 1 bitLI Length Indicator 6 bitsspare bits spare 2 bitsSTATUS Link status 8 or 16 bitsSIO Service Information Octet 8 bitsSIF Signaling Information Field (User data) up to 272 bytesCRC Cyclic Redundancy Check 16 bits

• MSU (Message Signal Unit): transports useful information to the upper levels.

• LSSU (Link Status Signal Unit): transports information relating to the link status, forinternal use by the MTP.

• FISU (Fill-in Signal Unit): intended only to occupy the link in the absence of otherinformation (enables a shorter time of synchronism acquisition).

3.3.3. MTP: network sub-level

The network sub-level provides support for transmitting signaling messages between SPs orSTPs in the network. It is transported in the user part of the MSU frames (consisting of theSIO and SIF fields), and contains addressing information in the network. In SS#7 terminologythe frames at this level are known as “messages”.

We shall not analyze here the content of all the fields but it is important to understand thecontent of the SIO and SIF fields -> “routing label”:

The SIO field (Service Information Octet) consists of a byte that contains the identification ofthe message user (the user part of the message). It is defined as follows:

Figure 7: MTP – SIO field

flag BSN BIB FSN FIB LI spare SIO CRCSIFMSU

Service Indicator Subservice Field


The standardized coding of the fields “Service Indicator” and “Subservice Field” is as follows:

Service Indicator Meaning00h Network management messages01h Network testing and maintenance messages02h Not used03h SCCP04h TUP05h ISUP06h DUP (circuit related messages)07h DUP (facility registration and cancellation)08h MTP testing part09h B-ISUP (Broad band ISUP)0Ah Satellite

Subservice Field Meaning00XXb International Network01XXb Not used10XXb National Network11XXb Reserved for national use

Table 1: MTP – SIO fields

The “routing label” field contains all the information relating to the addressing of the message.We should recall that the MTP provides connectionless services which means that itsmessages are datagrams that must contain the sender’s addresses (designated in the SS#7as OPC-Originating Point Code) and those of the destination (DPC-Destination Point Code).The structure of the SIF, and more specifically that of the routing label is as follows:

Figure 8: MTP – SIF fields

As illustrated, the addresses in the MTP occupy 14 bits. These addresses are subdivided in a3-8-3 bit structure, known as the SPC (Signaling Point Code):

flag BSN BIB FSN FIB LI spare SIO CRCSIFMSU

DPC (14 bits) OPC (14 bits) SLS (4 bits)

Routing label (4 bytes) Heading code (1 byte) User part (max 267 bytes)

Zone (3 bits) Area/Network (8 bits) Signaling Point (3 bits)


Figure 9: Structure of an SPC

The coding of these fields is defined jointly by the ITU-T and by the national regulatorybodies.Some years ago, due to the need to expand the addressing possibilities of the MTP in verylarge networks e.g. the USA, a 24-bit extended format was defined by the ANSI.

Conclusion:

There is a great deal more to say about the MTP, particularly at network management level,restart procedures, etc. However, for the purposes of this document it is the topic ofaddressing itself which is very important. Therefore, by way of conclusion (and after all thesefriendly acronyms...), it should be emphasized once again that:

• The MTP addresses comprise 14 bits (ITU-T), arranged in a 3-8-3 structure known asSPC. There is a 24 bit variant (extended SPC), defined by the ANSI.

• The MTP supports connectionless connections, and therefore its messages alwayscontain the addresses of the OPC and the DPC.


3.4. SCCP (Signaling Connection Control Part)

With the developments in the dimension and complexity of telecommunications networks, itbecame clear that the MTP’s addressing scheme was inadequate. On the other hand, itbecame necessary to provide connection oriented capabilities, not supported by the MTP.

The SCCP therefore came into being as a new functional entity capable of providing networkservices to higher levels according to the OSI norm (which was meanwhile completed).

Note: there are two standard versions of the SCCP: the ANSI norm and the ITU-T norm. Thedescriptions contained in this document refer solely to the ITU-T norm.

3.4.1. SCCP: message structure

The SCCP is characterized by providing two basic services: connection oriented andconnectionless, and the messages used by these two services are structured in accordancewith the primitives of the OSI norm (see Chapter 3.2) of the type N-CONNECT_req, N-DATA_ind, etc. Mandatory and optional parameters are specified for each primitive.The SCCP messages have the following structure:

Figure 10: Basic structure of the SCCP messages

This structure has some less trivial details, so we shall make some more detailedobservations:

- The mandatory fixed part contains parameters of fixed length, depending on the type ofmessage. The identification of the fixed length parameters is implicit according to the typeof message, that is, neither identifiers nor parameter length are present.

Figure 11: SCCP, format of the mandatory fixed part.

- The mandatory variable part is more confusing as it begins with a sequence of pointers(as far as the variable length parameters defined for the message in question), containing

Routing information(4 bytes)

Message type(1 byte)

Mandatory fixed part (variable size)

Mandatory variable part(variable size)

Optional parameters(variable size)

Mandatory parameter 1

Mandatory parameter 2

...............

Mandatory parameter N


the relative distance of the parameter in relation to the pointer. The dimension of eachpointer is always one byte.

Figure 12: SCCP, format of the mandatory variable part

The optional part consists of optional parameters, each being defined as a sequence:

-Identifier of the parameter-Length-Value

The optional part terminates with one byte filled with 0s.

Figure 13: SCCP, format of the optional part

The SCCP provides four class of protocol (class 0, 1, 2, 3). Class 0 and 1 support theconnectionless service and class 2 and 3 support the connection oriented service. Insummary, we have:

Pointer to parameter A (1 byte)

Pointer to parameter B (1 byte)

.............................

Pointer to optional part

Parameter A

Parameter B

......................

OPTIONAL PART..................................

Length of optional parameter X

Optional parameter X

Length of optional parameter Y

Optional parameter Y

..........................

00 (1 byte)


• Class 0: basic connectionless service, it doesn’t provide flow control There are only twomessages for this service: UDT (Unitdata) and XUDT(Extended UDT).

• Class 1: “Connectionless Sequenced” service, based on class 1 but permittingadditionally data sequence control.

• Class 2: basic connection oriented service (control of connection establishment andrelease only).

• Class 3: additionally enables flow control, data sequence and also the use of the primitive“Expedited Data” that is, the possibility of sending datagrams with information thatovertakes the normal flow (e.g. priority information for network management).

The following tables provide useful information regarding the existing messages andcorresponding optional parameters specified for the SCCP:

Message type Class prot. CodeCONNECTION REQUEST (CR) 2 and 3 01hCONNECTION CONFIRM (CC) 2 and 3 02hCONNECTION REFUSED (CREF) 2 and 3 03hRELEASED (RLSD) 2 and 3 04hRELEASE COMPLETE (RLSD) 2 and 3 05hDATA FORM 1 (DT1) 2 06hDATA FORM 2 (DT2) 3 07hDATA ACKNOWLEDGE (AK) 3 08hUNITDATA (UDT) 1 and 2 09hUNITDATA SERVICE (UDTS) 1 and 2 0AhEXPEDITED DATA (ED) 3 0BhEXPEDITED DATA ACKNOWL. (EA) 3 0ChRESET REQUEST (RSR) 3 0DhRESET CONFIRM (RSC) 3 0EhERROR (ERR) 2 and 3 0FhINACTIVITY TEST (IT) 2 and 3 10hEXTENDED UNITDATA (XUDT) 0 and 1 11hEXT. UNITDATA SERVICE (XUDTS) 0 and 1 12h

Table 2: SCCP message types

Optional parameter CodeEnd of the optional parameters 00hDestination local reference 01hSource local reference 02hCalled party address 03hCalling party address 04hProtocol class 05hSegmentation/reassembly 06hReceive sequence number 07hSequencing/segmenting 08hCredit 09hRelease cause 0AhReturn cause 0BhReset cause 0ChError cause 0DhRefusal cause 0EhData 0FhSegmentation 10h


Hop counter 11h

Table 3: Optional SCCP parameters

3.4.2. SCCP: addressing

Addressing is the fundamental aspect to be retained by the SCCP.As stated, the SCCP was largely created because of the need to expand the possibilities ofaddressing within the network. For this purpose, two additional forms of addressing havebeen defined (in addition to addressing by the SPC):

• Addressing by “Subsystem number”

The destination of the message is identified by a number (subsystem number, SSN) thatidentifies a specific application (subsystem) using the SCCP. The SSNs currently defined areas follows:

Subsystem Nº subsystemSCCP management 01hReserved 02hISUP (ISDN User Part) 03hOAMP (Operation, Adm.& Maint. User Part) 04hMAP (Mobile Application User Part) 05hHLR (Home Location Register) 06hVLR (Visited Location Register) 07hMSC (Mobile Switching Center) 08hEIR (Equipment Identification Register) 09hAUC (Authentication Center) 0AhISS (ISDN Supplementary Services) 0BhReserved for international use 0ChBroadband ISDN 0DhTCAP test responder 0EhReserved for international use 0Fh to 1FhReserved for national networks 20h to FEh

Table 4: SSNs currently specified

• Addressing by “Global title”

The global title consists of a sequence of digits that identify the destination (telephonenumber, telephone service prefix, credit card number, etc.).The “Signaling Transfer Points” (STPs) carry out a translation operation on these numberscalled global title translation, which results in a definite network address (SPC) and/or anSSN.The global title can be transmitted in four formats which vary with the type of informationincluded (with/without a numbering plan, nature of address, encoding scheme, etc.). Theidentification of the format is transmitted in a specific field (global title indicator).It should be noted that the major advantage of this method of addressing lies in the fact thatthe originating application of the message does not need to know its physical destination asthat mission is assigned to the STPs. This characteristic is fundamental in the implementationof the Intelligent Networks, for example.

The following figures describe the existing global title formats and the corresponding globaltitle indicator:


Global title indicator = 0001 (GTI 1):

7 6 5 4 3 2 1 0

O/E Nature of address indicator Octet 1

Global title address information Octet 2 andfurther


7 6 5 4 3 2 1 0

Translation type Octet 1

Global title address information Octet 2 and further


7 6 5 4 3 2 1 0


Numbering plan Encoding scheme Octet 2



7 6 5 4 3 2 1 0


Numbering plan Encoding scheme Octet 2

0 Nature of address indicator Octet 3


Note: the GTI4 format is the standard one in international networks.

An important point to remember is that the SCCP addresses can simultaneously contain anSPC, SSN and global title, but always in that order (according to the ITU-T definition):

7 6 5 4 3 2 1 0Byte 1Signaling Point Code

(SPC) Byte 2Subsystem number (SSN) Byte 3

Global Title (GT) Byte 4

Figure 14: SCCP, addresses format

In order to complete this chapter, below is the layout of a complete UDT (Unitdata) messageas well as the tables relating to the coding of the different fields:

PARAMETER Type 7 6 5 4 3 2 1 0Message Type Code F 0 0 0 0 1 0 0 1Return Option (R) / Prot. Class (C) F R 0 0 0 0 0 0 CPointer to Called Party AddressPointer to Calling Party AddressPointer to User Data


... Gaps possible in 1988 & 1992 versionsCalled Party Address Length IndicatorAddress Indicator : X RI GTI = 0 1 0 0 1 1RI = routing Indicator V Signaling Point CodeBit 1 = SSN includedBit 0 = SPC included SSN

Translation TypeNumbering Plan Encoding Scheme

Nature of AddressGT digits Digit 1 Digit 0

Digit ... Digit ....Digit 24 Digit 23

Calling Party Address Length IndicatorAddress Indicator X RI GTI = 0 1 0 0 1 1

V Signaling Point Code

SSNTranslation TypeNumbering Plan Encoding Scheme

Nature of AddressDigit 1 Digit 0Digit 3 Digit 4....... .......Digit 24 Digit 23

User Data V Length IndicatorValue

Figure 15: SCCP, UDT message

7 6 5 4 3 2 1 0

Reserved fornational use

Routingindicator

Global title indicator SSN indicator Point codeindicator

Figure 16: SCCP, coding of the field “ address indicator”

Bits 6 5 4 3 20 0 0 0 no global title included0 0 0 1 Global title includes nature of address indicator only0 0 1 0 Global title includes translation type only0 0 1 1 Global title includes translation type, numbering plan and encoding scheme0 1 0 0 Global title includes translation type, numbering plan, encoding scheme and

nature of address indicator0 1 0 1

to0 1 1 1

Spare international

1 0 0 0to

1 1 1 0

Spare national

1 1 1 1 Reserved for extension.0 xxxx Routing on Global Title1 xxxx Routing on SSN

Figure 17: SCCP, coding of the field “ global title indicator”


Bits 7 6 5 40 0 0 0 unknown0 0 0 1 ISDN/telephony numbering plan (Recommendations E.163 and E.164)0 0 1 0 generic numbering plan0 0 1 1 data numbering plan (Recommendation X.121)0 1 0 0 telex numbering plan (Recommendation F.69)0 1 0 1 maritime mobile numbering plan (Recommendations E.210, E.211)0 1 1 0 land mobile numbering plan (Recommendation E.212)0 1 1 1 ISDN/mobile numbering plan (Recommendation E.214)1 0 0 0

to1 1 0 1

spare

1 1 1 0 private network or network-specific numbering plan1 1 1 1 reserved.

Figure 18: SCCP, coding of the field “ numbering plan”

Bits 3 2 1 00 0 0 0 Unknown0 0 0 1 BCD, odd number of digits0 0 1 0 BCD, even number of digits0 0 1 1 National specific0 1 0 0

to1 1 1 0

Spare

1 1 1 1 Reserved.

Figure 19: SCCP, coding of the field “ encoding scheme”

Bits 7 6 5 4 3 2 1 0 Decimal Value0 0 0 0 0 0 0 0 0 unknown0 0 0 0 0 0 0 1

to0 0 1 1 1 1 1 1

1to63

international services

0 1 0 0 0 0 0 0to

0 1 1 1 1 1 1 1

64to

127

spare

1 0 0 0 0 0 0 0to

1 1 1 1 1 1 1 0

128to

254

national network specific

1 1 1 1 1 1 1 1 255 reserved for expansion

Figure 20: SCCP, coding of the field “translation type”



3.5. TCAP (Transaction Capabilities Application Part)

The TCAP (also designated TC) enables the exchanging of information between applicationsresident at different points of the network, using the connectionless service provided by theSCCP. The basic aim of the TCAP is to enable the execution of remote operations of thequestion-answer type, like database query or features activation/deactivation.The TCAP is the basic signaling used to support Intelligent Network applications,interconnection of mobile network’s databases, telecommunications networks management,etc.An important feature of these connections (called “transactions”) is the fact that they areindependent of any voice or data transmission channel (bearer channels), so they aredesignated “bearer unrelated” connections.

This aspect of the characterization of connections is often the source of misunderstandings,so let’s detail it a bit for the sake of clarification:

3.5.1. “Bearer related” connections versus “bearer unrelated” connections

A bearer related connection comprises a signaling channel and one or more associatedvoice/data channels. It corresponds to the situation of a normal telephone connection in whicha signaling channel is used (ISUP, for example) in order to assign and release a voicechannel (bearer channel) to make the respective call.That means, there is always at least one voice/data channel associated with the signaling linkduring the active phase of the call.

On the other hand, a bearer unrelated or connection independent connection has noassociated voice/data channel and all information is exchanged solely via the signalingchannel. This type of connection applies in situations where the transmission of largequantities of information in real time is not necessary, for example, the interrogation ofdatabases, sending telemetry data, passwords, network management, etc.

Note:

There is often a confusion with the terms connection oriented and connectionless , whichdescribe completely different concepts:

A connection oriented dialog is characterized by having an establishment (setup) phase, anactive phase (talk, information transfer) and a freeing of resources (release) phase. On theother hand, a connectionless dialog consists of transmitting individualized information thatalone contains all the information relating to the destination address (datagrams), there beingno reply from the destination as to whether it has been received. The data is simplytransmitted (typically in a UNITDATA message).

3.5.2. Characterization of the TCAP

The TCAP enables the establishing of an association (simple or multiple) betweenapplications resident in a network. The name transaction is applied to this association and itis identified by a sequential number assigned for each application and which remains fixedduring the existence of the transaction, designated respectively Originating Transaction IDor Destination Transaction ID .


Associated with a transaction is the definition of a dialog, identified by a Dialog ID. A dialogcan be structured (connection oriented transaction with a beginning, middle and end), ornon-structured (connectionless transaction).

An application context may be associated with the dialog, containing the informationnecessary to make the applications compatible. A typical example consists of the negotiatingof the format of the information, or version of software of the application.

A dialog may contain one or more components, which finally contains the application specificdata, such as the invoking of a remote operation or a response with the respective result.Each component must contain a sequential identification that identifies the invocation andrespective response, the Invoke D, as well as an associated operation depending on theapplication, the operation code. As an option it can have a secondary identification, thelinked ID.

3.5.3. Structure of the TCAP messages

Following the previous definitions, we see that the TCAP messages consists of two perfectlydefined parts:

Transaction Portion

Component Portion

Transaction portion:

This contains the data relating to the transaction (Transaction IDs), and to the dialog (dialogprimitive/message type, Dialog ID, application context).The primitives defined for the transaction portion are as follows:

TC-UNITDATA Identifies a non-structured dialog, that is, the transmission of self-contained information without response. All the remaining primitivesrefer to structured dialogs.

TC-BEGIN First primitive transmitted, request for start of transaction.

TC-CONTINUE Indicates the continuation of an already established dialog.

TC_END Structured closure of a dialog.

TC-U-ABORT User Abort, signals to the remote application that the transaction hasbeen aborted by the initiative of the local application.

TC-P-ABORT Provider Abort, signals both applications that the transaction hasbeen aborted by the TCAP.

TC-NOTICE Signals to the local application that the requested service cannot beprovided.

Component portion:

Contains one or several components relating to the application, which can be invocations,results, error messages, etc.


The primitives defined for the component portion are as follows:

TC-INVOKE Signals an interrogation to the remote application. Contains asobligatory parameters the Invoke ID and an operation code thatidentifies the specific operation required.

TC-RESULT-L Result Last, sole response to an invoke primitive. Must contain thesame Invoke ID as the invocation which originate it.

TC-RESULT-NL Result Not Last, intermediate response to an invoke primitive.It is used when there is a segmentation of the response.Must contain the same Invoke ID invocation that originated it. Thelast segment of the response is sent with a TC-RESULT-L primitive,of course.

TC-U-ERROR User Error, response to an invoke primitive indicating failure by theremote application in the execution of the required operation.

TC-L-CANCEL Local Cancel, signals the cancellation or a prior invocation by theTCAP (normally by timing out of the response time of the remoteapplication).

TC-U-CANCEL User Cancel, signals the cancellation of a previous invocation by thelocal application.

TC-L-REJECT Local Reject, signals the rejection of the previous invocation by thelocal TC, due to error in the respective parameters.

TC-R-REJECT Remote Reject, signals the rejection of the previous invocation by theremote TC, because of an error in the respective parameters.

TC-U-REJECT User Reject, signals the rejection of the previous invocation by theremote application, because of an error in the respective parameters.

As has been stated, underlying each invocation is a specific application operation code. Thetypes of response possible for an invocation depend on the class of operation with whichthat operation has been defined. There are four defined classes of operation, as follows:

Class ofoperation

Description Remarks

1 Report success or failure The remote operation always responds tothe invocation with a result.

2 Report only failure The remote operation responds to theinvocation only in the case of error.

3 Report only success The remote operation responds to theinvocation only in the case of success.

4 No report The remote operation never responds to theinvocation.

Table 5: Class of operation in the TCAP

The TCAP is a type of signaling that is partly aligned with the OSI model so that all theprimitives that have a remote significance exist in the request and indication form; this meanssay that a primitive sent by the application to the TC is of the _req type and the correspondingprimitive passed remotely by the TC to the application of the _ind type.


The transmission/reception of the elements of the transaction portion and the componentportion is always done in stack mode; this means that the application passes in first place thecomponents to the TCAP and the dialog primitive after, and the remote application receivesfrom the TCAP the dialog primitive followed by the components (see flow in the followingchapter).

3.5.4. A specific application example: the CCBS

In order to clarify the concepts stated previously, below is a typical example of a TCAPapplication in the telephone network, the CCBS service.The CCBS service (Call Completion to Busy Subscriber), enables a subscriber to beautomatically recalled when the destination number is busy; after hearing the busy signal, thesubscriber activates the service and in the case of success (the result is presented in the formof a tone or a display) puts the phone on-hook. When the remote subscriber becomes free,the local subscriber who activated the service is recalled, that is to say, his telephone rings;when he picks up the receiver the call to the remote subscriber is established automatically.

If we examine closely what is happening in the signaling network from the moment when thesubscriber activates the service, we will note the following flow:

Figure 21: Flow of the CCBS service

Below is a description of the flow:

1. When the subscriber activates the CCBS service (normally via a sequence of digits) theapplication responsible for the CCBS is called; this application generates a sequence(called APDU, Application Protocol Data Unit) which contains the data required for theinvocation of the CCBS at the remote exchange, namely the operation code designatedas ccbsRequest, followed by the dialog primitive to be sent (BEGIN).

TC-RESULT-L_reqTC-CONTINUE_req

TC-CONTINUE_indTC-RESULT-L_ind

TC TCSCCP SCCPMTP MTP

TC-INVOKE_req<ccbsRequest>TC-BEGIN_req TC-BEGIN_ind

TC-INVOKE_ind<ccbsRequest>

TC-END_req

TC-END_ind

TC-INVOKE_req<remoteUserFree>TC-CONTINUE_req

TC-CONTINUE_indTC-INVOKE_ind<remoteUserFree>


2. The TCAP constructs a unique message (a PDU, Protocol Data Unit), a TC-BEGIN_reqwith a TC_INVOKE_req, and sends it to the lower signaling level, in this case theconnectionless service of the SCCP. The SCCP carries out the translation of thedestination telephone number into a network address (global title translation),encapsulates the message received from the TCAP in a UDT message (UNITDATA) andsends it to its destination using the MTP services.

3. When the message reaches the remote exchange (possibly after passing through severalnetwork nodes, SPs or STPs) the TCAP separates the components of the receivedmessage and passes it to the CCBS application via a TC-BEGIN_ind followed by a TC-INVOKE_ind, which contains the operation code. The application decodes the APDUreceived, activates the monitoring of the subscriber whose access is busy and sends theresult back to the originating application by means of a component TC-RESULT-L_reqfollowed by a TC-CONTINUE_req.

4. When the remote application detects that the subscriber is free, it generates an APDUwith the remoteUserFree operation code, which is sent by the TCAP in a TC-INVOKE_req and in a TC-CONTINUE_req.

5. The local application receives the information that the subscriber is free and activates theringing tone to the local subscriber. When this answers, the call-processing application isinvoked to establish a normal call, while the CCBS application (which has alreadycompleted its mission) terminates the TCAP transaction with its remote partner sending ita TC-END_req message.

Some additional comments on this example:

• Users of the TCAP: recalling the diagram with the SS#7 protocols stack (Page 9) we canidentify the users involved in this example: thus, we have the MTP (layer 1,2 and 3), theSCCP (an add-on on layer 3), the TCAP (layer 7), and finally a TCAP user, theapplication CCBS. This application is standardized by the ITU-T and belongs to the ISS(ISDN Supplementary Services).Meanwhile it should be emphasized that the TCAP could be (and it is) also used in

proprietary applications.

• Operation code: as has been said previously, the TC-INVOKE primitives always containan associated operation code; in this particular case, we are using operations that havebeen standardized by the ITU-T for the CCBS service: the ccbsRequest operation, whichis defined as a class 1 operation (there is always a response) and the RemoteUserFreeoperation, which is a class 4 operation ( does not expect a response).

• Invoke ID: each TC-INVOKE component is associated with an arbitrary number thatidentifies it, called Invoke ID (in our example, the TC-INVOKE with ccbsRequest and theTC_RESULT-L carry the same Invoke ID because the second is a response to the first).

3.5.5. The encoding of TCAP messages

One aspect that could appear surprising is the fact that throughout this chapter we have notshown layouts defined for the messages, as it was the case of the chapters dedicated to theMTP and the SCCP. The reason is simple: the APDUs of the applications using the TCAP, aswell as the PDUs of the TCAP itself are encoded in accordance with a syntax standardized bythe ITU-T, designated ASN.1 (Abstract Syntax Notation No.1), which by their nature are notable to be represented in a fixed format.This may seem strange but we should not forget that we are working at the OSI Applicationlevel, and at this level it is intended that communication should be possible between differentapplications, independently of the platform, manufacturer, etc. (open systems concept).


ASN.1 was therefore created in order to enable communication between open systems, byusing an abstract syntax. But this is a subject that merits a chapter of its own.


3.6. ASN.1 notation (Abstract Syntax Notation No.1)

The OSI architecture has been defined in accordance with the “open system” concept. Inorder to guarantee communication between different platform applications, level 6 wasenvisaged (Presentation), responsible for making the formats or data representation systemscompatible. This involved the definition of an abstract syntax or rather a form of referencingdata independently of their representation form, and a transfer syntax, a set of rules thatenable the values to be transmitted in binary terms. A specific language was thereforecreated for this purpose, the ASN.1 (Abstract Syntax Notation No. 1).

In almost all existing implementations, level 6 does not exist as an isolated level, but is ratherembedded in the application layer, so in that sense the proposed OSI model did not succeed;meanwhile, ASN.1 (about which there were grave doubts at the beginning) became actuallywidely used both in switching networks (Intelligent Networks, GSM, TMN) and in IP basednetworks (the widely popular Network Management Protocol SNMP uses ASN.1).

It is not the intention of this document to provide an exhaustive description of this languagebut an understanding of its basic principles is fundamental for anyone working in this area, sothe following chapters have been dedicated to this subject.

3.6.1. Abstract syntax

ASN.1 is based on the definition of basic types of data (somewhat incorrectly referred to asobjects) from which more complex data types are defined.

The language provides a set of universal data type, which can be used as blocks for thedefinition of new data types, valid for specific applications.

In an ASN.1 module, the definition of data is made according to the following syntax:

name of the object ::= type of object

The lines beginning with (--) are comments.

Below is a description of the types of universal data defined in ASN.1, including an exampleof definition and, where appropriate, an example of value notation:

½ BOOLEAN

An object whose possible values are TRUE or FALSE.

example: Married::=BOOLEAN

½ INTEGER

Any whole negative, positive or zero number.

example of definition: DayOfMonth::=INTEGER

½ REAL

Value pertaining to the set of real numbers.

example: Area::=REAL


½ BIT STRING

Value represented by a binary sequence.

example: PageOfFax::=BIT STRING

example of notation: ‘10100111’B or ‘A7’H

½ OCTET STRING

Value comprising a sequence of octets, one octet being an ordered sequence of eight bits.

example: TracerOnline::=OCTET STRING

½ VisibleString

Sequence of characters in accordance with norm ISO 646 (equivalent to the ASCII notation).

example: NameOfFather::=VisibleString

example of notation: “John”

½ ENUMERATED

Values that are allocated different identifiers.

example: ResultOfExam::=ENUMERATED {WentWell(0), WentBadly(1), SoSo(2)}

½ SEQUENCE

List of types, fixed and in order. Can include optional elements but the sequence must alwaysbe maintained.example: PointCard::=SEQUENCE

{Name VisibleString, Number INTEGER, Position VisibleString OPTIONAL, Unit INTEGER}

½ SEQUENCE OF

Ordered sequence of values of the same type.

example: NumbersOfTheLottery::=SEQUENCE OF INTEGER

½ SET

Fixed, non-ordered set of types.

example: identical to the example submitted to SEQUENCE

½ SET OF


Non-ordered set of values of the same type.

example: identical to the example submitted to SEQUENCE OF

½ CHOICE

Fixed, non-ordered list of values of which only one can be selected.

example: Identification::=CHOICE{IdentityCardNo INTEGER, PassportNo INTEGER}

½ ANY½ ANY DEFINED BY

This is a derivation of CHOICE, in which the components are not specified a priori, but can beof any type defined by ASN.1.

example: TextOfPost::=ANY

½ NULL

Single value, null. This is used when several alternatives are possible and none is applicable.

example: ResultReceived::=CHOICE {INTEGER, NULL}

½ OBJECT IDENTIFIER

Sequence of values enabling the identification of an object or a standardized operation.It is frequently used to identify operations described in international standards and normallycomprises a sequence of values in which:

- The first value identifies the organization issuing the standard: 0=CCITT, 1=ISO,...- The second value identifies the type of member: standard, authority, network operator,...- Etc., etc....

½ Object Descriptor

Text associated with an OBJECT IDENTIFIER, which describes it in a readily intelligible form.

½ UTCTime

UTC data (Universal Time Coordinated).

½ GeneralizedTime

Another variant of the date.

There are also other universal types of date that identify objects such as NumericString,PrintableString, etc., for which a detailed definition may be found in the ASN.1 standards.


For an illustration of the structure of an ASN.1 module let us consider the definition of theCCBS service:

CCBSTC {ccitt recommendation q 733 3 operations-and-errors (1) version1 (1)} -- issue 08.02.98

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

IMPORTS Number, ScpDialogData FROM Add-TCAP-Information

OPERATION, ERROR FROM TCAPMessages {ccitt recommendation q 773 modules(2) messages(1) version2(2)};

--operation types

CcbsRequest ::= OPERATION PARAMETER ccbsRequestArg CcbsRequestArg RESULT ccbsRequestRes CcbsRequestRes ERRORS { ShortTermDenial, LongTermDenial}

ForwardCcbsRequest ::= OPERATION PARAMETER forwardCcbsRequestArg ForwardCcbsRequestArg

--Timer T = CCBS-T2

CcbsCancel ::= OPERATION PARAMETER cancelCause CauseCode -- OPTIONAL

CcbsSuspend ::= OPERATION

CcbsResume ::= OPERATION

RemoteUserFree ::= OPERATION

--error type definitions

LongTermDenial ::= ERRORShortTermDenial ::= ERROR

--constants and data type definitions

CcbsRequestArg ::= SEQUENCE{ calledPartyNumber Number, retainSupported BOOLEAN DEFAULT FALSE, userServiceInf [1] IMPLICIT USICode OPTIONAL, callingPartyNumber [2] IMPLICIT Number OPTIONAL, userServiceInfPrime [3] IMPLICIT USICode OPTIONAL, accessTransport [4] IMPLICIT AccessTransport OPTIONAL, scpDialogData [6] IMPLICIT ScpDialogData OPTIONAL }


ForwardCcbsRequestArg ::= SEQUENCE{ calledPartyNumber Number, callingPartyNumber Number, presentationRestrInd BOOLEAN, retainSupported BOOLEAN DEFAULT FALSE, transCalledPartyNumber [1] IMPLICIT Number OPTIONAL, userServiceInf [2] IMPLICIT USICode OPTIONAL, userServiceInfPrime [3] IMPLICIT USICode OPTIONAL, accessTransport [4] IMPLICIT AccessTransport OPTIONAL, cug-Info [5] IMPLICIT SEQUENCE { cug-Index [0] IMPLICIT INTEGER (0 .. 32767 ) OPTIONAL, suppressPrefCUG [1] IMPLICIT NULL OPTIONAL, suppressOA [2] IMPLICIT NULL OPTIONAL, ... } OPTIONAL }

CcbsRequestRes ::= SEQUENCE{ retainSupported BOOLEAN DEFAULT FALSE }

CauseCode ::= ENUMERATED{ cCBS-T3-Timeout (1), cCBS-T4-Timeout (2), cCBS-T7-Timeout (3), cCBS-T9-Timeout (4)}

USICode ::= OCTET STRING (SIZE (1..11))

AccessTransport ::= OCTET STRING (SIZE (1..maxAccessTransportLength))

maxAccessTransportLength INTEGER ::= 255

-- object identifier path

ccbsOID OBJECT IDENTIFIER ::= {ccitt recommendation q 733 3operations-and-errors(1)}

-- operation values

ccbsRequest CcbsRequest ::= globalValue:{ccbsOID 1}

ccbsCancel CcbsCancel ::= globalValue:{ccbsOID 2}

ccbsSuspend CcbsSuspend ::= globalValue:{ccbsOID 3}

ccbsResume CcbsResume ::= globalValue:{ccbsOID 4}

remoteUserFree RemoteUserFree ::= globalValue:{ccbsOID 5}

forwardCcbsRequest ForwardCcbsRequest ::= globalValue {ccbsOID 9}

-- error values

shortTermDenial ShortTermDenial ::= globalValue:{ccbsOID 6}

longTermDenial LongTermDenial ::= globalValue:{ccbsOID 7}

END -- of CCBS-Protocol

Some comments on this module:


- The designations OPERATION, PARAMETER, RESULT and ERROR correspond tothe macros imported from other module. ASN.1 has a wide range of resources for creatingmacros that enable the definition of new types of data.

- As may be seen, the construction of the data structures in ASN.1 consists of defininga macrostructure and defining the lower levels recursively. For example, in this module wehave the definition of an operation called CcbsRequest, whose parameters are calledCcbsRequestArg and are of the type CcbsRequestArg. The structure CcbsRequestArgis in turn made up of a sequence that contains a parameter called CalledPartNumber ofthe type Number, one retainSupported of the BOOLEAN type, etc... etc.

- Note that in the statement ccbsOID OBJECT IDENTIFIER and subsequent statements thatidentify these operations as objects defined in CCITT Standard Q733…

- Note the syntax [xx] IMPLICIT. Its importance will become clear a little later.


3.6.2. Transfer syntax

In parallel with the definition of the object types, ASN.1 defines the basic rules for encodingthem. These rules are standardized with the name B.E.R. (Basic Encoding Rules), and theserules define the transfer syntax, that is, the form in which the abstract descriptions we sawpreviously are mapped and transmitted in a sequence of octets.

The basic principles of data coding in ASN.1 are as follows:

q All the ASN.1 objects have an associated label (called tag) and are coded according to asequence Tag-Length-Value, TLV for short. A message coded in ASN.1 consists of arecursive sequence of TLV blocks.

Figure 22: TLV sequence

3.6.2.1. Coding the tag

q Four tag classes are defined, as follows:

- Universal: These correspond to the basic types described in the previouschapter (INTEGER, BOOLEAN, REAL, etc.). They are always codedwith the same value, independently of the application (they areuniversal).

- Application: These are defined for a specific application and therefore arerelevant only within the scope of that application.

- Context: These are defined for a specific application and relevant only in aspecific context of that application.

- Private: These are defined by the users of the application and thereforerelevant exclusively for those users.

The coding of the tag takes place as follows if the number of the tag is less than or equal to30:

Figure 23: Tag coding (if less than 30)

T L V T L V T L V

T L V

Class(2 bits)

P/C(1 bit)

Nº of tag(5 bits)


The class is coded in the following way:

Class Description00 Universal01 Application10 Context11 Private

Table 6: Class coding

The P/C bit identifies the type of tag as Primitive or Constructed.A tag is of the primitive type if it identifies a type of value defined, as INTEGER, BOOLEAN,NULL, etc.A tag is of the Constructed type if it can incorporate types of different objects, as in the caseof SET, SET OF, SEQUENCE, etc.

P/C Description0 Primitive1 Constructed

Table 7: Type coding (P/C bit)

The tags with a reference number higher than 30 can no longer be coded in a single octet. Inthis case, the tag number is filled in with 11111, and as many bytes follow as are necessary toencode it, with bit 7 filled to 1, except in the last byte (?!) … well, the best way is to look at thefollowing figure:

Figure 24: Tag coding for values higher than 30

In order to conclude this topic, below are shown the codes associated with the tags of theUniversal class as these are the only ones whose coding is always the same, independentlyof the application:

Name Class CodingBOOLEAN UNIVERSAL 1 01hINTEGER UNIVERSAL 2 02hBIT STRING UNIVERSAL 3 03hOCTET STRING UNIVERSAL 4 04hNULL UNIVERSAL 5 05hOBJECT IDENTIFIER UNIVERSAL 6 06hOBJECT DESCRIPTOR UNIVERSAL 7 07hEXTERNAL UNIVERSAL 8 08hREAL UNIVERSAL 9 09hENUMERATED UNIVERSAL 10 0Ah+++ reserved UNIVERSAL 11 ---+++ reserved UNIVERSAL 12 ---+++ reserved UNIVERSAL 13 ---+++ reserved UNIVERSAL 14 ---+++ reserved UNIVERSAL 15 ---SEQUENCE (and ... OF) UNIVERSAL 16 10h

Class P/C 1 1 1 1 1 1 X X X X X X X 0 X X X X X X X...........


SET (and SET OF) UNIVERSAL 17 11hNumericString UNIVERSAL 18 12hPrintableString UNIVERSAL 19 13hTelexString UNIVERSAL 20 14hVideotextString UNIVERSAL 21 15hIA5String UNIVERSAL 22 16hUTCTime UNIVERSAL 23 17hGeneralizedTime UNIVERSAL 24 18hGraphicString UNIVERSAL 25 19hVisibleString UNIVERSAL 26 1AhGeneralString UNIVERSAL 27 1Bh

Table 8: Codes allocated to Universal-type classes

3.6.2.2. Coding of the “length”

The length of the value in ASN.1 is coded in accordance with the following rule:

q If the length is less than 128 the so-called short defined format will apply, that is, it iscoded in a single octet, leaving bit 7 to zero:

q If the length is greater than or equal to 128 the so-called long defined format will apply,that is, the first octet has bit 7 set to 1 and the remaining bits indicate how many octetsfollow to encode the length (once again, it is better to look at the picture):

q If the overall length is unknown at the start of the transmission the undefined formatapplies, that is, the first octet has bit 7 set to 1 and the remainder to zero, and the octetsthat follow contain the value. When all the octets have been transmitted, two additionaloctets are sent filled with zeros … Obviously, the use of this format implies that the valueis coded in such a way that it contains no sequence of 2 octets set to zero.

0 X X X X X X X

X X X X X X X X(Length)

1 Nº of octets Lthat follow ...........

X X X X X X X X(Length)


3.6.3. Practical use

If the coding of objects in ASN.1 was limited to the use of tags of the Universal class wewould not have a big added value with it; but in fact ASN.1 permits the creation of morecomplex structures, with the allocation of specific tags for each application. That’s the aspectwe will illustrate briefly.

In the first place, let us assume that we are attempting to encode a company’s employeerecords. This could be done in the following way:

Module_1 DEFINITIONS

::=

BEGIN

RecordOfEmployee ::= SEQUENCE { name Name,

number NumberOfEmployee, nameOfSpouse Name OPTIONAL,

children RecordOfChild OPTIONAL}

RecordOfChild ::= SET {name Name,age Age}

Name ::=VisibleStringNumberOfEmployee ::=INTEGER (0 .. 1000)Age ::=INTEGER

END

In the specific case of John, employee no. 33, married to Mary, with a son Paul aged 14, theresulting sequence would be:

30 SEQUENCE1C length 1A 04 4A 6F 73 65 VisibleString, length=4,value=“John” 02 01 21 INTEGER, length=1,value=33 1A 05 4D 61 72 69 61 VisibleString, length=5,value=“Mary” 31 SET 0A length 1A 05 50 61 75 6C 6F VisibleString, length=5,value=“Paul” 02 01 0E INTEGER, length=1, value=14

Note the following: the sequence RecordOfEmployee contains two objects of the type Name.As this relates to a SEQUENCE there can be no confusion since the order is always retained,but this would not be the case if RecordOfEmployee had been defined as a SET (in which theorder of the objects is arbitrary).In order to avoid problems of this sort, tags from the Context class should be defined, i.e. theallocation of a specific tag for an object; thus, this tag would be valid only in that specificsituation in that ASN module.ASN.1 also enables the allocation of Application class tags to any object which means thatthis object will always be identified with that tag throughout the application.


Let us now see the previous example modified by using tags from the Context and Applicationclasses:


::=

BEGIN

RecordOfEmployee ::= [APPLICATION 1] SEQUENCE { name Name,

number NumberOfEmployee, nameOf Spouse [1] Name OPTIONAL,

children [2] RecordOfChild OPTIONAL}

RecordOfChild ::= SET {name [0] Name,age Age}


END

This time the resulting coding would be:

61 APPLICATION 1 Å RecordOfEmployee !!!24 length30 SEQUENCE22 length 1A 04 4A 6F 73 65 VisibleString, length=4,value=“John” 02 01 21 INTEGER, length=1,value=33 A1 07 1A 05 4D 61 72 69 61 Context 1,VisibleString, length=5,value=“Mary” !!! A2 0E 31 Context 2, SET !!! 0C length A0 07 1A 05 50 61 75 6C 6F Context 1 VisibleString...,value=“Paul” !!! 02 01 0E INTEGER, length=1, value=14

Note that now the sequence RecordOfEmployee is always identified by means of a specifictag for the entire application, tag 1 from the Application class.On the other hand, the object NameOfSpouse is now identified by tag 1 from the Contextclass, when integrated in the RecordOfEmployee sequence, the same applying for the objectChildren (tag 2 from the Context class). On the other hand, the object Name takes tag 0 whenintegrated in the object RecordOfChild.

The last point to consider is as follows: with this alteration the coded sequence becomeslonger as the Application and Context tags follow the tags of the primitive types comprisingthem (INTEGER, VisibleString, etc.). However, we are sending redundant information insofaras, for example, we already know that RecordOfEmployee (tag=61) is a sequence (tag=30).Therefore we need to find a coding in such a way that we can code TL(TLV) into T´L´V.The way to achieve this is by using the IMPLICIT instruction, by which we inform the compilerthat the structure of the object in question is implicit in the actual tag.

By applying this principle, our example would finally be described as follows:



::=

BEGIN

RecordOfEmployee ::= [APPLICATION 1]IMPLICIT SEQUENCE { name Name,

number NumberoOfEmployee, nameOfSpouse [1]IMPLICIT Name OPTIONAL,

children [2] IMPLICIT RecordOfChild OPTIONAL}

RecordOfChild ::= SET {name [0] IMPLICIT Name,age Age}


END

... and the resulting coding would finally be:

61 APPLICATION 1 Å RecordOfEmployee1C length 1A 04 4A 6F 73 65 VisibleString, length=4,value=“John” 02 01 21 INTEGER, length=1,value=33 81 05 4D 61 72 69 61 Context 1,VisibleString, length=5,value=“Mary” A2 0A Context 2, 80 05 50 61 75 6C 6F Context 0, VisibleString...,value=“Paul” 02 01 0E INTEGER, length=1, value=14

Normally, the IMPLICIT operator is used intensively because of the obvious compressionobtained. In order to avoid the systematic repetition of this operator in each definition ofobjects, the compiler can be told to use this notation by default, placing the IMPLICIT TAGSdirective at the head of the module. If a tag is to be coded explicitly, we can define this bymeans of the EXPLICIT directive.

From all that has been stated here, the final form of our module would doubtless be:


IMPLICIT TAGS

::=

BEGIN

RecordOfEmployee ::= [APPLICATION 1] SEQUENCE { name Name,

number NumberOfEmployee,nameOfSpouse [1] Name OPTIONAL,

children [2] RecordOfChild OPTIONAL}


RecordOfChild ::= SET {name [0] Name,age Age

}


END

In compiling this last module we would be able to confirm that the resulting coding would beexactly the same as that obtained with the previous module.



4. Users of SS#7

This chapter describes (briefly) some applications that use the No. 7 Signaling System andthe respective protocols.

4.1. ISS (ISDN Supplementary Services)

The ISS incorporates a series of facilities implemented in the telephone network, mainly (butnot exclusively) ISDN features. The following are some examples:

• “Call Completion” facilities, of which the already described CCBS is an example, and “CallCompletion on No Reply” (CCNR), which is very similar to the former:when subscriber A calls subscriber B and the latter one does not answer, subscriber A

can activate the CCNR service; the access to subscriber B is monitored until activity isdetected there and when the line becomes free the recalling of subscriber A is triggered,as in the CCBS.

• “Message Waiting Indication” (MWI), used in the voice-mail service: when an ISDNsubscriber has messages in his mailbox, this facility enables transmission of thisindication to the respective access. The information is carried via SS#7 in the networkand transmitted to the ISDN access via D channel.

To conclude this chapter, an example of an SCCP PDU is shown, which illustrates a majorpart of what has been described in this document: it consists of a UNITDATA (SCCP)message that encapsulates a TC-BEGIN (TCAP). The ASN.1 modules necessary in order tounderstand this example are found in Appendix 1: ASN.1 modules.

The TCAP message contains the following elements:

Transaction portion:

- Field “originating Transaction ID”

Component portion:

- Contains the following two invoke components:

- One component with the “inData” operation and respective parameters. Thisoperation belongs to a proprietary Siemens application known as BCAP (BusinessCorporation Application Part), and carries information intended for an IntelligentNetworks service.

- One component with the “mwiSet” operation and respective parameters. Thisoperation belongs to the ISS and is standardized by the ITU-T, containing as such afield of the type “Object Identifier”.

09, Message Type = UNITDATA SCCP part80, Bit Return Option set03, pointer to GT-Called Pty Address07, pointer to GT-Calling Pty Address0E, pointer to User data04,43,01,00,03, GT-Called Pty Address07,12,03,00,12,98,32,43, GT-Calling Pty Addr

------------------------------------76, length of USER DATA


62, BEGIN_ind TCAP part74, length48,04,08,8D,43,51, Originating Trnsaction ID

6C, Component Portion6C, length

A1, Invoke Component nr.144, length02,01,01, Invoke Id02,01,10, OPERATION =inData30, Sequence3C, length02,01,1C, triggerTableIdx30, sequence2C, length04,04,31,32,33,34, serviceKey02,01,07, ACN Selector02,01,03, SSF type02,01,03, (iN)NetworkInd30, Sequence1B, length01,01,01, spcIncluded04,03,12,34,00, spc02,01,02, routePref02,01,0C, ssid02,01,0A, transType02,01,02, encScheme04,05,03,10,17,44,44, number30, Sequence09, length04,03,B1,B2,B3, bgID04,02,C1,C2, subBGID

A1, Invoke Component nr.224, length02,01,%100, Invoke Id06, OBJECT IDENTIFIER06, length04, ccitt/ident org.00, etsi85,72, 75401, oper. and error01, OPERATION=mWISet30, Sequence17, length04,05,83,10,98,76,80, receivingUserNumber04,05,83,13,98,76,08, controllingUsetNumber0A,01,02, basicService= Unr.DigitalInfoA1, 04,02,02,00,07 Optional par=numberOfmessages


4.2. INAP (Intelligent Networks Application Part)

To be provided later.



4.3. MAP (Mobile Application Part)




4.4. CAP (CAMEL Application Part)



5. List of acronyms

ACSE Association Control Service ElementAPDU Application Protocol Data UnitASE Application Service ElementASN.1 Abstract Syntax Notation No. 1AUC Authentication CenterB-ISDN Broadband ISDNBSN Backward Sequence Number (MTP)BSS Base Station Subsystem (GSM)CCBS Call Completion to Busy Subscriber (ISS)CRC Cyclic Redundancy CheckCS-x Capability Set x (IN)DPC Destination Point CodeDUP Data User PartEIR Equipment Identification RegisterFCS Frame Check SequenceFISU Fill-In Signal Unit (MTP)FSN Forward Sequence Number (MTP)GSM Global System MobileGT Global Title (SCCP)GTI Global Title Indicator (SCCP)HLR Home Location RegisterIN Intelligent NetworkIP Intelligent Peripheral (IN) or Internet ProtocolISDN Integrated Services Digital NetworkISPC International Signaling PointISS ISDN Supplementary ServicesISUP ISDN User PartITU-T International Telecommunications Union – StandardizationLI Length Indicator (MTP)LSSU Link Status Signal UnitMACF Multiple Association Control Function (INAP)MAP Mobile Application PartMSC Mobile Switching CenterMSU Message Signal Unit (MTP)OAMP Operation, Administration & Maintenance PartOPC Originating Point CodePABX Private Automatic Branch ExchangePDU Protocol Data UnitROSE Remote Operations Service ElementSACF Single Association Control Function (INAP)SCCP Signaling Connection Control PartSCEF Service Creation Environment Function (IN)SCF Service Control Function (IN)SCP Service Control Point (IN)SIM Subscriber Identity Module (GSM)SIO Service Information Octet (MTP)SLS Signaling Link Selection (MTP)SP Signaling PointSPC Signaling Point CodeSRF Specialized Resource Function IN)SSF Service Switching Function (IN)SSN Subsystem Number (SCCP)SSP Service Switching Point (IN)STP Signaling Transfer PointSU Signaling Unit (MTP)


TC Transaction CapabilitiesTCAP Transaction Capabilities Application PartTMN Telecommunication Management NetworkTUP Telephone User Part

UDT Unitdata (SCCP)UMTS Universal Mobile Telecommunication SystemVLR Visitor Location Register (GSM)XUDT Extended Unitdata (SCCP)


6. Bibliography

6.1. ITU-T Recommendations

- MTP: Recommendations Q.701 to Q.709- SCCP: Recommendations Q.711 to Q.716- TUP: Recommendations Q.721 to Q.725- ISS: Recommendations Q.730 to Q.737- OAMP: Recommendations Q.750 to Q.755- ISUP: Recommendations Q.761 to Q.767- TCAP: Recommendations Q.771 to Q.775- MAP: Recommendation Q.1051- INAP-CS1: Recommendation Q.1218- INAP-CS2: Recommendation Q.1228

6.2. Other documents

Siemens P30308-A1638-D011-**-7622, SCCP Catalog version 13,13T, 14A

Vargas OSI-models, AEIST, 1996

Magedanz, T. Intelligent Networks-Standards and evolution to Universal Services, IBCLondon, 1999

Frampton, J. Signaling system #7, Philips Omnicom Training, 1998


7. Appendices

7.1. Appendix 1: ASN.1 modules

7.1.1. Definition of TCAP messages (standard)

TCAPMessages {ccitt(0) recommendation q 773 modules(2) messages(1)version2(2)} -- issue 08.02.98

DEFINITIONS ::=

BEGIN

-- This ASN.1-module TCAPMessages is based on-- CCITT Q773-92-- COM XI-R 199-E--

-- Requirements:-- *************-- * Type TransactionID introduced and used in DestTransactionID-- and OrigTransactionID.---- * The unlimited INTEGER in "P-AbortCause" changed in INTEGER-- with SIZE-constraint "SIZE (0..127)".---- * Typedefiniton of "ComponentPortion":-- SIZE-constraint "(1..MAX)" is removed to get the-- "resource-management".---- * All 5 unlimited INTEGER’s (in PROBLEMS) were changed to INTEGER’s-- with SIZE-constraint "SIZE (0..127)".---- * Definition of the Macros OPERATION and ERROR not included,-- however in EXPORTS clause included

EXPORTS OPERATION, ERROR, MessageType, Component, InvokeIdType;

-- Transaction Portion fields

MessageType ::= CHOICE { unidirectional [APPLICATION 1] IMPLICIT Unidirectional, begin [APPLICATION 2] IMPLICIT Begin, end [APPLICATION 4] IMPLICIT End, continue [APPLICATION 5] IMPLICIT Continue, abort [APPLICATION 7] IMPLICIT Abort}

Unidirectional ::= SEQUENCE {dialogPortion DialogPortion OPTIONAL, components ComponentPortion}

Begin ::= SEQUENCE {otid OrigTransactionID, dialogPortion DialogPortion OPTIONAL, components ComponentPortion OPTIONAL}

End ::= SEQUENCE {dtid DestTransactionID, dialogPortion DialogPortion OPTIONAL, components ComponentPortion OPTIONAL}


Continue ::= SEQUENCE {otid OrigTransactionID, dtid DestTransactionID, dialogPortion DialogPortion OPTIONAL, components ComponentPortion OPTIONAL}

Abort ::= SEQUENCE {dtid DestTransactionID, reason CHOICE {p-abortCause P-AbortCause, dialogPortion DialogPortion} OPTIONAL}

-- Note: When the Abort Message is generated by the Transaction sublayer,-- a p-Abort Cause must be present.

DialogPortion ::= [APPLICATION 11] EXTERNAL

-- The dialog portion carries the dialog control PDUs as value-- of the external data type. The direct reference should be set-- to {ccitt recommendation q 773 as(1) dialog-as(1) version1(1)}-- if structured dialog is used and-- to {ccitt recommendation q 773 as(1) unidialog-as(2) version1(1)}-- if unstructured dialog is used or-- any user defined abstract syntax name-- when only user information is carried-- (e.g. when user information is sent in-- a 1988 Abort message).

OrigTransactionID ::= [APPLICATION 8] IMPLICIT TransactionIDDestTransactionID ::= [APPLICATION 9] IMPLICIT TransactionID

TransactionID ::= OCTET STRING (SIZE(1..4))

P-AbortCause ::= [APPLICATION 10] IMPLICIT INTEGER { unrecognizedMessageType (0), unrecognizedTransactionID (1), badlyFormattedTransactionPortion (2), incorrectTransactionPortion (3), resourceLimitation (4) } (0..127)

-- COMPONENT PORTION. The last field in the transaction portion-- of the TCAP message is the component portion. The component-- portion may be absent.

ComponentPortion ::= [APPLICATION 12] IMPLICIT SEQUENCE OF Component

-- Component Portion fields

-- COMPONENT TYPE. Recommendation X.229 defines four Application-- Protocol Data Units (APDUs).-- TCAP adds returnResultNotLast to allow for the segmentation of-- a result.

Component ::= CHOICE{ invoke [1] IMPLICIT Invoke, returnResultLast [2] IMPLICIT ReturnResult, returnError [3] IMPLICIT ReturnError, reject [4] IMPLICIT Reject, returnResultNotLast [7] IMPLICIT ReturnResult}

-- The Components are sequences of data elements.

Invoke ::= SEQUENCE { invokeID InvokeIdType, linkedID [0] IMPLICIT InvokeIdType OPTIONAL, operationCode OPERATION,


parameter ANY DEFINED BY operationCode OPTIONAL}

-- ANY is filled by the single ASN.1 data type following the keyword-- PARAMETER or the keyword ARGUMENT in the type definition of a-- particular operation.

ReturnResult ::= SEQUENCE { invokeID InvokeIdType, result SEQUENCE { operationCode OPERATION, parameter ANY DEFINED BY operationCode } OPTIONAL }

-- ANY is filled by the single ASN.1 datatype following the keyword-- RESULT in the type definition of a particular operation.

ReturnError ::= SEQUENCE { invokeID InvokeIdType, errorCode ERROR, parameter ANY DEFINED BY errorCode OPTIONAL}

-- ANY is filled by the single ASN.1 data type following the keyword-- PARAMETER in the type definition of a particular error.

Reject ::= SEQUENCE { invokeID CHOICE { derivable InvokeIdType, not-derivable NULL}, problem CHOICE { generalProblem [0] IMPLICIT GeneralProblem, invokeProblem [1] IMPLICIT InvokeProblem, returnResultProblem [2] IMPLICIT ReturnResultProblem, returnErrorProblem [3] IMPLICIT ReturnErrorProblem}}

InvokeIdType ::= INTEGER(-128..127)

-- PROBLEMS.

GeneralProblem ::= INTEGER {unrecognizedComponent (0), mistypedComponent (1), badlyStructuredComponent (2)}(0..127)

InvokeProblem ::= INTEGER {duplicateInvokeID (0), unrecognizedOperation (1), mistypedParameter (2), resourceLimitation (3), initiatingRelease (4), unrecognizedLinkedID (5), linkedResponseUnexpected (6), unexpectedLinkedOperation (7)}(0..127)

ReturnResultProblem ::= INTEGER {unrecognizedInvokeID (0), returnResultUnexpected (1), mistypedParameter (2)} (0..127)

ReturnErrorProblem ::= INTEGER {unrecognizedInvokeID (0), returnErrorUnexpected (1), unrecognizedError (2), unexpectedError (3), mistypedParameter (4)} (0..127)END -- TCAPMessages


7.1.2. Definition of the BCAP operations (SIEMENS specific)

BCAP-Protocol -- {Siemens specific} , issue 08.02.98

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

IMPORTS Number, ScpDialogData FROM Add-TCAP-Information

OPERATION, ERROR FROM TCAPMessages {ccitt(0) recommendation q 773 modules(2)messages(1) version2(2)};

--===================================================================-- TYPE DEFINITIONS FOR OPERATIONS--===================================================================

-- Specification of SetUp-- ======================-- Direction: OLEX -> DLEX-- Class: 1-- Timer: BCAP-T1-- Purpose: to be providedSetUp ::= OPERATION ARGUMENT SetUpArg RESULT ERRORS { CalledAccessNonVpn, ShortPeriodDenial, LongPeriodDenial }

-- Specification of Connect-- ========================-- Direction: DLEX -> OLEX-- Class: 4-- Purpose: to be providedConnect ::= OPERATION ARGUMENT ConnectArg

-- Specification of Release-- ========================-- Direction: OLEX -> DLEX and DLEX -> OLEX-- Class: 4-- Purpose: to be providedRelease ::= OPERATION ARGUMENT ReleaseArg

-- Specification of VpnFacility-- ============================-- Direction: OLEX -> DLEX and DLEX -> OLEX-- Class: 4-- Purpose: to be providedVpnFacility ::= OPERATION ARGUMENT VpnFacilityArg

-- Specification of ActivityTest


-- =============================-- Direction: OLEX -> DLEX-- Class: 3-- Timer: BCAP-T2-- Purpose: to be providedActivityTest ::= OPERATION RESULT -- BOOLEAN ERRORS {}

--===================================================================-- TYPE DEFINITIONS FOR ERRORS--===================================================================

CalledAccessNonVpn ::= ERRORShortPeriodDenial ::= ERRORLongPeriodDenial ::= ERROR

--===================================================================-- TYPE DEFINITIONS FOR ARGUMENT DATA--===================================================================

SetUpArg ::= SEQUENCE { calledPartyNumber [0] Number, callingPartyNumber [1] Number OPTIONAL, vpnTransport [2] VpnTransport OPTIONAL, genericPartyNumber [3] Number OPTIONAL, bearerCapability [4] BearerCapability OPTIONAL, inCounter [5] InCounter OPTIONAL, scpDialogData [6] ScpDialogData OPTIONAL, applicationID [7] ApplicationID OPTIONAL, ... }

ConnectArg ::= SEQUENCE { vpnTransport [0] VpnTransport OPTIONAL, connectedNumber [1] Number OPTIONAL, applicationID [2] ApplicationID OPTIONAL, ... }

ReleaseArg ::= SEQUENCE { cause [0] Cause, vpnTransport [1] VpnTransport OPTIONAL, applicationID [2] ApplicationID OPTIONAL, ... }

VpnFacilityArg ::= SEQUENCE { vpnTransport [0] VpnTransport OPTIONAL, applicationID [1] ApplicationID OPTIONAL, ... }

--===================================================================-- TYPE DEFINITIONS FOR DATA--===================================================================

Cause ::= OCTET STRING (SIZE(1..maxCauseLength)) -- The number is codes as described in itu-t recommendation q850.

VpnTransport ::= OCTET STRING (SIZE(1..maxVpnTransportLength)) -- The number is codes as described in itu-t recommendation q763.


BearerCapability ::= OCTET STRING (SIZE(1..maxBearerCapability))

InCounter ::= INTEGER (0..5)

ApplicationID ::= INTEGER {qsig(0), internet(1), isci(2), teleworking(3) }(0..16)--===================================================================-- DEFINITIONS OF RANGE CONSTANTS--===================================================================

maxCauseLength INTEGER ::= 10

maxVpnTransportLength INTEGER ::= 2048

maxBearerCapability INTEGER ::= 12

--===================================================================-- DEFINITION OF OBJECT IDENTIFIER PATH--===================================================================

-- local values are used

--===================================================================-- ASSIGNMENTS FOR OPERATION VALUES--===================================================================

setUp SetUp ::= localValue 11

connect Connect ::= localValue 12

release Release ::= localValue 13

vpnFacility VpnFacility ::= localValue 14

activityTest ActivityTest ::= localValue 15

-- local value for in data moved to ADD-TCAP

--===================================================================-- ASSIGNMENTS FOR ERROR VALUES--===================================================================

calledAccessNonVpn CalledAccessNonVpn ::= localValue 17shortPeriodDenial ShortPeriodDenial ::= localValue 18longPeriodDenial LongPeriodDenial ::= localValue 19

END -- BCAP-Protocol


7.1.3. Definition of the MWI service - Message Waiting Indication (standard)

MWITC --MWI-Protocol {ccitt identified-organization etsi(0) 754 modules(2) -- operations-and-errors(1) version1(1)} -- issue 08.02.98

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

IMPORTS Number,ScpDialogData FROM Add-TCAP-Information

OPERATION, ERROR FROM TCAPMessages {ccitt recommendation q 773 modules(2) messages(1) version2(2)};

-- BasicService -- FROM BASICSER -- {ccitt identified-organization etsi(0) 196 basic-service-elements(8)};

--operation types

MWISet ::= OPERATION PARAMETER SEQUENCE { receivingUserNumber Number, controllingUserNumber Number, basicService BasicService, numberOfMessages [1] MessageCounter OPTIONAL, time [2] GeneralizedTime(SIZE(0..50)) OPTIONAL, contUserProvidedNumber [3] Number OPTIONAL, mode [4] InvocationMode OPTIONAL, messageIdentity [5] MessageIdentity OPTIONAL, scpDialogData [6] ScpDialogData OPTIONAL --,... } RESULT ERRORS { receivingUserNotSubscribed, indicationNotDelivered, supplementaryServiceInteraction, resourceUnavailable, maxNumOfControllingUsersReached, maxNumOfActiveInstancesReached, invalidReceivingNumber, invalidControllingNumber --,... }--Timer T = MWI-Tsup-- End of MWISet operation definition

MWIReset ::= OPERATION PARAMETER SEQUENCE { receivingUserNumber Number, controllingUserNumber Number, basicService BasicService, mode [1] InvocationMode OPTIONAL, scpDialogData [2] ScpDialogDataOPTIONAL --,... } RESULT


ERRORS { receivingUserNotSubscribed, indicationNotDelivered, supplementaryServiceInteraction, resourceUnavailable, invalidReceivingNumber, invalidControllingNumber --,... }--Timer T = MWI-Tsup-- End of MWIReset operation definition

--error type definitionsReceivingUserNotSubscribed ::= ERRORIndicationNotDelivered ::= ERRORInvalidControllingNumber ::= ERRORInvalidReceivingNumber ::= ERRORSupplementaryServiceInteraction ::= ERRORResourceUnavailable ::= ERRORMaxNumOfControllingUsersReached ::= ERRORMaxNumOfActiveInstancesReached ::= ERROR

--constants and data type definitions

-- mod 26.5.97: Called/CallingPartyNumber durch Number ersetzt

MessageCounter ::= INTEGER (0..65535)

InvocationMode ::= ENUMERATED { deferred (0), immediate (1), combined (2)}

MessageIdentity ::= SEQUENCE { messageRef MessageRef, status MessageStatus}

MessageRef ::= INTEGER (0..65535)

MessageStatus ::= ENUMERATED { addedMessage (0), removedMessage (1)}

BasicService ::= ENUMERATED { allServices (0), speech (1), unrestrictedDigitalInformation (2), audio3k1Hz (3), unrestDigitalInformationWithTonesAndAnnouncements (4), multirate (5), telephony3k1Hz (32), teletex (33), telefaxGroup4Class1 (34), videotexSyntaxBased (35), videotelephony (36), telefaxGroup2-3 (37), telephony7kHz (38), eurofileTransfer (39), fileTransferAndAcessManagement (40)}

-- object identifier path


mWIOID OBJECT IDENTIFIER ::= {ccitt identified-organizationetsi(0) 754 operations-and-errors(1)}

-- operation values

mWISet MWISet ::= globalValue:{mWIOID 1}mWIReset MWIReset ::= globalValue:{mWIOID 2}

-- error values

receivingUserNotSubscribed ReceivingUserNotSubscribed ::=globalValue:{mWIOID 10}invalidControllingNumber InvalidControllingNumber ::=globalValue:{mWIOID 11}invalidReceivingNumber InvalidReceivingNumber ::=globalValue:{mWIOID 12}indicationNotDelivered IndicationNotDelivered ::=globalValue:{mWIOID 13}supplementaryServiceInteraction SupplementaryServiceInteraction ::=globalValue:{mWIOID 14}resourceUnavailable ResourceUnavailable ::=globalValue:{mWIOID 15}maxNumOfControllingUsersReached MaxNumOfControllingUsersReached ::=globalValue:{mWIOID 16}maxNumOfActiveInstancesReached MaxNumOfActiveInstancesReached ::=globalValue:{mWIOID 17}

END -- of MWI OPerations and Errors



7.2. Appendix 2: SCCP/TCAP database (EWSD system)

This appendix contains an example of a database for SCCP and TCAP in the SiemensEWSD system, which assigns “Code Points” for the ISS services, therefore enabling thecarrying of information relating to services such as the CCBS, CCNR, MWI, etc.Obviously, the meaning of only some parameters is described here as an exhaustiveexplanation can be found in the appropriate manuals.

BGA:BGA:DISPC7OP;BGA:BGA:CCS7 -- DISPLAY SIGN. ELEMENTS -- OWN SIGNALING POINTBGA:BGA:SPC NETIND STPI SDL SPCSIZE SENDTFPBGA:-------------+------+----+---+--------+-------BGA:0- 0-0 INAT0 STP 62 NORMAL ONBGA: 0-0- 0-0 NAT0 STP 272 NORMAL ONBGA: 0- 0- 0 NAT1 STP 62 EXTENDED ONBGA:

The command CR C7OP enables the actual identification of the exchange to be defined forthe rest of the signaling network, allocating it an SPC (or OPC, in this case).The meaning of the parameters is as follows:

SPC = Signaling Point Code: this is the OPC that is actually assigned at the point of thenetwork in which we are, normally of the x-y-z-w type.

NETIND = Network Indicator: this parameter enables the selection of one of four possiblesignaling networks. These networks have standard ITU-T identifications, which are: NAT0,NAT1, INAT0 and INAT1.

STPI = Signaling Transfer Point Indicator: this parameter indicates the type of network nodethat we are defining, i.e. whether it is an SP or an STP (see the definition on Page 8).

SDL = Supported Data Length: specifies the maximum size of the “user part” of the MSUframes of the MTP (SIF field), with the value 272 as the default (see Page 13).

SPCSIZE = SPC Size: specifies whether the dimension of the SPC used is the ITU-Tstandard 14 bits (NORMAL), 24 bits ANSI (EXTENDED), or if this does not carry out mappingof the formats (ITU14MP, ANSI24MP, and others).

BGA:DISPC7DP:DPC=X,NETIND=NAT0;BGA:BGA:CCS7 -- DISPLAY SIGN. ELEMENTS -- DESTINATION POINTBGA:BGA:DPC NETIND OST ESTBGA:-------------+------+---+---BGA: 0-0- 0-1 NAT0 ACT ACTBGA: 0-0- 0-2 NAT0 ACT UNABGA: 0-0- 0-4 NAT0 ACT ACTBGA: 0-0- 0-6 NAT0 ACT ACTBGA:15-7-15-3 NAT0 ACT ACTBGA:

The command (CR/MOD/DISP) C7DP enables the specification of the SPC destination(DPCs) in relation to our network node (OPC). These DPCs may be internal to the exchangeitself or external.The STPs can also be specified for where routing may be carried out in order to reach theintended destination, indicating a linked sequence of DPCs eg. DPC=0-1-7-3&0-6-4-2&...


/**********************************************************************//* INTRODUCTION OF SCCP COMMON SERVICE DATA *//**********************************************************************/

ENTR SCDATA: SPC=O-O-O-O,NETIND=NAT0,MXMSGLEN=255,PROTCL=CL0&CL1;

The command ENTR SCDATA enables several basic values to be specified for thefunctioning of the SCCP for each of the four configurable networks (NAT0, NAT1, etc.),namely:

GTFRMT = Global Title Format: specifies the Global format used with the default equalingGT14, the format used in the international networks (the various existing formats areillustrated in Chapter 3.4.2).

SCCLSR = SCCP Segmenting/Reassembly: specifies whether our network is according BlueBook (which does not permit segmentation/reassembly) or according White Book.

MXMSGLEM = Maximum Message Length: specifies the maximum length of the “user part” inUDT (Unitdata) and XUDT (Extended UDT) messages. If a message passed to the SCCPexceeds this value, it is segmented and transmitted in several parts (if our network isaccording White Book).

PROTCL = Protocol Class: specifies the class of protocol of the SCCP supported by thenetwork, from CL0 to CL3; in this example we specify that our network supports the twoconnectionless classes (connectionless basic and connectionless-sequenced).

/**********************************************************************//* CREATION OF SS#7 USERS ASSOCIATION *//**********************************************************************/

CR C7USER: USNAME=SCCP, DPC=0-0-0-1, NETIND=NAT0, ACS=NO;

BGA:BGA:DISPC7USER:DPC=0-0-0-1,NETIND=NAT0;BGA:BGA:CCS7 -- USER RELATED DATABGA:BGA:DPC NETIND USNAME PCMTYP ACS ASSIGNBGA:--------------+--------+--------+--------+-------+---------BGA: 0-0- 0-1 NAT0 ISUP DIU30BGA: 0-0- 0-1 NAT0 SCCP NODIU NOBGA:

The command CR C7USER enables an MTP user to be associated with a particular DPC.The following parameters are of particular significance:

USNAME = User Name: can be the ISUP, SCCP or the TUP.

PCMTYP = PCM Type: specifies the type of PCM, DIU30 (Europe) or DIU24 (USA).

ACS = Association required: specifies whether the association of several links (Y/N) isrequired.

/**********************************************************************//* CREATION OF SCCP USERS *//**********************************************************************/

CR SCUSER: SSID=ISS, SSN=11, NETIND=NAT0, GTFRMT=GTI4,TCAPUS=YES;

BGA:DISPSCUSER:SSID=X,NETIND=NAT0;


BGA:BGA:SCCP USER INFORMATIONBGA:BGA:NETIND SSID SSN GTFRMT TCAPUSBGA:------+--------+---+------+------BGA:NAT0 IN3 241 GTI4 YBGA:NAT0 ISS 11 GTI4 YBGA:

The command SCUSER allows the definition of a SCCP user and the establishment of arelationship between that user (quoted as SSID, Subsystem ID) and an SSN standard(Subsystem Number, see Page 19).In practice, with this command we can define the applications (private or standard) that usethe SSCP in our network. It should be noted that when we define standard applications, theSSN should also be complied with that standard; in the opposite case the application will onlywork properly in our network.In this specific example, we are defining two SCCP users: the user IN3, to which we assignSSN 241 (proprietary application), and the user ISS which corresponds to the standard SSNNo. 11 (see Page 19).

Other parameters:

GTFRMT = Global Title Format: specifies that of the Global Title format used, by default beingequal to GT14 (format used in the international networks).

TCAPUS = TCAP User: specifies whether or not the SSID defined is a user of the TCAP(Y/N).

ENTR SCTTCD:TTID=IEESS, NETIND=NAT0, TTN=17;BGA:BGA:DISPSCTTCD:TTID=X,NETIND=NAT0;BGA:BGA:TRANSLATION TYPE INFORMATIONBGA:BGA:NETIND TTID TTNBGA:------+--------+----BGA:NAT0 UNKNOWN 0BGA:NAT0 IMSI 0BGA:NAT0 CCV 0BGA:NAT0 SMS 0BGA:NAT0 INDD 0BGA:NAT0 INCGPA 0BGA:NAT0 INPPDD 0BGA:NAT0 IEESS 17BGA:NAT0 ITCC 0BGA:NAT0 TT9 0BGA:NAT0 TT10 0BGA:NAT0 TT11 0BGA:NAT0 TT12 0BGA:NAT0 TT13 0BGA:NAT0 TT14 0BGA:NAT0 TT15 0BGA:NAT0 TT16 0BGA:NAT0 TT17 0BGA:NAT0 TT18 0BGA:NAT0 TT19 0BGA:NAT0 TT20 0BGA:NAT0 TT21 0BGA:NAT0 TT22 0BGA:NAT0 TT23 0BGA:NAT0 TT24 0BGA:NAT0 TT25 0BGA:NAT0 TT26 0BGA:NAT0 TT27 0


BGA:NAT0 TT28 0BGA:NAT0 TT29 0BGA:NAT0 TT30 0BGA:NAT0 TT31 0BGA:

The command SCTTCD specifies the form in which the Global Title is translated in networkaddresses. We should recall that the Global Title may contain several fields, depending onthe GTI, so it is necessary to specify the type of translation to be carried out. One of theGlobal Title fields is precisely the TTID (Translation Type Identifier). In this example only theTTID=7 (defined as IEESS, ISDN End to End Supplementary Services) contains information,corresponding to the TTN (Translation Type Number) equal to 17.

/**********************************************************************//* CREATION OF SCCP SUBSYSTEM *//**********************************************************************/

CR SCSS: SSID=ISS, SPC=0-0-0-0, NETIND=NAT0; /* OPC */CR SCSS: SSID=ISS, SPC=0-0-0-1, NETIND=NAT0, SASPR=YES;

CONF SCSS: SSID= ISS, SPC=0-0-0-1, NETIND=NAT0, OST=ACT;

BGA:BGA:DISPSCSS:NETIND=NAT0,SSID=ISS;BGA:BGA:SUBSYSTEM INFORMATIONBGA:BGA:NETIND SPC SSID LB SCMG SASPR OST RBLSTBGA:------+-------------+--------+--+----+-----+---+------BGA:NAT0 0-0- 0-0 ISS Y Y Y ACTBGA:NAT0 0-0- 0-1 ISS Y Y Y ACTBGA:

The command CR SCSS enables the creation of a subsystem associated with an SPC. Thesubsystem is created by using the parameter SSID, previously associated with an SSN viathe command CR SCUSER. This command is essentially directed towards the SCCPmanagement processes, not described in this document.Meanwhile, the subsystems created must be put into active status via the command CONFSCSS, (except if the SPC is the actual OPC).The meaning of the remaining parameters is as follows:

SCMG = SCCP Management: specifies whether management of the status of the subsystemis required (Y/N).

LB = Local Broadcast: specifies whether the remaining subsystems should be notified of thestate changes of the created subsystem.

SASPR = Subsystem available after SPC restart: specifies whether the subsystem shouldremain active after a “Restart” process.

CR SCCGPA: SSID=ISS,NETIND=NAT0, RTGP=PROG, TTID=IEESS, NP=ISDNTNP,# NA=NATNO, GTDIG=12000034;

BGA:BGA:BGA:DISPSCCGPA:SSID=X,NETIND=NAT0;BGA:BGA:CALLING PARTY ADDRESSBGA:BGA:NETIND SSID RTGP ISPC IGT TTID NP NA GTDIGBGA:-------+---------+-----+----+----+---------+---------+---------+--------BGA:NAT0 IN3 SPC N N UNKNOWN UNKNOWN UNKNOWNBGA:NAT0 ISS PROG N N IEESS ISDNTNP NATNO 12000034BGA:


The command CR SCCGPA creates a Calling Party Address, that is, a unique identificationfor the local subsystem. This identification can be a combination of several types of possibleaddresses in the SCCP (SPC, GT or SSN), and this combination is defined by the parameterRTGP (Routing Preference). The relevant parameters are as follows:

SSID = the identifier of the subsystem previously created.

RTGP = Routing Preference: can be SPC, GT or PROG (programmed).

ISPC = Include Signaling Point: specifies whether the SPC should be included in the CallingParty Address.

NA = Nature of Address: specifies the “Nature of Address” of the number defined, NATNO-National Number, INTNO-International Number, etc.

NP = Numbering Plan: numbering plan for the number defined, ISDNTNP-ISDN TelephonyNP, ISDNMNP-ISDN mobile NP, etc.

GTDIG = Global Title Digits: can be a Country Code, a LAC, a subscriber number, etc.

/**********************************************************************//* CREATION OF GLOBAL TITLE TRANSLATION DIGIT TREE *//**********************************************************************/

CR GTDIGTR: TRID=ISS, TTID=IEESS, NP=ISDNTNP, NA=NATNO;

BGA:DISPGTDIGTR:TRID=X;BGA:BGA:TRID TTID NP NABGA:-------------+---------+---------+--------BGA:ISS IEESS ISDNTNP NATNOBGA:INTISS IEESS ISDNTNP INTNOBGA:

The command CR GTDIGTR enables the conversion table that permits the SCCP to converta Global Title into an SPC, that is, an address that is recognizable by the MTP.The parameters are:

TRID = Translator identification: a symbolic name that we attribute to the conversion table.Note: in the above example, the first TRID is called ISS, but may be called anything else (notrelated to the SSID=ISS parameter that we saw previously)

TTID, NP, NA : see previous descriptions.

/**********************************************************************//* CREATION OF GLOBAL TITLE TRANSLATION CODE POINTS *//**********************************************************************/

CR GTCPT: TRID=ISS, GTDIG=12000034;CR GTCPT: TRID=ISS, GTDIG=26;CR GTCPT: TRID=ISS, GTDIG=801;CR GTCPT: TRID=ISS, GTDIG=802;CR GTCPT: TRID=ISS, GTDIG=803;........................................BGA:BGA:DISPGTCPT:TRID=X;BGA:BGA:TRID GTDIG DICON NP NA TTID NDBGA:------------+--------+-------------+--------+--------+--------+------BGA:ISS 12000034 NATOWN


BGA:ISS 26 NATOWNBGA:ISS 801 NATOWNBGA:ISS 802 NATOWNBGA:ISS 803 NATOWNBGA:ISS 804 NATOWNBGA:ISS 805 NATOWNBGA:ISS 806 NATOWNBGA:ISS 807 NATOWNBGA:ISS 808 NATOWNBGA:ISS 811 NATOWNBGA:ISS 812 NATOWNBGA:ISS 813 NATOWNBGA:ISS 814 NATOWNBGA:ISS 815 NATOWNBGA:ISS 816 NATOWNBGA:ISS 817 NATOWNBGA:ISS 818 NATOWNBGA:ISS 82 NATOWNBGA:ISS 83 NATOWNBGA:ISS 880 NATOWNBGA:ISS 890 NATOWNBGA:INTISS 11248 ..... NATNO NATOWNBGA:INTISS 248 NATOWNBGA:INTISS 49 +11 NATOWNBGA:

The command CR GTCPT creates the code points for translating the Global Titles. We areconfining ourselves here to items from the table previously created (which we called ISS),with the addresses that we are trying to reach, in this case typically LACs (the Local AreaCodes for those not familiar with this term).

CR GTDEST: TRID=ISS, GTDIG=12000034, DPC=0-0-0-0, ROUTE=INTERNAL, NI=NAT0;CR GTDEST: TRID=ISS, GTDIG=26, DPC=0-0-0-0, ROUTE=INTERNAL, NI=NAT0;CR GTDEST: TRID=ISS, GTDIG=801, DPC=0-0-0-0, ROUTE=INTERNAL, NI=NAT0;CR GTDEST: TRID=ISS, GTDIG=802, DPC=0-0-0-0, ROUTE=INTERNAL, NI=NAT0;..................CR GTDEST: TRID=ISS, GTDIG=811, DPC=0-0-0-1, ROUTE=INTERNAL, NI=NAT0;CR GTDEST: TRID=ISS, GTDIG=812, DPC=0-0-0-1, ROUTE=INTERNAL, NI=NAT0;....................................BGA:BGA:TRID : ISSBGA:BGA:GTDIG RTGP ROUTE SSID PPN NI DPCBGA:--------+------+--------+--------+---+-------+------------BGA:12000034 INTERNAL UNKNOWN NAT0 0-0- 0-0BGA:12111134 INTERNAL UNKNOWN NAT0 0-0- 0-1BGA:26 INTERNAL UNKNOWN NAT0 0-0- 0-0BGA:801 INTERNAL UNKNOWN NAT0 0-0- 0-0BGA:802 INTERNAL UNKNOWN NAT0 0-0- 0-0BGA:803 INTERNAL UNKNOWN NAT0 0-0- 0-0BGA:804 INTERNAL UNKNOWN NAT0 0-0- 0-0BGA:805 INTERNAL UNKNOWN NAT0 0-0- 0-0BGA:811 INTERNAL UNKNOWN NAT0 0-0- 0-1BGA:812 INTERNAL UNKNOWN NAT0 0-0- 0-1BGA:813 INTERNAL UNKNOWN NAT0 0-0- 0-1BGA:814 INTERNAL UNKNOWN NAT0 0-0- 0-1BGA:815 INTERNAL UNKNOWN NAT0 0-0- 0-1

Finally, the command CR GTDEST associates the Global Titles with the DPCs. Thesedestinations can be of several types: LTG in the actual exchange, internal routing in the actualexchange, external network, etc.This command has an enormous number of parameter combinations, depending on the typeof routing, so we are not concerned with them here.

SS7

Documents

mtp message transfer

message structure

transfer syntax

encoding of tcap messages

siemens sa bu net ds2221

network sublevel

link control sublevel

bearer related connections