SCCP Introduction
(4 intermediate revisions by one user not shown) | |||
Line 28: | Line 28: | ||
====SCCP GTT==== | ====SCCP GTT==== | ||
This represents the part of SCCP that is responsible with the translation of Global Titles.<br/> | This represents the part of SCCP that is responsible with the translation of Global Titles.<br/> | ||
− | Mainly this component will emit a sccp.route message each time a each time a GT needs to be translated. | + | Mainly this component will emit a sccp.route message each time a each time a GT needs to be translated.<br/> |
− | + | SCCP GTT implementation in Yate is located in ysig library. The methods declaration is in libs/ysig/yatesig.h and the implementation in libs/ysig/sccp.cpp. Classes name are SS7SCCP, GTT. | |
− | + | ||
− | =====SCCP GTT | + | ====SCCP management==== |
+ | This part of SCCP protocol offers a way to monitor the state of remote SCCP's and their applications.<br/> | ||
+ | Each time a remote SCCP state will change the SCCP management will emit a sccp.update message to inform all concerned parties about the state change. The informations are mainly used by GTT. | ||
+ | |||
+ | |||
+ | ===SCCP Messages=== | ||
+ | ====Data messages==== | ||
+ | * UDT. This is the simplest SCCP message. It is used to transfer data, between two SCCP endpoints, that does not require segmentation. | ||
+ | * XUDT. This message is like UDT but extended. It is used to transfer segmented data or other SCCP parameters like HopCounter. | ||
+ | * LUDT. This message is used to transfer long data. Usually is used over a SIGTRAN connection. | ||
+ | |||
+ | NOTE: In SCCP a message requires segmentation if the route to the destination contains a MTP2 link. The MTP2 link can transport a maximum of 272 octets including the MTP2 and MTP3 headers. | ||
+ | |||
+ | ====Management Messages==== | ||
+ | |||
+ | All Management messages have 3 important parameters: Affected Point Code, Affected SSN and status.<br/> | ||
+ | This is the list of management messages: | ||
+ | * SSA: Subsystem Allowed: This message is sent to inform a remote SCCP that the specified subsystem can receive messages. | ||
+ | * SSP: Subsystem Prohibited: This message is sent to inform a remote SCCP that the specified subsystem can not receive messages anymore. | ||
+ | * SST: Subsystem Status Test: This message is sent to a remote SCCP to find if the status of the specified subsystem has changed. | ||
+ | |||
+ | All the above messages are quite used in SCCP. But are some messages that are not so used: | ||
+ | * SOR: Subsystem Out of service Request. This message is sent to a remote SCCP to inform it that the specified subsystem requests to go OutOfService. | ||
+ | * SOG: Subsystem Out of service Grant. This message is sent to a remote SCCP as a response to a SOR request. | ||
+ | |||
+ | |||
+ | ===SCCP Configuration=== | ||
From sample ysigchan.conf: | From sample ysigchan.conf: | ||
Line 163: | Line 188: | ||
; sccp: string: The name of the sccp to attach to this GTT | ; sccp: string: The name of the sccp to attach to this GTT | ||
;sccp=sccp | ;sccp=sccp | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
===Status=== | ===Status=== |
Latest revision as of 11:19, 27 October 2017
SCCP stands for Signalling Connection Control Part.
SCCP represents a layer 4 protocol from SS7 signaling stack. It runs over a SS7 layer 3 protocol like MTP3 or M3UA. It provides:
- extended routing
- flow control
- segmentation
Contents |
[edit] SCCP in YATE
The SCCP implementation in YATE can be found in ysig library, the configuration samples in ysigchan.conf.sample.
An SCCP YATE instance is an "on demand" component. Basically this means that if you configure a SCCP section in ysigchan.conf but you do not reference it from a SCCP application (TCAP or GTT) the SCCP component will not be created.
[edit] SCCP components
The SCCP implementation is divided in three components:
[edit] SCCP
This represents the main component who is responsible for:
- message coding/decoding.
- segmentation.
- flow-control
- protocol logic.
[edit] SCCP GTT
This represents the part of SCCP that is responsible with the translation of Global Titles.
Mainly this component will emit a sccp.route message each time a each time a GT needs to be translated.
SCCP GTT implementation in Yate is located in ysig library. The methods declaration is in libs/ysig/yatesig.h and the implementation in libs/ysig/sccp.cpp. Classes name are SS7SCCP, GTT.
[edit] SCCP management
This part of SCCP protocol offers a way to monitor the state of remote SCCP's and their applications.
Each time a remote SCCP state will change the SCCP management will emit a sccp.update message to inform all concerned parties about the state change. The informations are mainly used by GTT.
[edit] SCCP Messages
[edit] Data messages
- UDT. This is the simplest SCCP message. It is used to transfer data, between two SCCP endpoints, that does not require segmentation.
- XUDT. This message is like UDT but extended. It is used to transfer segmented data or other SCCP parameters like HopCounter.
- LUDT. This message is used to transfer long data. Usually is used over a SIGTRAN connection.
NOTE: In SCCP a message requires segmentation if the route to the destination contains a MTP2 link. The MTP2 link can transport a maximum of 272 octets including the MTP2 and MTP3 headers.
[edit] Management Messages
All Management messages have 3 important parameters: Affected Point Code, Affected SSN and status.
This is the list of management messages:
- SSA: Subsystem Allowed: This message is sent to inform a remote SCCP that the specified subsystem can receive messages.
- SSP: Subsystem Prohibited: This message is sent to inform a remote SCCP that the specified subsystem can not receive messages anymore.
- SST: Subsystem Status Test: This message is sent to a remote SCCP to find if the status of the specified subsystem has changed.
All the above messages are quite used in SCCP. But are some messages that are not so used:
- SOR: Subsystem Out of service Request. This message is sent to a remote SCCP to inform it that the specified subsystem requests to go OutOfService.
- SOG: Subsystem Out of service Grant. This message is sent to a remote SCCP as a response to a SOR request.
[edit] SCCP Configuration
From sample ysigchan.conf:
; Example of a SS7 SCCP ;[sccp] ; type: keyword: identifies the component as a SS7 SCCP ;type=ss7-sccp ; pointcodetype: string: SS7 point code type (required) ; Allowed values: ; ITU ITU-T Q.704 ; ANSI ANSI T1.111.4 ;pointcodetype= ; localpointcode: string: Local point code to accept as destination (required) ; The format is network-cluster-member or number ;localpointcode= ; router: string: Name of the SS7 Router to attach to ; A boolean false value disables attaching a router (unlikely) ;router=ss7router ; network: string: Name of linkset to attach to if router is disabled ; This allows direct connection without MTP management (unlikely) ;network= ; management: string: Name of the SS7 management to use ;management=sccp-mgm ; hopcounter: integer: Default value for hop-counter ; This value indicates the maximum number of gt translations that can be ; made before the message reach it's destination ;hopcounter=15 ; ludt-support: boolean: True to allow sccp to send Long UnitData messages ;ludt-support=false ; segmentation-timeout: integer: Time in milliseconds before a segmented ; message is expired ; Values: 5000-20000 ms ;segmentation-timeout=5000 ; extended-monitoring: boolean: Compute an extended monitoring of sccp messages ;extended-monitoring=no ; print-messages: boolean: Print decoded protocol data units to output ; This option is applied on reload ; Defaults to no ;print-messages=no ; extended-debug: boolean: Print extended debug data (such as raw hex data) ; to output ; This option is applied on reload ; Defaults to no ;extended-debug=no ; endpoint: boolean: Force message processing if we are an endpoint ; This option will allow sccp to process failed gt translations messages ; if a ssn is pressent ;endpoint=true; ; local-dpc-only: boolean: Process only messages whose DPC equals localpointcode ; If turned off it will process (and possibly GTT) messages with any DPC ; This option is applied on reload ; Defaults to yes ;local-dpc-only=true ; Example of SS7 Sccp Management ;[sccp-mgm] ; type: keyword: identifies the component as a SS7 SCCP Management ; Values : ss7-sccp-itu-mgm ; Must correspond with the pointcode type of the sccp ;type= ; test-timer: integer: Initial time in milliseconds for Subsystem Status ; Test to be generated ; Values : 5000-10000 ; Note! This timer will increase exponentially until reaches 20000 if no ; corresponding message is received from the test initiator ;test-timer=5000 ; print-messages: boolean: True to print sccp management messages ;print-messages=false ; remote: struct: Remote SCCP witch present interest for GTT ; (Global Title Translator) ; This parameter allow us to monitor remote sccp's state ; This option can be repeated to monitor multiple remote sccp's ; Format: remote=pc(integer):ssn1,ssn2,.... ; pc : integer: Remote sccp pointcode ; ssn1 - ssnn: integer; Remote sccp subsystems witch we are monitoring ; Note! Ssn list may be empty if the remote sccp is a stp with GTT ;remote=2057:1,2,3,4 ; concerned: struct: List of remote sccp's witch are concerned about local state ; This parameter allow us to inform remote sccp's when local status has changed ; This option can be repeated to inform multiple remote sccp's ; Format: remote=pc(integer):ssn1,ssn2,.... ; pc : integer: Remote sccp pointcode ; ssn1 - ssnn: integer; List of local subsystems witch are of interest for the ; remote sccp ; Note! Ssn list may be empty if the remote sccp is concerned only if local ; sccp is available or not ;concerned=2057:1,2,3,4 ; local-subsystems: string: Coma separated list of local subsystems ; The subsystems present in this list will be monitored by this sccp management ;local-subsystems=1,2,3,4,5,.. ; auto-monitor: boolean: True to auto monitor remote sccp's. ; This flag enables remote sccp auto monitoring. When a message failed to be ; send to a remote sccp, the sccp management will automaticaly append the ; destination to the monitored remote sccp destinations ; to prevent sccp routing failure. ; NOTE! Do not use this option if your GTT (Global Title Translator) ; can route to a large number of remote addresses ; because a lot of memory and cpu power will be used! ;auto-monitor=false ; Example of GTT (Global Title Translator) ;[gtt] ; type: keyword: Identifies this component as a GTT ; NOTE! This type of gtt is based on yate messages system. ;type=ss7-gtt ; sccp: string: The name of the sccp to attach to this GTT ;sccp=sccp
[edit] Status
To check status of compotent use "status sip component_name".
Ex: "status sig sccp", "status sig gtt"
[edit] Control
SCCP component control commands:
status | control SCCP_NAME status | Show status |
full-status | control SCCP_NAME full-status | |
enable-extended-monitoring | control SCCP_NAME enable-extended-monitoring | |
disable-extended-monitoring | control MTP3_LINKSET_NAME disable-extended-monitoring | |
enable-print-messages | control SCCP_NAME enable-print-messages | |
disable-print-messages | control SCCP_NAME disable-print-messages |
[edit] SCCP usage scenarios
SCCP can be used in multiple scenarios, but this are the most known:
[edit] SCCP in STP
SCCP can be used in a STP.
This scenario is used to take advantage of the SCCP extended routing.
Basically we will find a combination of SCCP and GTT.
[edit] SCCP in SEP
In a SEP the SCCP role is to deliver the received messages to the SCPP applications above him(TCAP).
[edit] SCCP decoder
This is a special non-standard feature of YATE.
The SCCP can be used as a SCCP message decoder. This case can be found if it is used with M3UA-GW.
YATE M3UA-GW has the ability to route messages to ASPs based on SCCP GT or/and SSN, in this way the SCCP is used to decode the SCCP message for M3UA-GW so that the gateway can look for the routing parameters.
[edit] SCCP address translation
SCCP can be used as a bridge for two different point code types. For example it can receive messages from point code 1 international and send the message to point code 1 national.
[edit] SCCP Segmentation
SCCP may segment messages based on message length and SS7 network topology.
This meens that if a SS7 message exceeds the limit for a TDM link, the message will be segmented by SCCP and in multiple XUDT messages.
If the topology of the SS7 network is known and the SCCP needs to send a message only over SIGTRAN than it will send it in one or multiple LUDT messages.
In MTP3 configuration section exists two parameters: route and adjacent.
Adjacent represents the pointcode of the remote end of the Layer2 links.
Route can be repeated and represents the destination pointcodes that this linkset knows about.
When you configure the adjacent and the route parameters you can set the size of the path. This represents the maximum nuber of octets that can be transmited over the route. Default is 272 (TDM maximum size), but if you know that for example you have only M2PA links between local node and the adjacent node than you can specify the size of the route to 4000.
In this way when SCCP needs to send a message that exceeds the limits of a TDM link, after will obtain the route for the destination of the message will limit the message to worse link message size.
For example lets say that SCCP from SEP1 has a large message to send to SEP.
The link between STP2 and SEP1 is a M2PA link so it will send a LUDT message to STP2.
STP2 receives the message and detects that it has to send it to STP2. Link between STP2 and STP1 also M2PA so STP2 will send a LUDT message to STP1.
STP 1 receives the message and detects that it has to send it to SEP.
STP1 and SEP are connected with two links. On is M2PA and one is MTP2.
If size parameter is correctly set than SCCP on STP1 will detect that the maximum size that it can send is 272 and will segment the message and send it in multiple XUDT messages.