Ss7 Protocol Suite - Bicc _ Bisup _ Dup _ Isup _ Map _ Mtp-2 _ Mtp-3 _ q2140 _ Sccp _ Tcap _ Tup

8/12/2019 Ss7 Protocol Suite - Bicc _ Bisup _ Dup _ Isup _ Map _ Mtp-2 _ Mtp-3 _ q2140 _ Sccp _ Tcap _ Tup

1/18


2/18

3/18/14 SS7 Protocol Suite - BICC | BISUP | DUP | ISUP | MAP | MTP-2 | MTP-3 | Q2140 | SCCP | TCAP | TUP

www.protocols.com/pbook/ss7.htm#MTP-2 2

CIC LSB

BICC

ITU-T Q.1901

Bearer Independent Call Control protocol is a call control protocol used between serving

nodes. This protocol is based on the ISUP protocol, and was adapted to support the ISDN

services independent of the bearer technology and signalling mess age transport

technology used.

The format of the BICC packet is shown in the following il lustration:

8 7 6 5 4 3 2 1 Octet

1

CIC 2

CIC 3

MSB CIC 4

Message Type 5

BICC packet structure

Routing LabelThe label contained in a s ignalling m ess age, and used by the relevant user part to identify

particulars to which the message refers. It is also used by the Mess age Transfer Part to
http://www.itu.int/ITU-T/


3/18



route the mes sage towards its des tination point.

Call Instance Code (CIC)The allocation of call instance codes to individual circuits is determined by bilateral

agreement and/or in accordance with applicable predetermined rules .

Message Type CodeThe message type code consis ts of a one octet field and is mandatory for all messages .

The message type code uniquely defines the function and format of each ISDN Us er Part

message. Each message consists of a number of parameters. Message types may be:

6

9

44

24

26

23

41

25

27

7

5

47

32

33

31

8

1

12

16

18

14

2

13

45

Address complete.

Answer.

Call progress .

Circuit group blocking.

Circuit group blocking acknowledgement.

Circuit group reset.

Circuit group reset acknowledgement.

Circuit group unblocking.

Circuit group unblocking acknowledgement.

Connect.

Continuity.

Confusion

Facility accepted.

Facility reject.

Facility request.

Forward transfer.

Initial address.

Release.

Release complete.

Reset circuit.

Resume.

Subsequent address .

Suspend.

User-to-user information.

ParametersEach parameter has a name which is coded as a s ingle octet. The length of a parameter

may be fixed or variable, and a length indicator for each parameter may be included.


4/18



Enlarge More Details

Interested in more details about testing this protocol?

BISUP

Recommendation Q.2763 (02/95).

http://www.itu.int/ITU-T/.

The B-ISDN User Part (B-ISUP) is applicable to international B-ISDN networks. In addition,

the B-ISDN User Part is s uitable for national applications. Most mess ages and parameters

specified for international use are also required in typical national applications. Moreover,coding space has been reserved in order to allow national administrations and recognized

operating agencies to introduce network specific signalling messages and parameters

within the internationally standardized protocol structure.

B-ISDN user part messages are carried on the ATM signalling link by means of S-AAL

service data units, the format of which is described in 6.2/Q.2110.

As a national option B-ISDN user part messages can be carried on the STM signal ling l ink

by means of signal units, the format of which is described in 2.2/Q.703.

The format of, and the codes used in the service information octet are described in

14.2/Q.704. The service indicator for the B-ISDN user part is coded 1001.

The signalling information field of each mes sage s ignal unit containing an B-ISDN user

part message consists of an integral number of octets and encompass es the following

parts:

a) routing label;

b) message type code;

c) message length;

d) message compatibility information;

e) message content.

The structure of the B-ISUP protocol is as follows:

8 7 6 5 4 3 2 1 Octets

Message Type 1

Length Indicator 2
http://www.itu.int/ITU-T/http://www.radcom.com/Solutions.aspx?BoneId=677&ObjId=-1&=&=&=&staticName1=1&staticName2=http://www.radcom.com/Technologies.aspx?BoneId=376&ObjId=-1&=&=&=&staticName1=1&staticName2=http://www.protocols.com/pbook/ScreenCaptures/BICC.gif


5/18



3

Ext. Broadband/narrow-

band interworking

ind

Pass on

not

possible

ind

Discard

message

ind

Send

notification

