SS7

THE SIGNALLING SYSTEM N 7 AND ITS APPLICATIONS
Jos Velez
BU NET DS22 SIEMENS S.A. (PORTUGAL)
Jos Velez, SIEMENS SA BU NET DS22
1. 2.
INTRODUCTION.......................................................................................................................... 4 THE SIGNALING SYSTEMS...................................................................................................... 5 2.1. 2.2. THE DEVELOPMENT OF THE SIGNALING SYSTEMS ..................................................................... 5 SOME NOTES ON OSI ARCHITECTURE ....................................................................................... 5
3.
THE N 7 SIGNALING SYSTEM................................................................................................ 8 3.1. THE SIGNALING NETWORK ........................................................................................................ 8 3.2. THE STRUCTURE OF THE SS#7 PROTOCOLS ............................................................................... 9 3.3. MTP (MESSAGE TRANSFER PART) ......................................................................................... 12 3.3.1. MTP: physical sublevel.................................................................................................. 12 3.3.2. MTP: signaling link control sub-level............................................................................ 12 3.3.3. MTP: network sub-level ................................................................................................. 13 3.4. SCCP (SIGNALING CONNECTION CONTROL PART)................................................................. 16 3.4.1. SCCP: message structure............................................................................................... 16 3.4.2. SCCP: addressing .......................................................................................................... 19 3.5. TCAP (TRANSACTION CAPABILITIES APPLICATION PART)..................................................... 24 3.5.1. Bearer related connections versus bearer unrelated connections ........................ 24 3.5.2. Characterization of the TCAP........................................................................................ 24 3.5.3. Structure of the TCAP messages .................................................................................... 25 3.5.4. A specific application example: the CCBS..................................................................... 27 3.5.5. The encoding of TCAP messages ................................................................................... 28 3.6. ASN.1 NOTATION (ABSTRACT SYNTAX NOTATION NO.1)...................................................... 30 3.6.1. Abstract syntax............................................................................................................... 30 3.6.2. Transfer syntax............................................................................................................... 36 3.6.3. Practical use .................................................................................................................. 39
4.
USERS OF SS#7........................................................................................................................... 44 4.1. 4.2. 4.3. 4.4. ISS (ISDN SUPPLEMENTARY SERVICES) ................................................................................ 44 INAP (INTELLIGENT NETWORKS APPLICATION PART) ........................................................... 46 MAP (MOBILE APPLICATION PART)....................................................................................... 48 CAP (CAMEL APPLICATION PART) ...................................................................................... 50
5. 6.
LIST OF ACRONYMS ............................................................................................................... 51 BIBLIOGRAPHY ........................................................................................................................ 53 6.1. 6.2. ITU-T RECOMMENDATIONS ................................................................................................... 53 OTHER DOCUMENTS................................................................................................................ 53
7.
APPENDICES.............................................................................................................................. 54 7.1. APPENDIX 1: ASN.1 MODULES ............................................................................................... 54 7.1.1. Definition of TCAP messages (standard)....................................................................... 54 7.1.2. Definition of the BCAP operations (SIEMENS specific)................................................ 57 7.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 ........................................................................................ 5 Figure 2: Application Level. Generic ASEs................................................................................ 7 Figure 3: Association modes...................................................................................................... 8 Figure 4: SS#7 protocols stack .................................................................................................. 9 Figure 5: MTP levels ................................................................................................................ 12 Figure 6: MTP frames .............................................................................................................. 12 Figure 7: MTP SIO field ........................................................................................................ 13 Figure 8: MTP SIF fields ....................................................................................................... 14 Figure 9: Structure of an SPC.................................................................................................. 15 Figure 10: Basic structure of the SCCP messages ................................................................. 16 Figure 11: SCCP, format of the mandatory fixed part.............................................................. 16 Figure 12: SCCP, format of the mandatory variable part ........................................................ 17 Figure 13: SCCP, format of the optional part........................................................................... 17 Figure 14: SCCP, addresses format........................................................................................ 20 Figure 15: SCCP, UDT message............................................................................................. 21 Figure 16: SCCP, coding of the field address indicator ........................................................ 21 Figure 17: SCCP, coding of the field global title indicator ..................................................... 21 Figure 18: SCCP, coding of the field numbering plan ........................................................... 22 Figure 19: SCCP, coding of the field encoding scheme ........................................................ 22 Figure 20: SCCP, coding of the field translation type............................................................ 22 Figure 21: Flow of the CCBS service....................................................................................... 27 Figure 22: TLV sequence......................................................................................................... 36 Figure 23: Tag coding (if less than 30) ................................................................................... 36 Figure 24: Tag coding for values higher than 30 ..................................................................... 37
Tables Table 1: MTP SIO fields........................................................................................................ 14 Table 2: SCCP message types................................................................................................ 18 Table 3: Optional SCCP parameters ...................................................................................... 19 Table 4: SSNs currently specified............................................................................................ 19 Table 5: Class of operation in the TCAP ................................................................................. 26 Table 6: Class coding .............................................................................................................. 37 Table 7: Type coding (P/C bit) ................................................................................................. 37 Table 8: Codes allocated to Universal-type classes ................................................................ 38
1. Introduction
Particularly in applications developed during recent years and based on concepts such as transaction or association, No. 7 signaling has frequently been a factor that has caused confusion. These concepts have been assuming a major role in applications developed in the last few years, both within the area of additional services for the traditional fixed network and in areas as diverse as Intelligent Networks (IN), mobile networks and, more recently, services oriented towards the Internet. This document does not set out to be a treatise on these matters, rather it seeks simply to be an aid to those wishing to develop applications in this area, or merely to acquire a knowledge of it. Caveat: this document was originally aimed at colleagues who are collaborating or who will be collaborating in the DS2 2 work-group (Siemens Portugal), so special emphasis is given to the 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 the structure of No. 7 signaling (SS#7); there then follows a description of the standard language ASN.1 (Abstract Syntax Notation n 1), as this is a pre-requisite for understanding the applications. 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 some appendices which are particularly useful for those currently working in this area.
Alfragide, September 1999
2. The signaling systems

2.1. The development of the signaling systems
The 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 first telephone networks created more than one hundred years ago, but it is important to state that all modern signaling systems are of the out of band type, that is, signaling is carried via the network on dedicated channels (signaling channels), logically independent of the channels for carrying voice/data (bearer channels). These systems, known as common channel signaling, enable not only faster transmission of information, but they also have the additional advantage of enabling the establishment of signaling links, without previously occupying a voice channel. Being out of band systems, they are obliged to carry out an advance check of the continuity of the voice channel (cross-office check).
Exchange A Exchange B
Signaling c hannels
Voice/data channels
Figure 1: Common channel signaling
In the early 1970s, AT&T developed a common mode channel signaling system, called Common Channel Interoffice Signaling, subsequently standardized by the ITU with the name No. 6 Signaling System. This system used 336-bit frames (?!..) which were transmitted on analog lines at 200 bps using PSK modulation. Meanwhile, with the development of the open system concept, and originating from the wellknown OSI levels (in parallel with packet networks based on HDLC type frames becoming commonplace), in the early eighties the ITU defined a new digital signaling system based on packets, the No. 7 Signaling System (SS#7 for short). The main virtue of this system is the fact that that it has been designed with several levels which although not strictly following the OSI structure are, up to a certain point, compatible with it. More important still: it has been divided into various parts which enable it to support several types of connection. But we will be moving on to this later .
2.2. Some notes on OSI architecture

A less well-known aspect of OSI architecture, beyond the well know level definition, is the identification of certain functional blocks in level 7 (Application). Therefore the concept of the Application Service Element (ASE) is defined as a sub-application in level 7 which can be used by other applications.
This definition can be better illustrated by taking as an example a generic client-server application: 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 well certainly have dedicated functions for transfer/ file management, etc. The point to be emphasized is that all these functions will, in principle, be accessible to the different applications that run on both platforms. The functions referred to quite rightly constitute the generic ASEs identified in level 7 of the OSI architecture, as follows: ACSE (Association Control Service Element) This defines the communication and dialog primitives for establishing and terminating an association between remote applications. One example: let us suppose that we are trying to implement software for a TELNET like application; the combination of routines responsible for controlling the association between the terminal and the host constitute the ACSE. ROSE (Remote Operations Service Element) This defines the primitives, dialogs and state machine for the carrying out of remote operations. The TCAP (which we will discuss later) is an example of implementation partially aligned with the ROSE. RTSE (Robust Transfer Service Element) This ASE defines the primitives and the dialogs for secure data transfer between remote applications. A specific example of a RTSE is the FTAM system (IBM).
Application Level (7) Application X

ACSE
Application Level (7) Application X

ACSE
Application Y
RTSE
Application Y
RTSE
ROSE
ROSE
Presentation Level (6) Session Level (5) Transport Level (4) Protocols Network Level (3) Data Link Level (2) Physical Level ( )
Presentation Level (6) Session Level (5) Transport Level (4) Network Level ( ) Data Link Level (2) Physical Level ( )
Figure 2: Application Level. Generic ASEs Two additional notes on the OSI nomenclature: Basic operations (messages) exchanged between adjacent levels or between equivalent levels between two remote points (peer levels) are designated as communication primitives. 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 levels they are designated as Application Protocol Data Units (APDUs).
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, the following 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) for signaling message routing tasks, characterized by a high speed/capacity processing. May or may not be the origin or destination of messages. In SS#7, we designate as mode of association the relationship between the physical connection 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.
Exchange A Exchange B
Signaling
Associated Mode
Voice/data
SP
SP
Voice/data
Exchange C
STP
Quasi-Associated Mode
Signaling
SP STP
Figure 3: Association modes (There is a third mode not supported by SS#7, designated as non-associated mode in which the routing may vary dynamically in an adaptive form, depending on the traffic).
3.2.
The structure of the SS#7 protocols
The structure of the SS#7 protocols in their initial form contained only three functional blocks known as parts. The first covered the functions corresponding with the three basic OSI levels (Physical, Data Link and Network) and the two remaining blocks, somehow equivalents to levels 4 and 7 (Transport and Application), incorporated the network applications existing at the time. They were the TUP (Telephone User Part) for telephone Call Control, 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 todays architecture, illustrated here:
INAP
MAP
OAMP
ISS
CAP
TCAP (Level 7 OSI)
ISUP
TUP
SCCP (Level 3 OSI) MTP
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 a connectionless 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 the counterpoint in the network to ISDNs subscriber signaling, the DSS1. SCCP (Signaling Connection Control Part) this completes the level 3 OSI, expanding the addressing capabilities of the MTP and providing connectionless and connection oriented services. TCAP (Transaction Capabilities Application Part or TC for short) provides support for real time 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 communication protocol between the SSP and the SCP in an Intelligent Network architecture. MAP (Mobile Application Part) user of the TCAP, provides support for communication between the databases of the mobile networks, namely in the GSM system.
OAMP (Operation, Administration and Maintenance Part) user of the TCAP, provides support 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 the standard 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 on No Reply). CAP (CAMEL Application Part) provides support for the implementation of the I.N. in the mobile 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 mobile networks. 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 users INAP, ISS, etc.
10
11
3.3.
MTP (Message Transfer Part)
The MTP provides functions that are equivalent to the first three OSI levels (Physical, Data Link and Network) and its internal structure coincides exactly with this division:
MTP - Level 3 (network) MTP - Level 2 (data link) MTP - Level 1 (physical) 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 following features: 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 carried out via HDLC type frames and as such the frames are signaled by flags filled 01111110; the technique of bit stuffing is used to avoid the accidental appearance of this pattern in the frame 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, the network level) and there are three types only, differentiated by the content of the user part, which are the following:
FISU
flag BSN BIB FSN FIB LI spare CRC
LSSU
flag
BSN
BIB
FSN
FIB
LI
spare
STATUS
CRC
MSU
flag
BSN
BIB
FSN
FIB
LI
spare
SIO
SIF
CRC
Figure 6: MTP frames
12
Key: flag BSN BIB FSN FIB LI spare STATUS SIO SIF CRC synchronization flag, 01111110 Backward Sequence Number Backward Indicator Bit Forward Sequence Number Forward Indicator Bit Length Indicator bits spare Link status Service Information Octet Signaling Information Field (User data) Cyclic Redundancy Check 8 bits 7 bits 1 bit 7 bits 1 bit 6 bits 2 bits 8 or 16 bits 8 bits up to 272 bytes 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, for internal use by the MTP. FISU (Fill-in Signal Unit): intended only to occupy the link in the absence of other information (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 or STPs in the network. It is transported in the user part of the MSU frames (consisting of the SIO and SIF fields), and contains addressing information in the network. In SS#7 terminology the 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 the content of the SIO and SIF fields -> routing label: The SIO field (Service Information Octet) consists of a byte that contains the identification of the message user (the user part of the message). It is defined as follows:
MSU
flag
BSN
BIB
FSN
FIB
LI
spare
SIO
SIF
CRC
Service Indicator
Subservice Field
Figure 7: MTP SIO field
13
The standardized coding of the fields Service Indicator and Subservice Field is as follows: Service Indicator 00h 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah Meaning Network management messages Network testing and maintenance messages Not used SCCP TUP ISUP DUP (circuit related messages) DUP (facility registration and cancellation) MTP testing part B-ISUP (Broad band ISUP) Satellite
Subservice Field 00XXb 01XXb 10XXb 11XXb Table 1: MTP SIO fields
Meaning International Network Not used National Network Reserved for national use
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 its messages are datagrams that must contain the senders addresses (designated in the SS#7 as 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:
MSU
flag
BSN
BIB
FSN
FIB
LI
spare
SIO
SIF
CRC
Routing label (4 bytes)
Heading code (1 byte)
User part (max 267 bytes)
DPC (14 bits)
OPC (14 bits)
SLS (4 bits)
Figure 8: MTP SIF fields As illustrated, the addresses in the MTP occupy 14 bits. These addresses are subdivided in a 3-8-3 bit structure, known as the SPC (Signaling Point Code):
Zone (3 bits)
Area/Network (8 bits)
Signaling Point (3 bits)
14
Figure 9: Structure of an SPC
The coding of these fields is defined jointly by the ITU-T and by the national regulatory bodies. Some years ago, due to the need to expand the addressing possibilities of the MTP in very large 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 of addressing itself which is very important. Therefore, by way of conclusion (and after all these friendly acronyms...), it should be emphasized once again that: The MTP addresses comprise 14 bits (ITU-T), arranged in a 3-8-3 structure known as SPC. There is a 24 bit variant (extended SPC), defined by the ANSI. The MTP supports connectionless connections, and therefore its messages always contain the addresses of the OPC and the DPC.
15
3.4.
SCCP (Signaling Connection Control Part)
With the developments in the dimension and complexity of telecommunications networks, it became clear that the MTPs addressing scheme was inadequate. On the other hand, it became 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 network services 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. The descriptions 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 and connectionless, and the messages used by these two services are structured in accordance with the primitives of the OSI norm (see Chapter 3.2) of the type N-CONNECT_req, NDATA_ind, etc. Mandatory and optional parameters are specified for each primitive. The SCCP messages have the following structure:
Routing information (4 bytes) Message type (1 byte) Mandatory fixed part (variable size) Mandatory variable part (variable size) Optional parameters (variable size) Figure 10: Basic structure of the SCCP messages This structure has some less trivial details, so we shall make some more detailed observations: The mandatory fixed part contains parameters of fixed length, depending on the type of message. The identification of the fixed length parameters is implicit according to the type of message, that is, neither identifiers nor parameter length are present.
Mandatory parameter 1 Mandatory parameter 2 ............... Mandatory parameter N
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
16
the relative distance of the parameter in relation to the pointer. The dimension of each pointer is always one byte.
Pointer to parameter A (1 byte) Pointer to parameter B (1 byte) ............................. Pointer to optional part Parameter A Parameter B ......................
OPTIONAL PART ................. .................
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.
Length of optional parameter X Optional parameter X Length of optional parameter Y Optional parameter Y .......................... 00 (1 byte)
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 the connectionless service and class 2 and 3 support the connection oriented service. In summary, we have:
17
Class 0: basic connectionless service, it doesnt provide flow control There are only two messages for this service: UDT (Unitdata) and XUDT(Extended UDT). Class 1: Connectionless Sequenced service, based on class 1 but permitting additionally data sequence control. Class 2: basic connection oriented service (control of connection establishment and release 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 that overtakes the normal flow (e.g. priority information for network management).
The following tables provide useful information regarding the existing messages and corresponding optional parameters specified for the SCCP:
Message type CONNECTION REQUEST (CR) CONNECTION CONFIRM (CC) CONNECTION REFUSED (CREF) RELEASED (RLSD) RELEASE COMPLETE (RLSD) DATA FORM 1 (DT1) DATA FORM 2 (DT2) DATA ACKNOWLEDGE (AK) UNITDATA (UDT) UNITDATA SERVICE (UDTS) EXPEDITED DATA (ED) EXPEDITED DATA ACKNOWL. (EA) RESET REQUEST (RSR) RESET CONFIRM (RSC) ERROR (ERR) INACTIVITY TEST (IT) EXTENDED UNITDATA (XUDT) EXT. UNITDATA SERVICE (XUDTS) Table 2: SCCP message types Optional parameter End of the optional parameters Destination local reference Source local reference Called party address Calling party address Protocol class Segmentation/reassembly Receive sequence number Sequencing/segmenting Credit Release cause Return cause Reset cause Error cause Refusal cause Data Segmentation
Class prot. 2 and 3 2 and 3 2 and 3 2 and 3 2 and 3 2 3 3 1 and 2 1 and 2 3 3 3 3 2 and 3 2 and 3 0 and 1 0 and 1
Code 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh 10h 11h 12h
Code 00h 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh 10h
18
Hop counter Table 3: Optional SCCP parameters
11h
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 of addressing within the network. For this purpose, two additional forms of addressing have been 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) that identifies a specific application (subsystem) using the SCCP. The SSNs currently defined are as follows:
Subsystem SCCP management Reserved ISUP (ISDN User Part) OAMP (Operation, Adm.& Maint. User Part) MAP (Mobile Application User Part) HLR (Home Location Register) VLR (Visited Location Register) MSC (Mobile Switching Center) EIR (Equipment Identification Register) AUC (Authentication Center) ISS (ISDN Supplementary Services) Reserved for international use Broadband ISDN TCAP test responder Reserved for international use Reserved for national networks Table 4: SSNs currently specified
N subsystem 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh to 1Fh 20h to FEh
Addressing by Global title
The global title consists of a sequence of digits that identify the destination (telephone number, telephone service prefix, credit card number, etc.). The Signaling Transfer Points (STPs) carry out a translation operation on these numbers called global title translation, which results in a definite network address (SPC) and/or an SSN. The global title can be transmitted in four formats which vary with the type of information included (with/without a numbering plan, nature of address, encoding scheme, etc.). The identification 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 that the originating application of the message does not need to know its physical destination as that mission is assigned to the STPs. This characteristic is fundamental in the implementation of the Intelligent Networks, for example. The following figures describe the existing global title formats and the corresponding global title indicator:
19
Global title indicator = 0001 (GTI 1):

7 O/E 6 5 4 3 2 1 0 Octet 1 Octet 2 and further
Nature of address indicator Global title address information

7 6 5 4 3 2 1 0 Octet 1 Octet 2 and further
Translation type Global title address information

7 6 5 4 3 2 1 0 Octet 1 Octet 2 Octet 3 and further
Translation type Numbering plan Encoding scheme Global title address information

7 6 5 4 3 2 1 0 Octet 1 Octet 2 Octet 3 Octet 4 and further
Translation type Numbering plan 0 Encoding scheme Nature of address indicator Global title address information Note: the GTI4 format is the standard one in international networks.
An important point to remember is that the SCCP addresses can simultaneously contain an SPC, SSN and global title, but always in that order (according to the ITU-T definition):
5 4 3 2 1 Signaling Point Code (SPC) Subsystem number (SSN) Global Title (GT)
0 Byte 1 Byte 2 Byte 3 Byte 4
Figure 14: SCCP, addresses format In order to complete this chapter, below is the layout of a complete UDT (Unitdata) message as well as the tables relating to the coding of the different fields: PARAMETER Message Type Code Return Option (R) / Prot. Class (C) Pointer to Called Party Address Pointer to Calling Party Address Pointer to User Data Type F F 7 0 R 6 0 0 5 0 0 4 0 0 3 1 0 2 0 0 1 0 0 0 1 C
20
... Called Party Address Address Indicator : RI = routing Indicator Bit 1 = SSN included Bit 0 = SPC included
Gaps possible in 1988 & 1992 versions Length Indicator X RI GTI = 0 1 0 0 1 Signaling Point Code
GT digits
Calling Party Address Address Indicator V
SSN Translation Type Numbering Plan Encoding Scheme Nature of Address Digit 1 Digit 0 Digit ... Digit .... Digit 24 Digit 23 Length Indicator X RI GTI = 0 1 0 0 1 1 Signaling Point Code SSN Translation Type Numbering Plan Nature of Address Digit 1 Digit 3 ....... Digit 24 Length Indicator Value
Encoding Scheme Digit 0 Digit 4 ....... Digit 23
User Data Figure 15: SCCP, UDT message
7 Reserved for national use
6 Routing indicator
1 SSN indicator
0 Point code indicator
Global title indicator
Figure 16: SCCP, coding of the field address indicator
Bits
5432 0000 0001 0010 0011 0100 0101 to 0111 1000 to 1110 1111 xxxx xxxx
no global title included Global title includes nature of address indicator only Global title includes translation type only Global title includes translation type, numbering plan and encoding scheme Global title includes translation type, numbering plan, encoding scheme and nature of address indicator
Spare international
Spare national Reserved for extension. Routing on Global Title Routing on SSN
0 1
Figure 17: SCCP, coding of the field global title indicator
21
Bits
7654 0000 0001 0010 0011 0100 0101 0110 0111 1000 to 1101 1110 1111
unknown ISDN/telephony numbering plan (Recommendations E.163 and E.164) generic numbering plan data numbering plan (Recommendation X.121) telex numbering plan (Recommendation F.69) maritime mobile numbering plan (Recommendations E.210, E.211) land mobile numbering plan (Recommendation E.212) ISDN/mobile numbering plan (Recommendation E.214)
spare private network or network-specific numbering plan reserved.
Figure 18: SCCP, coding of the field numbering plan
Bits
3210 0000 0001 0010 0011 0100 to 1110 1111
Unknown BCD, odd number of digits BCD, even number of digits National specific
Spare Reserved.
Figure 19: SCCP, coding of the field encoding scheme
Bits
76543210 00000000 00000001 to 00111111 01000000 to 01111111 10000000 to 11111110 11111111
Decimal Value 0 1 to 63 64 to 127 128 to 254 255
unknown
international services
spare
national network specific reserved for expansion
Figure 20: SCCP, coding of the field translation type
22
23
3.5.
TCAP (Transaction Capabilities Application Part)
The TCAP (also designated TC) enables the exchanging of information between applications resident at different points of the network, using the connectionless service provided by the SCCP. The basic aim of the TCAP is to enable the execution of remote operations of the question-answer type, like database query or features activation/deactivation. The TCAP is the basic signaling used to support Intelligent Network applications, interconnection of mobile networks databases, telecommunications networks management, etc. An important feature of these connections (called transactions) is the fact that they are independent of any voice or data transmission channel (bearer channels), so they are designated bearer unrelated connections. This aspect of the characterization of connections is often the source of misunderstandings, so lets 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 associated voice/data channels. It corresponds to the situation of a normal telephone connection in which a signaling channel is used (ISUP, for example) in order to assign and release a voice channel (bearer channel) to make the respective call. That means, there is always at least one voice/data channel associated with the signaling link during the active phase of the call. On the other hand, a bearer unrelated or connection independent connection has no associated voice/data channel and all information is exchanged solely via the signaling channel. This type of connection applies in situations where the transmission of large quantities of information in real time is not necessary, for example, the interrogation of databases, sending telemetry data, passwords, network management, etc.
Note: There is often a confusion with the terms connection oriented and connectionless, which describe completely different concepts: A connection oriented dialog is characterized by having an establishment (setup) phase, an active phase (talk, information transfer) and a freeing of resources (release) phase. On the other hand, a connectionless dialog consists of transmitting individualized information that alone contains all the information relating to the destination address (datagrams), there being no reply from the destination as to whether it has been received. The data is simply transmitted (typically in a UNITDATA message).
3.5.2.
Characterization of the TCAP
The TCAP enables the establishing of an association (simple or multiple) between applications resident in a network. The name transaction is applied to this association and it is identified by a sequential number assigned for each application and which remains fixed during the existence of the transaction, designated respectively Originating Transaction ID or Destination Transaction ID.
24
Associated with a transaction is the definition of a dialog, identified by a Dialog ID. A dialog can be structured (connection oriented transaction with a beginning, middle and end), or non-structured (connectionless transaction). An application context may be associated with the dialog, containing the information necessary to make the applications compatible. A typical example consists of the negotiating of 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 specific data, 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 and respective response, the Invoke D, as well as an associated operation depending on the application, the operation code. As an option it can have a secondary identification, the linked ID.
3.5.3.
Structure of the TCAP messages
Following the previous definitions, we see that the TCAP messages consists of two perfectly defined parts:
Transaction Portion
Component Portion
Transaction portion: This contains the data relating to the transaction (Transaction IDs), and to the dialog (dialog primitive/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 selfcontained information without response. All the remaining primitives refer to structured dialogs. First primitive transmitted, request for start of transaction. Indicates the continuation of an already established dialog. Structured closure of a dialog.
TC-BEGIN TC-CONTINUE TC_END TC-U-ABORT
User Abort, signals to the remote application that the transaction has been aborted by the initiative of the local application. Provider Abort, signals both applications that the transaction has been aborted by the TCAP.
Signals to the local application that the requested service cannot be provided.
TC-P-ABORT
TC-NOTICE
Component portion: Contains one or several components relating to the application, which can be invocations, results, error messages, etc.
25
The primitives defined for the component portion are as follows:
TC-INVOKE
Signals an interrogation to the remote application. Contains as obligatory parameters the Invoke ID and an operation code that identifies the specific operation required.
TC-RESULT-L
Result Last, sole response to an invoke primitive. Must contain the same Invoke ID as the invocation which originate it. 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. The last segment of the response is sent with a TC-RESULT-L primitive, of course. User Error, response to an invoke primitive indicating failure by the remote application in the execution of the required operation. Local Cancel, signals the cancellation or a prior invocation by the TCAP (normally by timing out of the response time of the remote application). User Cancel, signals the cancellation of a previous invocation by the local application. Local Reject, signals the rejection of the previous invocation by the local TC, due to error in the respective parameters. Remote Reject, signals the rejection of the previous invocation by the remote TC, because of an error in the respective parameters. User Reject, signals the rejection of the previous invocation by the remote application, because of an error in the respective parameters.
TC-RESULT-NL
TC-U-ERROR
TC-L-CANCEL
TC-U-CANCEL
TC-L-REJECT
TC-R-REJECT
TC-U-REJECT
As has been stated, underlying each invocation is a specific application operation code. The types of response possible for an invocation depend on the class of operation with which that operation has been defined. There are four defined classes of operation, as follows:
Class of operation 1 2 3 4
Description Report success or failure Report only failure Report only success No report
Remarks The remote operation always responds to the invocation with a result. The remote operation responds to the invocation only in the case of error. The remote operation responds to the invocation only in the case of success. The remote operation never responds to the invocation.
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 the primitives that have a remote significance exist in the request and indication form; this means say that a primitive sent by the application to the TC is of the _req type and the corresponding primitive passed remotely by the TC to the application of the _ind type.
26
The transmission/reception of the elements of the transaction portion and the component portion is always done in stack mode; this means that the application passes in first place the components to the TCAP and the dialog primitive after, and the remote application receives from the TCAP the dialog primitive followed by the components (see flow in the following chapter).
3.5.4.
A specific application example: the CCBS
In order to clarify the concepts stated previously, below is a typical example of a TCAP application in the telephone network, the CCBS service. The CCBS service (Call Completion to Busy Subscriber), enables a subscriber to be automatically recalled when the destination number is busy; after hearing the busy signal, the subscriber activates the service and in the case of success (the result is presented in the form of 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 the subscriber activates the service, we will note the following flow:
TC TC-INVOKE_req <ccbsRequest> TC-BEGIN_req SCCP MTP MTP SCCP TC
TC-BEGIN_ind TC-INVOKE_ind <ccbsRequest> TC-RESULT-L_req TC-CONTINUE_req
TC-CONTINUE_ind TC-RESULT-L_ind TC-INVOKE_req <remoteUserFree> TC-CONTINUE_req TC-CONTINUE_ind TC-INVOKE_ind <remoteUserFree> TC-END_req TC-END_ind
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) the application responsible for the CCBS is called; this application generates a sequence (called APDU, Application Protocol Data Unit) which contains the data required for the invocation of the CCBS at the remote exchange, namely the operation code designated as ccbsRequest, followed by the dialog primitive to be sent (BEGIN).
27
2. The TCAP constructs a unique message (a PDU, Protocol Data Unit), a TC-BEGIN_req with a TC_INVOKE_req, and sends it to the lower signaling level, in this case the connectionless service of the SCCP. The SCCP carries out the translation of the destination telephone number into a network address (global title translation), encapsulates the message received from the TCAP in a UDT message (UNITDATA) and sends it to its destination using the MTP services.
3. When the message reaches the remote exchange (possibly after passing through several network nodes, SPs or STPs) the TCAP separates the components of the received message and passes it to the CCBS application via a TC-BEGIN_ind followed by a TCINVOKE_ind, which contains the operation code. The application decodes the APDU received, activates the monitoring of the subscriber whose access is busy and sends the result back to the originating application by means of a component TC-RESULT-L_req followed by a TC-CONTINUE_req. 4. When the remote application detects that the subscriber is free, it generates an APDU with the remoteUserFree operation code, which is sent by the TCAP in a TCINVOKE_req and in a TC-CONTINUE_req. 5. The local application receives the information that the subscriber is free and activates the ringing tone to the local subscriber. When this answers, the call-processing application is invoked to establish a normal call, while the CCBS application (which has already completed its mission) terminates the TCAP transaction with its remote partner sending it a 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 can identify the users involved in this example: thus, we have the MTP (layer 1,2 and 3), the SCCP (an add-on on layer 3), the TCAP (layer 7), and finally a TCAP user, the application 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 contain an associated operation code; in this particular case, we are using operations that have been standardized by the ITU-T for the CCBS service: the ccbsRequest operation, which is defined as a class 1 operation (there is always a response) and the RemoteUserFree operation, which is a class 4 operation ( does not expect a response). Invoke ID: each TC-INVOKE component is associated with an arbitrary number that identifies it, called Invoke ID (in our example, the TC-INVOKE with ccbsRequest and the TC_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 not shown layouts defined for the messages, as it was the case of the chapters dedicated to the MTP and the SCCP. The reason is simple: the APDUs of the applications using the TCAP, as well as the PDUs of the TCAP itself are encoded in accordance with a syntax standardized by the ITU-T, designated ASN.1 (Abstract Syntax Notation No.1), which by their nature are not able to be represented in a fixed format. This may seem strange but we should not forget that we are working at the OSI Application level, and at this level it is intended that communication should be possible between different applications, independently of the platform, manufacturer, etc. (open systems concept).
28
ASN.1 was therefore created in order to enable communication between open systems, by using an abstract syntax. But this is a subject that merits a chapter of its own.
29
3.6.
ASN.1 notation (Abstract Syntax Notation No.1)
The OSI architecture has been defined in accordance with the open system concept. In order to guarantee communication between different platform applications, level 6 was envisaged (Presentation), responsible for making the formats or data representation systems compatible. This involved the definition of an abstract syntax or rather a form of referencing data independently of their representation form, and a transfer syntax, a set of rules that enable the values to be transmitted in binary terms. A specific language was therefore created 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 rather embedded 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 actually widely used both in switching networks (Intelligent Networks, GSM, TMN) and in IP based networks (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 language but an understanding of its basic principles is fundamental for anyone working in this area, so the 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 as objects) from which more complex data types are defined. The language provides a set of universal data type, which can be used as blocks for the definition 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 example of 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
30
BIT STRING
Value represented by a binary sequence. example: example of notation: PageOfFax::=BIT STRING 10100111B or A7H
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: example of notation: NameOfFather::=VisibleString 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 always be 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
31
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 PassportNo ANY ANY DEFINED BY INTEGER, INTEGER}
This is a derivation of CHOICE, in which the components are not specified a priori, but can be of 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 normally comprises 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.
32
For an illustration of the structure of an ASN.1 module let us consider the definition of the CCBS 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 ::= CcbsResume ::=
OPERATION OPERATION OPERATION
RemoteUserFree ::=
--error type definitions LongTermDenial ::= ShortTermDenial ::= ERROR 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 }
33
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 cCBS-T4-Timeout cCBS-T7-Timeout cCBS-T9-Timeout USICode ::=
(1), (2), (3), (4)}
OCTET STRING (SIZE (1..11)) OCTET STRING (SIZE (1..maxAccessTransportLength)) INTEGER ::= 255
AccessTransport ::=
maxAccessTransportLength
-- object identifier path ccbsOID OBJECT IDENTIFIER ::= operations-and-errors(1)} {ccitt recommendation q 733 3
-- operation values ccbsRequest ccbsCancel ccbsSuspend ccbsResume remoteUserFree CcbsRequest ::= globalValue:{ccbsOID 1} CcbsCancel ::= globalValue:{ccbsOID 2}
CcbsSuspend ::= globalValue:{ccbsOID 3} CcbsResume ::= globalValue:{ccbsOID 4} globalValue:{ccbsOID 5} ::= globalValue {ccbsOID 9}
RemoteUserFree ::=
forwardCcbsRequest ForwardCcbsRequest
-- error values shortTermDenial ShortTermDenial ::= longTermDenial LongTermDenial ::= globalValue:{ccbsOID 6} globalValue:{ccbsOID 7}
END -- of CCBS-Protocol
Some comments on this module:
34
The designations OPERATION, PARAMETER, RESULT and ERROR correspond to the macros imported from other module. ASN.1 has a wide range of resources for creating macros that enable the definition of new types of data. As may be seen, the construction of the data structures in ASN.1 consists of defining a macrostructure and defining the lower levels recursively. For example, in this module we have the definition of an operation called CcbsRequest, whose parameters are called CcbsRequestArg and are of the type CcbsRequestArg. The structure CcbsRequestArg is in turn made up of a sequence that contains a parameter called CalledPartNumber of the type Number, one retainSupported of the BOOLEAN type, etc... etc. - Note that in the statement ccbsOID OBJECT IDENTIFIER and subsequent statements that identify these operations as objects defined in CCITT Standard Q733 - Note the syntax [xx] IMPLICIT. Its importance will become clear a little later.
35
3.6.2.
Transfer syntax
In parallel with the definition of the object types, ASN.1 defines the basic rules for encoding them. These rules are standardized with the name B.E.R. (Basic Encoding Rules), and these rules define the transfer syntax, that is, the form in which the abstract descriptions we saw previously are mapped and transmitted in a sequence of octets. The basic principles of data coding in ASN.1 are as follows:
All the ASN.1 objects have an associated label (called tag) and are coded according to a sequence Tag-Length-Value, TLV for short. A message coded in ASN.1 consists of a recursive sequence of TLV blocks.
Figure 22: TLV sequence
3.6.2.1.
Coding the tag
Four tag classes are defined, as follows: - Universal: These correspond to the basic types described in the previous chapter (INTEGER, BOOLEAN, REAL, etc.). They are always coded with the same value, independently of the application (they are universal). These are defined for a specific application and therefore are relevant only within the scope of that application. These are defined for a specific application and relevant only in a specific context of that application. These are defined by the users of the application and therefore relevant exclusively for those users.
- Application:
- Context:
- Private:
The coding of the tag takes place as follows if the number of the tag is less than or equal to 30:
Class (2 bits)
P/C (1 bit)
N of tag (5 bits)
Figure 23: Tag coding (if less than 30)
36
The class is coded in the following way: Class 00 01 10 11 Description Universal Application Context 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 case of SET, SET OF, SEQUENCE, etc. P/C 0 1 Description Primitive 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. In this case, the tag number is filled in with 11111, and as many bytes follow as are necessary to encode it, with bit 7 filled to 1, except in the last byte (?!) well, the best way is to look at the following figure:
Class
P/C
1 1 1 1 1
XXXXXXX
XXXXXXX
...........
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 the Universal class as these are the only ones whose coding is always the same, independently of the application: Name BOOLEAN INTEGER BIT STRING OCTET STRING NULL OBJECT IDENTIFIER OBJECT DESCRIPTOR EXTERNAL REAL ENUMERATED +++ reserved +++ reserved +++ reserved +++ reserved +++ reserved SEQUENCE (and ... OF) Class UNIVERSAL 1 UNIVERSAL 2 UNIVERSAL 3 UNIVERSAL 4 UNIVERSAL 5 UNIVERSAL 6 UNIVERSAL 7 UNIVERSAL 8 UNIVERSAL 9 UNIVERSAL 10 UNIVERSAL 11 UNIVERSAL 12 UNIVERSAL 13 UNIVERSAL 14 UNIVERSAL 15 UNIVERSAL 16 Coding 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah ----------10h
37
SET (and SET OF) NumericString PrintableString TelexString VideotextString IA5String UTCTime GeneralizedTime GraphicString VisibleString GeneralString
UNIVERSAL 17 UNIVERSAL 18 UNIVERSAL 19 UNIVERSAL 20 UNIVERSAL 21 UNIVERSAL 22 UNIVERSAL 23 UNIVERSAL 24 UNIVERSAL 25 UNIVERSAL 26 UNIVERSAL 27
11h 12h 13h 14h 15h 16h 17h 18h 19h 1Ah 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:
If the length is less than 128 the so-called short defined format will apply, that is, it is coded in a single octet, leaving bit 7 to zero:
XXXXXXX
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 octets follow to encode the length (once again, it is better to look at the picture):
N of octets L that follow
XXXXXXXX (Length)
...........
XXXXXXXX (Length)
If the overall length is unknown at the start of the transmission the undefined format applies, that is, the first octet has bit 7 set to 1 and the remainder to zero, and the octets that follow contain the value. When all the octets have been transmitted, two additional octets are sent filled with zeros Obviously, the use of this format implies that the value is coded in such a way that it contains no sequence of 2 octets set to zero.
38
3.6.3.
Practical use
If the coding of objects in ASN.1 was limited to the use of tags of the Universal class we would not have a big added value with it; but in fact ASN.1 permits the creation of more complex structures, with the allocation of specific tags for each application. Thats the aspect we will illustrate briefly. In the first place, let us assume that we are attempting to encode a companys employee records. This could be done in the following way:
Module_1 DEFINITIONS ::= BEGIN RecordOfEmployee ::= SEQUENCE { name number nameOfSpouse children } RecordOfChild ::= SET { name age } Name, NumberOfEmployee, Name OPTIONAL, RecordOfChild OPTIONAL
Name, Age
Name ::=VisibleString NumberOfEmployee ::=INTEGER (0 .. 1000) Age ::=INTEGER END
In the specific case of John, employee no. 33, married to Mary, with a son Paul aged 14, the resulting sequence would be: 30 1C 1A 04 4A 6F 73 65 02 01 21 1A 05 4D 61 72 69 61 31 0A 1A 05 50 61 75 6C 6F 02 01 0E SEQUENCE length VisibleString, length=4,value=John INTEGER, length=1,value=33 VisibleString, length=5,value=Mary SET length VisibleString, length=5,value=Paul 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 the order of the objects is arbitrary). In order to avoid problems of this sort, tags from the Context class should be defined, i.e. the allocation of a specific tag for an object; thus, this tag would be valid only in that specific situation in that ASN module. ASN.1 also enables the allocation of Application class tags to any object which means that this object will always be identified with that tag throughout the application.
39
Let us now see the previous example modified by using tags from the Context and Application classes:
Module_2 DEFINITIONS ::= BEGIN RecordOfEmployee ::= [APPLICATION 1] SEQUENCE name number nameOf Spouse [1] children [2] } RecordOfChild ::= SET { name [0] age } { Name, NumberOfEmployee, Name OPTIONAL, RecordOfChild OPTIONAL
Name, Age
This time the resulting coding would be: 61 24 30 22 1A 02 A1 A2 APPLICATION 1 RecordOfEmployee !!! length SEQUENCE length 04 4A 6F 73 65 VisibleString, length=4,value=John 01 21 INTEGER, length=1,value=33 07 1A 05 4D 61 72 69 61 Context 1,VisibleString, length=5,value=Mary !!! 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 specific tag 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 Context class, when integrated in the RecordOfEmployee sequence, the same applying for the object Children (tag 2 from the Context class). On the other hand, the object Name takes tag 0 when integrated in the object RecordOfChild. The last point to consider is as follows: with this alteration the coded sequence becomes longer as the Application and Context tags follow the tags of the primitive types comprising them (INTEGER, VisibleString, etc.). However, we are sending redundant information insofar as, 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 TLV. The way to achieve this is by using the IMPLICIT instruction, by which we inform the compiler that 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:
40
Module_3 DEFINITIONS ::= 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 age }
Name, Age
... and the resulting coding would finally be: 61 1C 1A 02 81 A2 APPLICATION 1 RecordOfEmployee length VisibleString, length=4,value=John INTEGER, length=1,value=33 Context 1,VisibleString, length=5,value=Mary Context 2, Context 0, VisibleString...,value=Paul INTEGER, length=1, value=14
04 4A 6F 73 65 01 21 05 4D 61 72 69 61 0A 80 05 50 61 75 6C 6F 02 01 0E
Normally, the IMPLICIT operator is used intensively because of the obvious compression obtained. In order to avoid the systematic repetition of this operator in each definition of objects, the compiler can be told to use this notation by default, placing the IMPLICIT TAGS directive at the head of the module. If a tag is to be coded explicitly, we can define this by means of the EXPLICIT directive. From all that has been stated here, the final form of our module would doubtless be:
Module_4 DEFINITIONS IMPLICIT TAGS ::= BEGIN
RecordOfEmployee ::= [APPLICATION 1] SEQUENCE { name Name, number NumberOfEmployee, nameOfSpouse [1] Name OPTIONAL, children [2] RecordOfChild OPTIONAL }
41
RecordOfChild ::= SET
{ name [0] age
Name, Age
} Name ::=VisibleString NumberOfEmployee ::=INTEGER (0 .. 1000) Age ::=INTEGER END
In compiling this last module we would be able to confirm that the resulting coding would be exactly the same as that obtained with the previous module.
42
43
4. Users of SS#7
This chapter describes (briefly) some applications that use the No. 7 Signaling System and the respective protocols.
4.1.
ISS (ISDN Supplementary Services)
The ISS incorporates a series of facilities implemented in the telephone network, mainly (but not exclusively) ISDN features. The following are some examples: Call Completion facilities, of which the already described CCBS is an example, and Call Completion 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 is detected 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 ISDN subscriber has messages in his mailbox, this facility enables transmission of this indication to the respective access. The information is carried via SS#7 in the network and transmitted to the ISDN access via D channel.
To conclude this chapter, an example of an SCCP PDU is shown, which illustrates a major part 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 to understand 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. This operation belongs to a proprietary Siemens application known as BCAP (Business Corporation Application Part), and carries information intended for an Intelligent Networks service. - One component with the mwiSet operation and respective parameters. This operation belongs to the ISS and is standardized by the ITU-T, containing as such a field of the type Object Identifier.
09, 80, 03, 07, 0E, 04,43,01,00,03, 07,12,03,00,12,98,32,43, Message Type = UNITDATA SCCP part Bit Return Option set pointer to GT-Called Pty Address pointer to GT-Calling Pty Address pointer to User data GT-Called Pty Address GT-Calling Pty Addr -----------------------------------length of USER DATA
76,
44
62, 74, 48,04,08,8D,43,51, 6C, 6C, A1, 44, 02,01,01, 02,01,10, 30, 3C, 02,01,1C, 30, 2C, 04,04,31,32,33,34, 02,01,07, 02,01,03, 02,01,03, 30, 1B, 01,01,01, 04,03,12,34,00, 02,01,02, 02,01,0C, 02,01,0A, 02,01,02, 04,05,03,10,17,44,44, 30, 09, 04,03,B1,B2,B3, 04,02,C1,C2, A1, 24, 02,01,%100, 06, 06, 04, 00, 85,72, 01, 01, 30, 17, 04,05,83,10,98,76,80, 04,05,83,13,98,76,08, 0A,01,02, A1, 04,02,02,00,07
BEGIN_ind length Originating Trnsaction ID Component Portion length Invoke Component nr.1 length Invoke Id OPERATION =inData Sequence length triggerTableIdx sequence length serviceKey ACN Selector SSF type (iN)NetworkInd Sequence length spcIncluded spc routePref ssid transType encScheme number Sequence length bgID subBGID
TCAP part
Invoke Component nr.2 length Invoke Id OBJECT IDENTIFIER length ccitt/ident org. etsi 754 oper. and error OPERATION=mWISet Sequence length receivingUserNumber controllingUsetNumber basicService= Unr.DigitalInfo Optional par=numberOfmessages
45
4.2.
INAP (Intelligent Networks Application Part)
To be provided later.
46
47
4.3.
MAP (Mobile Application Part)
48
49
4.4.
CAP (CAMEL Application Part)
50
5. List of acronyms
ACSE APDU ASE ASN.1 AUC B-ISDN BSN BSS CCBS CRC CS-x DPC DUP EIR FCS FISU FSN GSM GT GTI HLR IN IP ISDN ISPC ISS ISUP ITU-T LI LSSU MACF MAP MSC MSU OAMP OPC PABX PDU ROSE SACF SCCP SCEF SCF SCP SIM SIO SLS SP SPC SRF SSF SSN SSP STP SU Association Control Service Element Application Protocol Data Unit Application Service Element Abstract Syntax Notation No. 1 Authentication Center Broadband ISDN Backward Sequence Number (MTP) Base Station Subsystem (GSM) Call Completion to Busy Subscriber (ISS) Cyclic Redundancy Check Capability Set x (IN) Destination Point Code Data User Part Equipment Identification Register Frame Check Sequence Fill-In Signal Unit (MTP) Forward Sequence Number (MTP) Global System Mobile Global Title (SCCP) Global Title Indicator (SCCP) Home Location Register Intelligent Network Intelligent Peripheral (IN) or Internet Protocol Integrated Services Digital Network International Signaling Point ISDN Supplementary Services ISDN User Part International Telecommunications Union Standardization Length Indicator (MTP) Link Status Signal Unit Multiple Association Control Function (INAP) Mobile Application Part Mobile Switching Center Message Signal Unit (MTP) Operation, Administration & Maintenance Part Originating Point Code Private Automatic Branch Exchange Protocol Data Unit Remote Operations Service Element Single Association Control Function (INAP) Signaling Connection Control Part Service Creation Environment Function (IN) Service Control Function (IN) Service Control Point (IN) Subscriber Identity Module (GSM) Service Information Octet (MTP) Signaling Link Selection (MTP) Signaling Point Signaling Point Code Specialized Resource Function IN) Service Switching Function (IN) Subsystem Number (SCCP) Service Switching Point (IN) Signaling Transfer Point Signaling Unit (MTP)
51
TC TCAP TMN TUP UDT UMTS VLR XUDT
Transaction Capabilities Transaction Capabilities Application Part Telecommunication Management Network Telephone User Part Unitdata (SCCP) Universal Mobile Telecommunication System Visitor Location Register (GSM) Extended Unitdata (SCCP)
52
6. Bibliography
6.1. ITU-T Recommendations
Recommendations Q.701 to Q.709 Recommendations Q.711 to Q.716 Recommendations Q.721 to Q.725 Recommendations Q.730 to Q.737 Recommendations Q.750 to Q.755 Recommendations Q.761 to Q.767 Recommendations Q.771 to Q.775 Recommendation Q.1051 Recommendation Q.1218 Recommendation Q.1228
- MTP: - SCCP: - TUP: - ISS: - OAMP: - ISUP: - TCAP: - MAP: - INAP-CS1: - INAP-CS2:
6.2.
Siemens Vargas
Other documents
P30308-A1638-D011-**-7622, SCCP Catalog version 13,13T, 14A OSI-models, AEIST, 1996 Intelligent Networks-Standards and evolution to Universal Services, IBC London, 1999 Signaling system #7, Philips Omnicom Training, 1998
Magedanz, T.
Frampton, J.
53
7. Appendices
7.1. Appendix 1: ASN.1 modules
Definition of TCAP messages (standard)
7.1.1.
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 INTEGERs (in PROBLEMS) were changed to INTEGERs -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 begin end continue abort Unidirectional ::=
[APPLICATION [APPLICATION [APPLICATION [APPLICATION [APPLICATION
1] 2] 4] 5] 7]
IMPLICIT IMPLICIT IMPLICIT IMPLICIT IMPLICIT
Unidirectional, Begin, End, Continue, Abort}
SEQUENCE {dialogPortion components SEQUENCE {otid dialogPortion components SEQUENCE {dtid dialogPortion components
DialogPortion OPTIONAL, ComponentPortion} OrigTransactionID, DialogPortion OPTIONAL, ComponentPortion OPTIONAL} DestTransactionID, DialogPortion OPTIONAL, ComponentPortion OPTIONAL}
Begin ::=
End ::=
54
Continue ::=
SEQUENCE {otid dtid dialogPortion components SEQUENCE {dtid reason CHOICE {p-abortCause dialogPortion
OrigTransactionID, DestTransactionID, DialogPortion OPTIONAL, ComponentPortion OPTIONAL} DestTransactionID, P-AbortCause, DialogPortion} OPTIONAL}
Abort ::=
-- 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 ::= DestTransactionID ::=
[APPLICATION 8] IMPLICIT TransactionID [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 returnResultLast returnError reject returnResultNotLast
[1] [2] [3] [4] [7]
IMPLICIT IMPLICIT IMPLICIT IMPLICIT IMPLICIT
Invoke, ReturnResult, ReturnError, Reject, ReturnResult}
-- The Components are sequences of data elements. Invoke ::= SEQUENCE { invokeID linkedID operationCode
InvokeIdType, [0] IMPLICIT InvokeIdType OPTIONAL, OPERATION,
55
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 errorCode parameter
InvokeIdType, ERROR, 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 invokeProblem [1] IMPLICIT returnResultProblem [2] IMPLICIT returnErrorProblem [3] IMPLICIT InvokeIdType ::= INTEGER(-128..127) -- PROBLEMS. GeneralProblem
GeneralProblem, InvokeProblem, ReturnResultProblem, ReturnErrorProblem}}
::= 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) ::= INTEGER {unrecognizedInvokeID (0), returnErrorUnexpected (1), unrecognizedError (2), unexpectedError (3), mistypedParameter (4)} (0..127)
ReturnErrorProblem
END -- TCAPMessages
56
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 provided SetUp ::= OPERATION ARGUMENT SetUpArg RESULT ERRORS { CalledAccessNonVpn, ShortPeriodDenial, LongPeriodDenial } -- Specification of Connect -- ======================== -- Direction: DLEX -> OLEX -- Class: 4 -- Purpose: to be provided Connect ::= OPERATION ARGUMENT ConnectArg -- Specification of Release -- ======================== -- Direction: OLEX -> DLEX and DLEX -> OLEX -- Class: 4 -- Purpose: to be provided Release ::= OPERATION ARGUMENT ReleaseArg -- Specification of VpnFacility -- ============================ -- Direction: OLEX -> DLEX and DLEX -> OLEX -- Class: 4 -- Purpose: to be provided VpnFacility ::= OPERATION ARGUMENT VpnFacilityArg -- Specification of ActivityTest
57
-- ============================= -- Direction: OLEX -> DLEX -- Class: 3 -- Timer: BCAP-T2 -- Purpose: to be provided ActivityTest ::= OPERATION RESULT -- BOOLEAN ERRORS {}
--=================================================================== -- TYPE DEFINITIONS FOR ERRORS --=================================================================== CalledAccessNonVpn ShortPeriodDenial LongPeriodDenial ::= ERROR ::= ERROR ::= 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 cause vpnTransport applicationID ... } VpnFacilityArg vpnTransport applicationID ... } ::= SEQUENCE { [0] Cause, [1] VpnTransport OPTIONAL, [2] ApplicationID OPTIONAL,
::= SEQUENCE { [0] VpnTransport OPTIONAL, [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.
58
BearerCapability InCounter ApplicationID
::= OCTET STRING (SIZE(1..maxBearerCapability)) ::= INTEGER (0..5)
::= INTEGER {qsig(0), internet(1), isci(2), teleworking(3) }(0..16) --=================================================================== -- DEFINITIONS OF RANGE CONSTANTS --=================================================================== maxCauseLength maxVpnTransportLength maxBearerCapability INTEGER INTEGER INTEGER ::= 10 ::= 2048 ::= 12
--=================================================================== -- DEFINITION OF OBJECT IDENTIFIER PATH --=================================================================== -- local values are used
--=================================================================== -- ASSIGNMENTS FOR OPERATION VALUES --=================================================================== setUp connect release vpnFacility activityTest SetUp Connect Release VpnFacility ::= localValue 11 ::= localValue 12 ::= localValue 13 ::= localValue 14
ActivityTest ::= localValue 15
-- local value for in data moved to ADD-TCAP --=================================================================== -- ASSIGNMENTS FOR ERROR VALUES --=================================================================== calledAccessNonVpn shortPeriodDenial longPeriodDenial CalledAccessNonVpn ::= localValue 17 ShortPeriodDenial ::= localValue 18 LongPeriodDenial ::= localValue 19
END -- BCAP-Protocol
59
7.1.3.
MWITC
Definition of the MWI service - Message Waiting Indication (standard)
--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-serviceelements(8)};
--operation types MWISet ::= OPERATION PARAMETER SEQUENCE { receivingUserNumber Number, controllingUserNumber Number, basicService BasicService, numberOfMessages [1] MessageCounter time [2] GeneralizedTime (SIZE(0..50)) OPTIONAL, contUserProvidedNumber [3] Number OPTIONAL, mode [4] InvocationMode messageIdentity [5] MessageIdentity scpDialogData [6] ScpDialogData --,... } RESULT ERRORS { receivingUserNotSubscribed, indicationNotDelivered, supplementaryServiceInteraction, resourceUnavailable, maxNumOfControllingUsersReached, maxNumOfActiveInstancesReached, invalidReceivingNumber, invalidControllingNumber --,... } --Timer T = MWI-Tsup -- End of MWISet operation definition MWIReset ::= OPERATION PARAMETER SEQUENCE { receivingUserNumber controllingUserNumber basicService mode scpDialogData --,... } RESULT
OPTIONAL,
OPTIONAL, OPTIONAL, OPTIONAL
Number, Number, BasicService, [1] InvocationMode [2] ScpDialogData
OPTIONAL,
OPTIONAL
60
ERRORS { receivingUserNotSubscribed, indicationNotDelivered, supplementaryServiceInteraction, resourceUnavailable, invalidReceivingNumber, invalidControllingNumber --,... } --Timer T = MWI-Tsup -- End of MWIReset operation definition
--error type definitions ReceivingUserNotSubscribed IndicationNotDelivered InvalidControllingNumber InvalidReceivingNumber SupplementaryServiceInteraction ResourceUnavailable MaxNumOfControllingUsersReached MaxNumOfActiveInstancesReached
::= ::= ::= ::= ::= ::= ::= ::=
ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR
--constants and data type definitions -- mod 26.5.97: Called/CallingPartyNumber durch Number ersetzt MessageCounter InvocationMode ::= ::= INTEGER (0..65535) ENUMERATED { deferred (0), immediate (1), combined (2)} SEQUENCE { messageRef status
MessageIdentity
::=
MessageRef, MessageStatus}
MessageRef MessageStatus
::= ::=
INTEGER (0..65535) 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
61
mWIOID etsi(0) 754
OBJECT IDENTIFIER ::=
{ccitt identified-organization operations-and-errors(1)}
-- operation values mWISet mWIReset MWISet MWIReset ::= ::= globalValue:{mWIOID 1} globalValue:{mWIOID 2}
-- error values receivingUserNotSubscribed globalValue:{mWIOID 10} invalidControllingNumber globalValue:{mWIOID 11} invalidReceivingNumber globalValue:{mWIOID 12} indicationNotDelivered globalValue:{mWIOID 13} supplementaryServiceInteraction globalValue:{mWIOID 14} resourceUnavailable globalValue:{mWIOID 15} maxNumOfControllingUsersReached globalValue:{mWIOID 16} maxNumOfActiveInstancesReached globalValue:{mWIOID 17} ReceivingUserNotSubscribed InvalidControllingNumber InvalidReceivingNumber IndicationNotDelivered ::= ::= ::= ::=
SupplementaryServiceInteraction ::= ResourceUnavailable ::=
MaxNumOfControllingUsersReached ::= MaxNumOfActiveInstancesReached ::=
END -- of MWI OPerations and Errors
62
63
7.2.
Appendix 2: SCCP/TCAP database (EWSD system)
This appendix contains an example of a database for SCCP and TCAP in the Siemens EWSD system, which assigns Code Points for the ISS services, therefore enabling the carrying of information relating to services such as the CCBS, CCNR, MWI, etc. Obviously, the meaning of only some parameters is described here as an exhaustive explanation can be found in the appropriate manuals.
BGA: BGA:DISPC7OP; BGA: BGA:CCS7 -- DISPLAY SIGN. ELEMENTS -- OWN SIGNALING POINT BGA: BGA:SPC NETIND STPI SDL SPCSIZE SENDTFP BGA:-------------+------+----+---+--------+------BGA:0- 0-0 INAT0 STP 62 NORMAL ON BGA: 0-0- 0-0 NAT0 STP 272 NORMAL ON BGA: 0- 0- 0 NAT1 STP 62 EXTENDED ON BGA:
The command CR C7OP enables the actual identification of the exchange to be defined for the 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 the network in which we are, normally of the x-y-z-w type. NETIND = Network Indicator: this parameter enables the selection of one of four possible signaling 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 node that 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 MSU frames 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-T standard 14 bits (NORMAL), 24 bits ANSI (EXTENDED), or if this does not carry out mapping of the formats (ITU14MP, ANSI24MP, and others).
BGA:DISPC7DP:DPC=X,NETIND=NAT0; BGA: BGA:CCS7 -- DISPLAY SIGN. ELEMENTS -- DESTINATION POINT BGA: BGA:DPC NETIND OST EST BGA:-------------+------+---+--BGA: 0-0- 0-1 NAT0 ACT ACT BGA: 0-0- 0-2 NAT0 ACT UNA BGA: 0-0- 0-4 NAT0 ACT ACT BGA: 0-0- 0-6 NAT0 ACT ACT BGA:15-7-15-3 NAT0 ACT ACT BGA:
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 exchange itself or external. The STPs can also be specified for where routing may be carried out in order to reach the intended destination, indicating a linked sequence of DPCs eg. DPC=0-1-7-3&0-6-4-2&...
64
/**********************************************************************/ /* 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 the functioning 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 equaling GT14, the format used in the international networks (the various existing formats are illustrated in Chapter 3.4.2). SCCLSR = SCCP Segmenting/Reassembly: specifies whether our network is according Blue Book (which does not permit segmentation/reassembly) or according White Book. MXMSGLEM = Maximum Message Length: specifies the maximum length of the user part in UDT (Unitdata) and XUDT (Extended UDT) messages. If a message passed to the SCCP exceeds this value, it is segmented and transmitted in several parts (if our network is according White Book). PROTCL = Protocol Class: specifies the class of protocol of the SCCP supported by the network, from CL0 to CL3; in this example we specify that our network supports the two connectionless 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 DATA BGA: BGA:DPC NETIND USNAME PCMTYP ACS ASSIGN BGA:--------------+--------+--------+--------+-------+--------BGA: 0-0- 0-1 NAT0 ISUP DIU30 BGA: 0-0- 0-1 NAT0 SCCP NODIU NO BGA:
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) is required.
/**********************************************************************/ /* CREATION OF SCCP USERS */ /**********************************************************************/ CR SCUSER: SSID=ISS, SSN=11, NETIND=NAT0, GTFRMT=GTI4,TCAPUS=YES; BGA:DISPSCUSER:SSID=X,NETIND=NAT0;
65
BGA: BGA:SCCP USER INFORMATION BGA: BGA:NETIND SSID SSN GTFRMT TCAPUS BGA:------+--------+---+------+-----BGA:NAT0 IN3 241 GTI4 Y BGA:NAT0 ISS 11 GTI4 Y BGA:
The command SCUSER allows the definition of a SCCP user and the establishment of a relationship 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 use the SSCP in our network. It should be noted that when we define standard applications, the SSN should also be complied with that standard; in the opposite case the application will only work properly in our network. In this specific example, we are defining two SCCP users: the user IN3, to which we assign SSN 241 (proprietary application), and the user ISS which corresponds to the standard SSN No. 11 (see Page 19). Other parameters: GTFRMT = Global Title Format: specifies that of the Global Title format used, by default being equal 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 INFORMATION BGA: BGA:NETIND TTID TTN BGA:------+--------+---BGA:NAT0 UNKNOWN 0 BGA:NAT0 IMSI 0 BGA:NAT0 CCV 0 BGA:NAT0 SMS 0 BGA:NAT0 INDD 0 BGA:NAT0 INCGPA 0 BGA:NAT0 INPPDD 0 BGA:NAT0 IEESS 17 BGA:NAT0 ITCC 0 BGA:NAT0 TT9 0 BGA:NAT0 TT10 0 BGA:NAT0 TT11 0 BGA:NAT0 TT12 0 BGA:NAT0 TT13 0 BGA:NAT0 TT14 0 BGA:NAT0 TT15 0 BGA:NAT0 TT16 0 BGA:NAT0 TT17 0 BGA:NAT0 TT18 0 BGA:NAT0 TT19 0 BGA:NAT0 TT20 0 BGA:NAT0 TT21 0 BGA:NAT0 TT22 0 BGA:NAT0 TT23 0 BGA:NAT0 TT24 0 BGA:NAT0 TT25 0 BGA:NAT0 TT26 0 BGA:NAT0 TT27 0
66
BGA:NAT0 BGA:NAT0 BGA:NAT0 BGA:NAT0 BGA:
TT28 TT29 TT30 TT31
0 0 0 0
The command SCTTCD specifies the form in which the Global Title is translated in network addresses. We should recall that the Global Title may contain several fields, depending on the GTI, so it is necessary to specify the type of translation to be carried out. One of the Global Title fields is precisely the TTID (Translation Type Identifier). In this example only the TTID=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; 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 INFORMATION BGA: BGA:NETIND SPC SSID LB SCMG SASPR OST RBLST BGA:------+-------------+--------+--+----+-----+---+-----BGA:NAT0 0-0- 0-0 ISS Y Y Y ACT BGA:NAT0 0-0- 0-1 ISS Y Y Y ACT BGA: /* OPC */
The command CR SCSS enables the creation of a subsystem associated with an SPC. The subsystem is created by using the parameter SSID, previously associated with an SSN via the command CR SCUSER. This command is essentially directed towards the SCCP management processes, not described in this document. Meanwhile, the subsystems created must be put into active status via the command CONF SCSS, (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 subsystem is required (Y/N). LB = Local Broadcast: specifies whether the remaining subsystems should be notified of the state changes of the created subsystem. SASPR = Subsystem available after SPC restart: specifies whether the subsystem should remain 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 ADDRESS BGA: BGA:NETIND SSID RTGP ISPC IGT TTID NP NA GTDIG BGA:-------+---------+-----+----+----+---------+---------+---------+-------BGA:NAT0 IN3 SPC N N UNKNOWN UNKNOWN UNKNOWN BGA:NAT0 ISS PROG N N IEESS ISDNTNP NATNO 12000034 BGA:
67
The command CR SCCGPA creates a Calling Party Address, that is, a unique identification for the local subsystem. This identification can be a combination of several types of possible addresses in the SCCP (SPC, GT or SSN), and this combination is defined by the parameter RTGP (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 Calling Party Address. NA = Nature of Address: specifies the Nature of Address of the number defined, NATNONational Number, INTNO-International Number, etc. NP = Numbering Plan: numbering plan for the number defined, ISDNTNP-ISDN Telephony NP, 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 NA BGA:-------------+---------+---------+-------BGA:ISS IEESS ISDNTNP NATNO BGA:INTISS IEESS ISDNTNP INTNO BGA:
The command CR GTDIGTR enables the conversion table that permits the SCCP to convert a 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 (not related 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 ND BGA:------------+--------+-------------+--------+--------+--------+-----BGA:ISS 12000034 NATOWN
68
BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:ISS BGA:INTISS BGA:INTISS BGA:INTISS BGA:
26 801 802 803 804 805 806 807 808 811 812 813 814 815 816 817 818 82 83 880 890 11248 248 49
..... +11
NATNO
NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN NATOWN
The command CR GTCPT creates the code points for translating the Global Titles. We are confining 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 Area Codes 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 : ISS BGA: BGA:GTDIG RTGP ROUTE SSID PPN NI DPC BGA:--------+------+--------+--------+---+-------+-----------BGA:12000034 INTERNAL UNKNOWN NAT0 0-0- 0-0 BGA:12111134 INTERNAL UNKNOWN NAT0 0-0- 0-1 BGA:26 INTERNAL UNKNOWN NAT0 0-0- 0-0 BGA:801 INTERNAL UNKNOWN NAT0 0-0- 0-0 BGA:802 INTERNAL UNKNOWN NAT0 0-0- 0-0 BGA:803 INTERNAL UNKNOWN NAT0 0-0- 0-0 BGA:804 INTERNAL UNKNOWN NAT0 0-0- 0-0 BGA:805 INTERNAL UNKNOWN NAT0 0-0- 0-0 BGA:811 INTERNAL UNKNOWN NAT0 0-0- 0-1 BGA:812 INTERNAL UNKNOWN NAT0 0-0- 0-1 BGA:813 INTERNAL UNKNOWN NAT0 0-0- 0-1 BGA:814 INTERNAL UNKNOWN NAT0 0-0- 0-1 BGA:815 INTERNAL UNKNOWN NAT0 0-0- 0-1
Finally, the command CR GTDEST associates the Global Titles with the DPCs. These destinations can be of several types: LTG in the actual exchange, internal routing in the actual exchange, external network, etc. This command has an enormous number of parameter combinations, depending on the type of routing, so we are not concerned with them here.
69

SS7

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SS7

Hochgeladen von

Copyright:

Verfügbare Formate

THE SIGNALLING SYSTEM N 7 AND ITS APPLICATIONS

Jos Velez, SIEMENS SA BU NET DS22

Jos Velez, SIEMENS SA BU NET DS22

Jos Velez, SIEMENS SA BU NET DS22

Alfragide, September 1999

Jos Velez, SIEMENS SA BU NET DS22

2. The signaling systems

Figure 1: Common channel signaling

2.2. Some notes on OSI architecture

Jos Velez, SIEMENS SA BU NET DS22

Jos Velez, SIEMENS SA BU NET DS22

Application Level (7) Application X

Application Level (7) Application X

Jos Velez, SIEMENS SA BU NET DS22

3. The N 7 Signaling System

Jos Velez, SIEMENS SA BU NET DS22

The structure of the SS#7 protocols

TCAP (Level 7 OSI)

SCCP (Level 3 OSI) MTP

Figure 4: SS#7 protocols stack

Jos Velez, SIEMENS SA BU NET DS22

Jos Velez, SIEMENS SA BU NET DS22

Jos Velez, SIEMENS SA BU NET DS22

MTP (Message Transfer Part)

MTP: physical sublevel

MTP: signaling link control sub-level

Figure 6: MTP frames

Jos Velez, SIEMENS SA BU NET DS22

MTP: network sub-level

Figure 7: MTP SIO field

Jos Velez, SIEMENS SA BU NET DS22

Routing label (4 bytes)

Heading code (1 byte)

User part (max 267 bytes)

DPC (14 bits)

OPC (14 bits)

Signaling Point (3 bits)

Jos Velez, SIEMENS SA BU NET DS22

Figure 9: Structure of an SPC

Jos Velez, SIEMENS SA BU NET DS22

SCCP (Signaling Connection Control Part)

SCCP: message structure

Mandatory parameter 1 Mandatory parameter 2 ............... Mandatory parameter N

Jos Velez, SIEMENS SA BU NET DS22

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

Figure 12: SCCP, format of the mandatory variable part

Jos Velez, SIEMENS SA BU NET DS22

Jos Velez, SIEMENS SA BU NET DS22

Hop counter Table 3: Optional SCCP parameters

Addressing by Global title

Jos Velez, SIEMENS SA BU NET DS22

Global title indicator = 0001 (GTI 1):

Nature of address indicator Global title address information

Global title indicator = 0010 (GTI 2):

Translation type Global title address information

Global title indicator = 011 (GTI 3):

Global title indicator = 0100 (GTI 4):

0 Byte 1 Byte 2 Byte 3 Byte 4

Jos Velez, SIEMENS SA BU NET DS22

Calling Party Address Address Indicator V

Encoding Scheme Digit 0 Digit 4 ....... Digit 23

User Data Figure 15: SCCP, UDT message

7 Reserved for national use

0 Point code indicator