ind

Release

call ind

Transit

at

intermed

exch.

ind

4

Message TypeThe different message types. The following mess age types are available:

0x01 INITIAL ADDRESS0x02 SUBSEQUENT ADDRESS

0x05 CONSISTENCY CHECK REQUEST

0x06 ADDRESS COMPLETE

0x08 FORWARD TRANSFER

0x09 ANSWER

0x0A IAM ACKNOWLEDGE

0x0B IAM REJECT

0x0C RELEASE

0x0D SUSPEND

0x0E RESUME

0x0F RESET ACKNOWLEDGE

0x10 RELEASE COMPLETE

0x11 CONSISTENCY CHECK REQ ACK0x12 RESET

0x13 BLOCKING

0x14 UNBLOCKING

0x15 BLOCKING ACKNOWLEDGE

0x16 UNBLOCKING ACKNOWLEDGE

0x17 CONSISTENCY CHECK END

0x18 CONSISTENCY CHECK END ACK

0x2C CALL PROGRESS

0x2D USER-TO-USER INFORMATION

0x2F CONFUSION

0x32 NET RESOURCE MANAGMENT

0x34 USER PART TEST

0x35 USER PART AVAILABLE

0x38 SEGMENTATION

Message LengthThe mess age length in octets.

Broadband/narrow-band Iinterworking Ind:0 Pass on

1 Discard message

2 Release call

3 Reserved

Pass on not Possible IndicatorThe following indicators are available0 Release call

1 Discard information

Discard Message IndicatorThe following indicators are available

0 Do not discard message

1 Discard message

Send Notification IndicatorThe following indicators are available

0 Do not send notification


6/18



1 Send notification

Release call indicatorThe following indicators are available

0 Do not release call

1 Release call

Transit at intermed exch. IndicatorThe following indicators are available

0 Transit interpretation

1 End node interpretation



DUP

ITU-T recommendation X.61 (Q.741)

http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q741.html

The Data User Part (DUP) defines the necessary call control, and facility registration and

cancellation related elements for international common channel signalling by use of

Signalling System No. 7 for circuit-switched data transmiss ion services. The data signalling

mes sages are divided into two categories:

Call and circuit related mes sages: used to set up and clear a call or control and

supervise the circuit state.

Facility registration and cancellation related mess ages: used to exchange

information between originating and destination exchanges to regis ter and cancel

information related to user facilities.

The general format of the header of call and circuit related mes sages is s hown as follows:

15 8 7 0

OPC DPS

BIC OPC
http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q741.htmlhttp://www.radcom.com/Solutions.aspx?BoneId=677&ObjId=-1&=&=&=&staticName1=1&staticName2=http://www.radcom.com/Technologies.aspx?BoneId=376&ObjId=-1&=&=&=&staticName1=1&staticName2=http://www.protocols.com/pbook/ScreenCaptures/BISUP.gif


7/18



TCS BIC

Message specific parameters Heading Code

The general format of the header of facility registration and cancellation mess ages is

shown as follows:

15 8 7 0

OPC DPS

Spare bits OPC

Message specific parameters Heading code

Routing LabelThe label contained in a s ignalling m ess age and used by the relevant user part to identify

particulars to which the message refers. This is also use by the mes sage transfer part to

route the message towards its destination point. It contains the DPS, OPC, BIC and TSC

fields.

DPSThe destination point code (14 bits) is the code applicable to the data switching exchange to

which the mess age is to be delivered.

OPCThe originating point code (14 bits) is the code applicable to the data switching exchange

from which the mess age is sent.

BICBearer identification code (12 bi ts). For bearers which form part of a 2.048 Mbit/s PCM

system according to Recommendation G.734, the bearer identification code contains in the

5 leas t significant bits a binary representation of the actual number of the time slot which is

ass igned to the bearer. The remaining bits of the bearer identification code are used where

necessary, to identify one among several systems, interconnecting the originating point and

destination point. For bearers which form part of a 8.448 Mbit/s PCM system the bearer

identification code is coded in accordance with the scheme s pecified for the circuit

identification code for the corresponding case in Recomm endation Q.723.

TSCTime slot code (8 bits). If the data circuit is derived from the data multiplex carried by the

bearer, identified by the bearer identification code:

Bits 1-4 contain, in pure binary representation, the channel number of the circuit within the

12.8 kbit/s or 12 kbit/s phase; the channel number being in the range:

0-15 for 600 bit/s circuits

0- 3 for 2400 bit/s circuits

0- 1 for 4800 bit/s circuits

0 for 9600 bit/s circuits

Bits 5-7 contain, in pure binary representation, the number of the 12.8 kbit/s or 12 kbit/s

phase, the phase number being in the range 0-4;

Bit 8 is coded 0.

In the case where the data circuit uses the full 64 kbit/s bearer rate, the time slot code wi ll

be 01110000.

Heading codeThe heading code (4 bits) contains the mess age type code which is mandatory for all

mes sages . It uniquely defines the function and format of each DAP mes sage.

Message specific parametersContains specific fields for each message.


8/18



Spare bitsNot used, should be set to "0000".


ISUP

Q.763http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q763_23976.html

ISUP is the ISDN User Part of SS7. ISUP defines the protocol and procedures used to

setup, manage and release trunk circuits that carry voice and data calls over the public

switched telephone network. ISUP is us ed for both ISDN and non-ISDN calls. Calls that

originate and terminate at the same switch do not use ISUP signal ling. ISDN User Part

messages are carried on the signalling link by means of signal units. The signalling

information field of each message s ignal unit contains an ISDN User Part mess age

consis ting of an integral number of octets.

The format of the ISUP packet is shown in the following illus tration:

Routing label

Circuit identification code

Message type code

Mandatory fixed part - (Parameters)

Mandatory variable part - (Parameters)

Optional part - (Parameters)

ISUP packet structure

Routing labelThe label contained in a s ignalling m ess age, and used by the relevant user part to identify

particulars to which the message refers. It is also used by the Mess age Transfer Part to

route the mes sage towards its des tination point.

Circuit identification codeThe allocation of circuit identification codes to individual circuits is determined by bilateral

agreement and/or in accordance with applicable predetermined rules .

Message type codeThe message type code consis ts of a one octet field and is mandatory for all messages .

The message type code uniquely defines the function and format of each ISDN Us er Part

message. Each message consists of a number of parameters. Message types may be:

Address complete

Answer

Blocking

Blocking acknowledgementCall progress

Circuit group blocking

Circuit group blocking acknowledgement

Circuit group query @

Circuit group query response @

Circuit group reset

Circuit group reset acknowledgement

Circuit group unblocking

Circuit group unblocking acknowledgement

Charge information @

Confusion

Connect
http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q763_23976.htmlhttp://www.radcom.com/Solutions.aspx?BoneId=677&ObjId=-1&=&=&=&staticName1=1&staticName2=


9/18



Continuity

Continuity check request

Facility @

Facility accepted

Facility reject

Forward transfer

Identification request

Identification response

Information @

Information reques t @

Initial addressLoop back acknowledgement

Network resource management

Overload @

Pass-along @

Release

Release complete

Reset circuit

Resume

Segmentation

Subsequent address

Suspend

Unblocking

Unblocking acknowledgement

Unequipped CIC @

User Part available

User Part test

User-to-user information

ParametersEach parameter has a name which is coded as a s ingle octet. The length of a parameter

may be fixed or variable, and a length indicator for each parameter may be included.

ISUP decode

http://www.radcom.com/Solutions.aspx?BoneId=677&ObjId=-1&=&=&=&staticName1=1&staticName2=


10/18



MAP

EIA/TIA-41http://www.tiaonline.org.com

Mobile Application Part (MAP) messages sent between mobile switches and databases to

support user authentication, equipment identification, and roaming are carried by TCAP In

mobile networks (IS-41 and GSM) when a mobile subscriber roams into a new mobile

switching center (MSC) area, the integrated visi tor location register reques ts s ervice profile

information from the subscriber's hom e location register (HLR) using MAP (mobile

application part) information carried within TCAP mes sages .

The packet consists of a header followed by up to four information elements. The general

format of the header is shown here:

The format of the header is s hown in the following il lustration:

1 byte 1 byte

Operation specifier Length

MAP Parameters

...

MAP header structure

Operation specifierThe type of packet. The following operations are defined:

AuthenticationDirective

AuthenticationDirectiveForward

AuthenticationFailureReport

AuthenticationRequest

AuthenticationStatusReport

BaseStationChallenge

Blocking

BulkDeregistration

CountRequest

FacilitiesDirective

FacilitiesDirective2

FacilitiesRelease

FeatureRequest

FlashRequest

HandoffBack

HandoffBack2

HandoffMeasurementRequest

HandoffMeasurementRequest2

HandoffToThird

HandoffToThird2

InformationDirective

InformationForward

InterSystemAnswerInterSystemPage

InterSystemPage2

InterSystemSetup

LocationRequest

MobileOnChannel

MSInactive

OriginationRequest

QualificationDirective

QualificationRequest

RandomVariableRequest

RedirectionDirective

RedirectionRequest
http://www.tiaonline.org/


11/18



RegistrationCancellation

RegistrationNotification

RemoteUserInteractionDirective

ResetCircuit

RoutingRequest

SMSDeliveryBackward

SMSDeliveryForward

SMSDeliveryPointToPoint

SMSNotification

SMSRequest

TransferToNumberRequestTrunkTest

TrunkTestDisconnect

Unblocking

UnreliableRoamerDataDirective

UnsolicitedResponse

LengthThe length of the packet.

MAP parametersVarious parameters dependent on the operation.


MTP-2


Message Transfer Part - Level 2 (MTP-2) is a signalling link which together with MTP-3

provides reliable transfer of signalling messages between two directly connected signalling

points.

(Compliant with ITU Q.703 1994 and ANSI T1.111 199.)

The format of the header is s hown in the following il lustration:

7 8 bits

Flag

BSN (7 bits) BIB

FSN (7 bits) FIB

LI (6 + 2 bits)

SIO

SIF

Checksum(16 bits)

Flag

MTP-2 header structure

BSNBackward sequence number. Used to acknowledge message signal units which have

been received from the remote end of the signalling link.

BIBBackward indicator bit. The forward and backward indicator bit together with forward and

backward sequence number are used in the basic error control method to perform the


12/18


13/18



Q2140

Recommendation Q.2140.


The SSCF for NNI Signaling standard cons ists of the Service Specific Coordination Function

(SSCF) in conjunction with the Service Specific Connection Oriented Protocol (SSCOP)

which defines the Service Specific Convergence Sublayer (SSCS). The purpose of the

Service Specific Coordination Function is to enhance the services of SSCOP to meet the

needs of the requirements of the NNI level 3 protocol. In addition the SSCF at the NNI

provides communication with Layer Management for proper operation of signalling links.

The SSCF at the NNI is the uppermost sub-layer in the protocol stack for the SAAL at the

NNI. By construction, it utilizes the services of the underlying SAAL sub-layers, in

combination with its own functions, to provide an overall SAAL service to the SAAL user, as

described below.

The SAAL at the NNI provides s ignalling link functions for the transfer of signalling

mes sages over one individual signall ing data link. The SAAL functions provide a s ignalling

link for reliable transfer of signalling messages between two signalling points.

A signalling message delivered by the higher levels is trans ferred over the signalling link in

variable length Protocol Data Units (PDUs). For proper operation of the signalling link, the

PDU comprises transfer control information in addition to the information content of the

signalling message.

The protocol header structure is as follows:

8 7 6 5 4 3 2 1 Octets

Reserved 1

2

3

SSCF Status 4

SSCF TypeThe SSCF status:

1 Out of Service

2 Processor Outage

3 In Service

4 Normal

5 Emergency

7 Alignment Not Successful

8 Management Initiated

9 Protocol Error

10 Proving Not Succes sful


14/18


15/18



RLSD Released.

RLC Release Complete.

DT1 Data Form 1.

DT2 Data Form 2.

AK Data Acknowledgment.

UDT Unidata.

UDTS Unidata Service.

ED Expedited Data.

EA Expedited Data Acknowledgment.

RSR Reset Request.

RSC Reset Confirm.ERR Protocol Data Unit Error.

IT Inactivity Test.

XUDT Extended Unidata.

XUDTS Extended Unidata Service.

Mandatory fixed partThe parts that are mandatory and of fixed length for a particular message type wil l be

contained in the mandatory fixed part.

Mandatory variable partMandatory parameters of variable length will be included in the mandatory variable part. The

name of each parameter and the order in which the pointers are sent is implicit in the

message type.

Optional partThe optional part consists of parameters that may or may not occur in any particular

mes sage type. Both fixed length and variable length parameters may be included. Optional

parameters may be transmitted in any order. Each optional parameter will include the

parameter name (one octet) and the length indicator (one octet) followed by the parameter

contents.


TCAP


TCAP (Transaction Capabilities Application Part) enables the deployment of advanced

intelligent network services by supporting non-circuit related information exchange between

signalling points us ing the SCCP connectionless s ervice. TCAP messages are contained

within the SCCP portion of an MSU. A TCAP mes sage is comprised of a transaction portion

and a component portion.

(Compl iant with ITU recomm endation q.773.)

A TCAP message is structured as a single cons tructor information element consisting of

the following: Transaction Portion, which contains information elem ents used by theTransaction sub-layer; a Component Portion, which contains information elements used by

the Component sub-layer related to components; and, optionally, the Dialogue Portion,

which contains the Application Context and user information, which are not components.

Each Component is a constructor information element.

Tag Length Contents


16/18



TCAP packet structure

Information ElementAn information elem ent is firs t interpreted according to its pos ition within the syntax of the

mes sage. Each information element within a TCAP message has the sam e structure. An

information element consists of three fields, which always appear in the following order.

TagThe Tag dis tinguishes one information element from another and governs the interpretation

of the Contents. It may be one or more octets in length. The Tag is composed of Class ,

Form and Tag codes.

LengthSpecifies the length of the Contents.

ContentsContains the substance of the element, containing the primary information the element is

intended to convey.

TCAP Packet Types

TCAP packet types are as follows:

Unidirectional

Query with permission

Query without permission

Response

Conversation with permission

Conversation without permission

Abort


TUP

ITU-T Recommendation Q.723.

http://www.itu.int/ITU-T/.Signalling System No.7 - Telephone User Part.

The Telephone User Part (TUP) carries the telephone user messages on the signalling

data link by means of signal units.

The signalling information of each mess age constitutes the signalling information field of

the corresponding signal unit and consis ts of an integral number of octets. It basically

contains the label, the heading code and one or more signals and/or indications.

The service information octet comprises the service indicator and the subservice field.

The service indicator is used to associate signalling information with a particular User Part

and is only used with message signal units (see Recommendation Q.704, 12.2).

The information in the subservice field permits a distinction to be made between national

and international signalling messages. In national applications when this discrimination is

not required poss ibly for certain national User Parts only, the subservice field can be us ed

independently for different User Parts.

The TUP header structure is as follows:
http://www.itu.int/ITU-T/http://www.radcom.com/Solutions.aspx?BoneId=677&ObjId=-1&=&=&=&staticName1=1&staticName2=


17/18



8 7 6 5 4 3 2 1 Octets

Message Type Code 1

Message Type CodeThe message type code. The following m ess age type codes are available:

0x11 Initial Address

0x21 Initial Address With Additional Information

0x31 Subsequent Address

0x41 Subsequent Address With One Signal

0x12 General Forward Setup Information

0x32 Continuity Signal

0x42 Continuity Failure Signal

0x13 General Request

0x14 Address Complete

0x24 Charging

0x15 Switching Equipment Congestion Signal

0x25 Circuit Group Congestion Signal

0x35 National Network Congestion Signal

0x45 Address Incomplete s ignal

0x55 Call Failure Signal

0x65 Subscriber Busy Signal (electrical)

0x75 Unallocated Number Signal0x85 Line Out Of Service Signal

0x95 Send Special Information Tone Signal

0xA5 Acces s Barred Signal

0xB5 Digi ta l Path Not Provided Signal

0xC5 Misdialled Trunk Prefix

0xF5 Extended Unsuccessful Backward Setup Information

0x06 Answer Signal, Unqualified

0x16 Ans wer Signal, Charge

0x26 Ans wer Signal, No Charge

0x36 Clear Back Signal

0x46 Clear Forward Signal

0x56 Reanswer Signal

0x66 Forward Trans fer Signal0x76 Calling Party Clear Signal

0x17 Release Guard Signal

0x27 Blocking Signal

0x37 Blocking Acknowledgement Signal

0x47 Unblocking Signal

0x57 Unblocking Acknowledgement Signal

0x67 Continuity Check Request Signal

0x77 Res et Circuit Signal

0x18 Maintenance Oriented Group Blocking

0x28 Maintenance Oriented Group Blocking Acknowledgement

0x38 Maintenance Oriented Group Unblocking

0x48 Maintenance Oriented Group Unblocking Acknowledgement

0x58 Hardware Failure Oriented Group Blocking

0x68 Hardware Failure Oriented Group Blocking Acknowledgement

0x78 Hardware Failure Oriented Group Unblocking

0x88 Hardware Failure Oriented Group Unblocking Acknowledgement

0x98 Circuit Group Reset

0xA8 Circui t Group Reset Acknowledgement

0xB8 Software Generated Group Blocking

0xC8 Software Generated Group Blocking Acknowledgement

0xD8 Software Generated Group Unblocking

0xE8 Software Generated Group Unblocking Acknowledgement

0x1A Automatic Congestion Control Information

0x2C Metering Puls e Mes sage


18/18


0x1D Operator Signal

0x1E Subscriber Local - Busy Signal

0x2E Subscriber Toll - Busy Signal

0x1F Malicious Call Tracing Signal



SS7 Family Protocol Information

BICC | BISUP | DUP | ISUP | MAP | MTP-2| MTP-3 | Q2140 | SCCP | TCAP | TUP

Additional Information

Protocol Testing - Products

Protocol Testing - Solutions

Protocol Testing - Technologies

Directory |Acrony ms| Hot Links| Tech Papers| Register| Feedback | Adv ertising| SearchVoIP Testing | Network Monitoring | VoIP Monitoring | Network Analy zer | Wireless Monitor | Protocol Analyzer | N etwork

Analy sis | VoIP Call Generator | SIP Simulator | TCP/IP Analy zer
http://www.radcom.com/Products.aspx?BoneId=666http://www.radcom.com/Products.aspx?BoneId=673http://www.radcom.com/Products.aspx?BoneId=674http://www.radcom.com/Products.aspx?BoneId=832http://www.radcom.com/Products.aspx?BoneId=826http://www.radcom.com/Solutions.aspx?BoneId=759http://www.radcom.com/Products.aspx?BoneId=938http://www.radcom.com/Solutions.aspx?BoneId=1016http://www.radcom.com/Products.aspx?BoneId=658http://www.radcom.com/Products.aspx?BoneId=916http://www.protocols.com/index.htmhttp://www.protocols.com/v2/forms/ad.htmhttp://www.protocols.com/v2/forms/feed.htmhttp://www.protocols.com/v2/forms/register.htmhttp://www.protocols.com/v2/forms/register_wp.htmhttp://www.protocols.com/hot.htmhttp://www.protocols.com/stand.htmhttp://www.protocols.com/protocols.htmhttp://www.radcom.com/LeadForm1.aspx?BoneId=376&ObjID=-1&staticname1=1http://www.radcom.com/Solutions.aspx?BoneId=375&ObjId=-1&=&=&=&staticName1=1&staticName2=http://www.radcom.com/Products.aspx?BoneId=374&ObjId=-1&=&=&=&staticName1=1&staticName2=http://www.protocols.com/pbook/ss7.htm#TUPhttp://www.protocols.com/pbook/ss7.htm#TCAPhttp://www.protocols.com/pbook/ss7.htm#SCCPhttp://www.protocols.com/pbook/ss7.htm#Q2140http://www.protocols.com/pbook/ss7.htm#MTP-3http://www.protocols.com/pbook/ss7.htm#MTP-2http://www.protocols.com/pbook/ss7.htm#MAPhttp://www.protocols.com/pbook/ss7.htm#ISUPhttp://www.protocols.com/pbook/ss7.htm#DUPhttp://www.protocols.com/pbook/ss7.htm#BISUPhttp://www.protocols.com/pbook/ss7.htm#BICChttp://www.radcom.com/Solutions.aspx?BoneId=677&ObjId=-1&=&=&=&staticName1=1&staticName2=http://www.radcom.com/Technologies.aspx?BoneId=376&ObjId=-1&=&=&=&staticName1=1&staticName2=http://www.protocols.com/pbook/ScreenCaptures/TUP.gif

Ss7 Protocol Suite - Bicc _ Bisup _ Dup _ Isup _ Map _ Mtp-2 _ Mtp-3 _ q2140 _ Sccp _ Tcap _ Tup

Documents

Transcript of Ss7 Protocol Suite - Bicc _ Bisup _ Dup _ Isup _ Map _ Mtp-2 _ Mtp-3 _ q2140 _ Sccp _ Tcap _ Tup