SigTran (Signaling Transport, Signaling Transfer Protocol) protocol stack supports signaling of traditional circuit switched network SCN (Switch Circuit Network, Circuit Switching Network) via IP network transmission. The protocol stack supports the inter-layer standard primitive interface in the definition of the SCN signaling protocol hierarchy, ensuring that the existing SCN signaling application can be used without modification, while using the standard IP transport protocol as the transmission underlayer, by increasing Its features meet the special transmission requirements for SCN signaling.
SigTRAN protocol stack controls communication between signaling gateways and media gateway controllers, there are two main functions: adapter and transmission. Correspondingly, the SigTRAN protocol stack contains two-layer protocol: transfer protocols and adaptation protocols, the former is SCTP / IP, the latter, such as M2ua (adapted MTP2 users), IUA (adapt Q.921 users), etc. The SigTRAN protocol model is shown in Figure 2-1.
M3ua: MTP3 User Adaptation Layer M2ua: MTP3 User Adaptation Layer IUA: ISDN Q.921 User Adaptation Layer M2PA: MTP2 Peer Adaptation Layer V5UA: V5 User Adaptation Layer SUA: SCCP User Adaptation Layer SCTP: Flow Control Transfer Protocol IP: Internet Protocol Mac: Media Access Control
Figure 2-1 SigTRAN protocol model
The SigTRAN protocol is just the adaptation and transmission of SCN signaling, and does not process user layer signaling messages. In order to ensure reliable transmission of signaling, SCTP is introduced as a transport layer protocol.
The SIGTRAN protocol of Softx3000 applies contains Mac, IP, SCTP, M2UA, and M3ua. Due to the network layer The following protocol (Mac, IP) is a standard TCP / IP protocol family, refer to this manual appendix.
2.1.1 SigTran Application in Softx3000
The SoftX3000 is connected to the SG connection through the SigTran protocol, and the narrowband circuit switched web signaling (such as SS7 ISUP, INAP, etc.) is transmitted through the IP network. SigTRAN is shown in Figure 2-2 in Softx3000.
Figure 2-2 Application of SigTran in SoftX3000
The SigTRAN protocol is applied to the interface between the signaling gateway (SG) and SOFTX3000, and the narrowband SCN signaling is transmitted in the IP network. The principle is as follows:
Circuit switched network signals are accessed by the signaling gateway (SG), while the media stream (such as a secondary circuit) is connected by the Media Gateway (TMG). The signaling gateway packages narrow-band signaling layers (or directly narrow signaling) package to the media gateway controller (ie Softx3000), media gateway controller processing signaling, through the media gateway control protocol (H.248) Control the carrying connection of the media gateway to complete the interoperability of the circuit switched network and the packet switched network. In this model, the Signaling Gateway and the Media Gateway controller run the SigTRAN protocol stack.
According to the SG position, SoftX3000 provides three ways to SCR signaling:
1. SG built in Softx3000
The SoftX3000 directs the TDM interface and SCN connections, using MTP signaling, and does not use the SigTRAN protocol.
2. SG built in TMG
TMG completes SCN signaling conversion and adaptation by built-in SG, and is a IP package to transfer to Softx3000 in IP network, signaling transmission using the M2UA adaptation protocol of the SigTRAN protocol. 3. Independent SG 2.1.2 Terminology
Media Gateway (MG)
SG completes SCN signaling conversion and adaptation, and packets into the IP package to transfer to Softx3000, signaling transmits the M3UA adaptation protocol using the SigTran protocol.
When the media stream flows from the SCN to the packet network, the MG ends the SCN media stream, package media data (if the media data is not a packet-based form), and passes the packaged service to the packet network. When the media stream flows from the packet network to the SCN, the opposite function is performed.
2. Media Gateway Controller (MGC)
MGC is responsible for handling registration and management of resources on MG. MGC may have this capability: the use of resources in accordance with local strategies; for signaling transmission, MGC may have this capability: end and initiate SCN signaling protocols, such as SS7-ISUP and Q.931.
3. Signaling Gateway (SG)
SG is a signaling agent that can receive / send SCN internal signaling on an IP network edge. The SG function in the SS7-Internet gateway includes relay, translation or end of SS7 signaling. The SG function may also coexist with the MG function in the MG, processing the device-related SCN signaling (eg, signaling backhaul).
2.2 SCTP
2.2.1 Overview
SCTP terminology
(1) Transfer address and IP address
The SCTP transfer address is an IP address plus an SCTP port number. The SCTP port number is SCTP to identify users on the same address, and the TCP port number is a concept. For example, IP address
10.105.28.92 and SCTP port number 1024 identify a transmission address, and 10.105.28.93 and 1024 identify another transmission address, similarly, 10.105.28.92 and port number 1023 also identify a different transmission address.
(2) Host and endpoint
"Host) is a computer, with one or more IP addresses, is a typical physical entity.
"End Point" is the basic logic concept of SCTP, which is a logical sender and recipient of the datagram, a typical logic entity.
The SCTP protocol specifies that the two endpoints can only be established, but there can be many endpoints on a host.
(3) Coupling and flow
"Association is the logical connection or channel of data transferring data transferred by two SCTP ends through the 4-way handheld mechanism specified by the SCTP protocol.
"Stream" is a feature term for the SCTP protocol. Strictly, "stream" is a one-way logic channel from one end point to another endpoint. The data that wants to pass in order must be transferred in a stream.
One conjugate can contain multiple streams.
(4) TSN and SSN TSN (Transmission Sequence Number), transfer sequence numbers. A coupled in SCTP
One end assigns a 32-bit sequence number based on the initial TSN to each data block sequence for the local end to confirm when it is received. The TSN is based on coupling maintenance.
The SSN (Stream Sequence Number) streamlines, within each stream of SCTP, sequentially assigns a 16-bit sequence number to each data block sequentially transmitted in this stream to ensure the order within the stream. SSN is based on stream maintenance.
The assignment of TSN and SSN is independent of each other (5) other CWnd: congestion window. SCTP is also a sliding window protocol, and the congestion window is for each purpose.
The address maintenance is adjusted according to the network condition. When the transmission of the destination address is not confirming that the message length exceeds its CWnd, the endpoint will stop sending data to this address.
RWND: Receive the window. RWND is used to describe a coupling-to-end reception buffer size. During the coupling process, both parties will exchange the initial RWnd of each other. RWND will be transmitted according to data transmission, confirming, instant changes. The size of the RWND limits the size of the data that SCTP can send. When RWND is equal to 0, the SCTP can also send a datagram to identify the change in the other-buffer until the CWND limit is achieved by confirming the message.
2. SCTP concept
SCTP (Stream Control Transmission Protocol, Flow Control Transfer Protocol) is a reliable datagram transfer protocol that provides protocols (such as IP) based on unreliable transmission services. SCTP is designed to transmit SCN narrowband signaling messages via IP network. SCTP has improved TCP's defects, so that signaling transmission has higher reliability, SCTP design includes appropriate congestion control, preventing flooding and camouflage attacks, better real-time performance and multi-standard properties. SCTP is considered a transport layer protocol that is applied as a SCTP user, and the lower layer is a packet network. In the application of the SigTran protocol, the SCTP upper user is an adaptive module of SCN signaling (such as M2ua, M3ua, etc.), and the lower layer is an IP network.
The SCTP protocol has the following characteristics:
•
Transmission protocol based on user message pack;
•
Support for the order or disorderly delivery of the internal user datagram;
•
A plurality of streams can be established in one coupling, and the transmission of data between streams does not interfere;
•
By supporting multi-belonging to improve the reliability of the coupling at one or both ends;
•
The coupling needs to be esed
Cookie
Certification guarantees the coupling security;
•
Real-time path fault test function.
3. SCTP function
The function of SCTP mainly includes the launch and closing of the connection, the internal order transmission, user data fragmentation, confirming and eliminating congestion, message block bundle, packet verification, and path management.
•
Coupling start and close
SCTP
It is a conjugated transport protocol, usually, data only has two ends that have been established.
Come during the point to pass (
SCTP
Allows the specific steps during the coupling process to deliver data). Therefore, the coupling establishment and closing is
SCTP
Provide other services premise.
•
Inland order transmission
SCTP
Providing a datagram sequence transfer, order-transmitted data reports must be paid in a "stream". The flow is the cornerstone of the order.
•
User data fragmentation
SCTP
By the maximum transfer path
PMTU
Detection, implementation
SCTP
The layers will be packaged in large user data.
IP
Multiple fragmentation, reorganization, can reduce the router
IP
Layer burden.
•
Confirmation and avoiding congestion confirmation and retransmission is the agreement to ensure the reliability of the transmission reliability.
SCTP
The same is true. Confirmation mechanism is
SCTP
Keep the cornerstone of the transport reliability. Congestion avoids follow
TCP
Window mechanism for proper flow control.
•
Block binding
If a short user data is taken a big one
SCTP
The message header transmits efficiency is very low, and several user data can be bound in one.
SCTP
The message is transmitted to increase the utilization of bandwidth.
•
Packet verification
Packet verification is
SCTP
Provide cornerstone with error-free transmission.
SCTP
By use of user data
ADLER-32
Algorithm, calculate one
32
Bit checksum, with in the datagram, the same operations in the receiving end, verify that the user data is destroyed by checking the checksum. •
Path management
Through heartbeat, the cumulative retransmission, SCTP will manage the destination address, the accessibility of the endpoint.
From the above description, we can see several differences between SCTP relative to TCP:
(1) TCP is based on character stream transmission, and the upper layer must have its own trimming mechanism. SCTP is based on datagram. No upper-layer delimitation. (2) SCTP supports multiple IP address configurations. (3) SCTP proposes the concept of flow and sequentially transmits in the stream. 2.2.2 SCTP Message
The SCTP message package is in the user data field, and Table 2-1 lists the main message types. Table 2-1 SCTP message
Name Description Data (Net Data) User Data Blocks. INIT is used to initiate SCTP connections between two endpoints. INIT ACK is used to confirm the SCTP connection initiation message (INIT). Sack This data block is sent to the peer to confirm that the DATA block is received and the receiving order gap of the peer DATA is notified. The HeartBeat endpoint sends the data block to the peer to detect the reaches of a certain destination address defined in the current connection. HeartBeat Ack Responsive HeartBeat message. Abort is closed. One endpoint in the shutdown connection initiates a Graceful shutdown. ShutDown Ack Responds to the shutdown message, is issued when the program is turned off. ERROR notifies the peer, SCTP connection has something wrong. The cookie echo is only used to connect the initiator, which is sent by the connected initiator to the peer to complete the initiator. Cookie ACK Cookie Echo Message SHUTDOWN The shutdown ACK message is confirmed when the program is complete.
2.2.3 Signaling Process
SCTP as a connection-oriented reliable transport layer protocol, the protocol process includes: coupling, coupling termination, data transfer, and confirmation, plus a congestion control mechanism, path management mechanism.
Connected establishment
The process of SCTP coupling is 4 steps. There are 4 messages interactions: init, init Ack, cookie echo, cookie ack. As shown in Figure 2-3.
Endpoint a endpoint z
Established
Figure 2-3 Coupling establishment process message interaction
(1) The coupling start is first to create a data structure TCB (transmission control block) to describe the upcoming this coupling (including the coupling basic information), then sends an init message to the peer. In this message, the parameters generally bring one or more IP addresses used on the local end (if not, the source address sent by the INIT message as the address of the endpoint). In the universal header, because the TAG of the other party is still not known, zero will be set zero. In the message parameter, the number of TAGs and desired input and output flows must be taken on the message parameters. After sending an init timer, wait for the other party's INIT ACK message, the timer is going to reissue init until you reach the maximum number of retransmission. After these movements are completed, the initiator enters the cookie-wait state. (2) After the coupled receiving end receives the INIT message, a TAG will be placed as the initial TAG as the primary TAG in the parameter of the init ACK message. A TCB is then generated according to the coupling basic information, but this TCB is a temporary TCB. After this TCB generation, the necessary information (which includes a cookie generated timestamp and the life of the cookie) and the algorithm of the key to the algorithm described via the algorithm described by RFC 2401 (this calculation is irreversible) of). Then combine those necessary information and this MAC into a parameter called State Cookie, which is included in the Init Ack message. The Verification Tag of the General Head of the INIT ACK message is set to the value of the initial TAG in the init message. The INIT ACK message generally also belts information such as the address, input and output streams, etc. Send the init Ack to the peer, delete the temporary TCB, (so, the acceptable end does not reserve any resources for this coupling). (3) The coupling initiator is returned to the init Ack and stop the INIT timer. Update your own TCB, fill in the information obtained from the init Ack. Then generate a cookie echo message, bring the State cookie in the init Ack back. Start the cookie timer. State transfer to cookie-echoed. (4) After the coupling receiving end receives the cookie echo message, Cookie verification is performed. The TCB section in State Cookie and the local key are calculated based on the MAC algorithm of the RFC 2401, and the MAC carries the MAC in the STATE cookies is compared, and the message is discarded if the difference is different. If the same, take out the timestamp of the TCB portion, and the current time comparison, see if the time has exceeded the life period of the cookie. If so, discard it. Otherwise, a coupled coupling is established according to the information in the TCB. Migrate the status into the Establish and return the cookie ACK message. (5) The coupling initiator receives the cookie ACK message, stops the cookie timer, and moves to the Establish. Such a coupling process is completed. 2. Coupling termination
The termination of SCTP coupling is two, one is the termination of Graceful, one is the termination of UNGRACEFUL. The former guarantees that all ends of the ends have not transmitted, and the unconfirmed data is transmitted and confirmed before terminating the coupling. The latter will directly terminate the coupling and discard the data.
(1) GRACEFUL closes Graceful's coupling termination is completed by three-step handshake: (2) First, the user terminating the initiator requests graceful to terminate the coupling. The SCTP coupling moves from the Establish state to the shutdown-pending state. In this state, SCTP does not accept any data transmission request on this coupling. At the same time, wait for all the ended confirmation of the unconfirmed data to get the peer. (3) When all local ends send unconfirmed data, send a shutdown message to the peer to the shutdown-sample state, launch the shutdown timer, and wait for the peer shutdown-Ack message. In this state, it is confirmed immediately after receiving the peer (later, the SCTP application delay confirmation mechanism) is said. (4) After receiving the SHUT DOWN message, the peer receives the shutdown-revD state, and no longer receives the data transmission request on this coupling. When all the endless data and the transmitted data and the unconfirmed data are sent and confirmed, the shutdown ACK message is sent. Start the shutdown timer Wait to the Shutdwon Complete message. (5) After the start of the launch of the shutdown Ack message, stop the shutdown timer, send the shutdown completion message to the peer. Delete the coupling TCB. (6) After receiving the SHUTDOWN Complete message, the peer is removed. (7) Ungraceful Close This shutdown is relatively simple because the security is not considered. When the initiator sends an ABORT message to the peer, remove the coupling TCB immediately. The coupled TCB immediately removes the coupling TCB after receiving this ABORT message.
2.3 M2ua
When SG is built into TMG, TMG completes SCN signaling and adaptation by built-in SG, and the IP package is transmitted to SOFTX3000, the TMG and SOFTX3000 signaling transmits using the M2UA adaptation protocol of the SigTRAN protocol.
2.3.1 Overview
1. M2ua concept
M2ua (SS7 MTP2-User Adaption Layer Protocol, MTP2 User Adapter Protocol), which uses traffic control Transfer Protocol (SCTP) or other suitable transport protocols, user signaling messages (ie, MTP3) that transmits SS7 MTP2 layers (ie, This protocol can be used to signal signaling between signaling gateways (SG) and Media Gateway Controllers (MGCs), as shown in Figure 2-4.
Figure 2-4 Location of M2UA in the system
As shown in Figure 2-4, SEP (signaling endpoint) narrowband signaling is connected to the MGC through the SG (Signaling Gateway), and the M2UA runs on the upper layer of SCTP, which is the SCTP user. The upper layer of the MGC side M2UA is MTP3, and the SG is MTP2.
In the following description, some concepts about M2UA are used, and these concepts are described in Table 2-2.
Table 2-2 M2UA basic concept
Abscape Name Description IID Interface ID The communication between the two ends of M2ua can be identified by text or integer. Each interface ID corresponds to an actual physical link. The interface ID is the logical ID of the SS7 signaling link for SG and ASP. AS Application Server (Application Server) A logical entity represents a certain resource, corresponding to a specific "routing context". For M2ua, AS is a set of interface IDs. Each AS contains a set of application server processes (ASPs), one or more ASPs can handle services. ASP Application Server Process ASP is an instance of an AS process. Each ASP contains a SCTP endpoint, and an ASP can serve multiple AS. In M2UA applications, ASP works in master / alternative ways, only the main ASP processing business. Signaling Backhaul When the MG built-in SG function, if the signaling is not handled in the local processing, the interface of the signaling from the coupling data stream (ie MGC) is transmitted. • M2UA link "M2ua Link" is a newly introduced concept similar to MTP LINK.
In order to configure the M2ua stack, the user must also configure SG, AS, and ASP. To avoid this overhead, implement the M2UA configuration function of the user, introduced the M2UA Link concept so that the user can manage and maintain the link.
M2UA LINK: The logical connection created between SG and ASP. A link includes SG, ASP, and SCTP connections between SG and ASP. Its status and ASP status and SCTP connection status correspond.
The network structure of M2UA is shown in Figure 2-5. After introducing M2UA Link, the M2UA network structure can be simplified as shown in Figure 2-6.
MGC
LINK0 and LINK 1
LINK2 and LINK 3
Figure 2-5 M2UA network structure
MGC
MTP2 LINK 0 M2UA LINK 0 (Servered for MTP2 Link 0and Link1)
MTP2 LINK 1 MTP2 LINK 2 MTP2 LINK 3
Figure 2-6 Simplified network structure of M2UA
The M2UA link provides a link channel for one or more MTP2 for communicating with its users (MTP3). Each MTP link is mapped to a specific M2UA link through the M2UA interface ID. Thus, data from the MTP link can be transmitted through the M2UA link.
2. M2UA business function
M2ua provides the following services:
•
stand by
MTP2 / MTP3
Interface boundary, for
PSTN
with
IP
Net
MTP2
The user provides seamless operation.
•
stand by
SG
with
MGC
Management communication between management.
•
management
SG
with
MGC
between
SCTP
connection.
2.3.2 m2ua message
Message format
The M2UA message encapsulates the user data field of the SCTP message, contains the public message header, the M2ua message header.
•
Public message head
M2ua
The public message head includes version, message level, message type, message length, and message content.
•
M2ua
Message head
M2ua
Message head and
MAUP
Working together.
The header includes labels, length, and interface identifiers. The interface identifier is used to identify the physical interface on the SG of the signal to receive the signaling message. The format of interface identification parameters can be text or integers, and their values are allocated according to network operation policy. The value used is negotiated between SG and ASP.
2. M2UA message
•
M2ua
news:
•
ASP
Maintenance message:
Message Name Description DATA contains SS7 MTP2 - User Protocol Data Unit (PDU). TTC DATA includes TTC SS7 MTP2 - User Protocol Data Unit (PDU). ESTABLISH (Request, when the MGC requires SS7 link service, it will send a Establish Confirmation request message to the gateway, the gateway recipients establish a confirmation message (Establish Confirmation). Release (Release Request) message is used to release channels. Release confirmation and indication, Release Indication, Confirmation is used to indicate confirmation that the channel has been confirmed. The MGC is sent to trigger a state request on a specific SS7 link supported by SG. State Confirm is sent by the SG to respond to the State Request message issued by the MGC. State Indication is sent from the SG to the ASP, indicating the status of the link. Congestion is sent from SG to ASP, indicating the discard state of the congestion state and the link. Indication Retrieval (Request, Confirm) Retrieval Request Message For MTP Trimod Transduction Process, request BSN to recover PDUs from the forwarding queue, or clear the PDU from the recovery queue. SG sends a RetrieVal Confirm message to the queue. Retrieval Indication is sent by the SG with a PDU from the retransmission queue. Retrieval Complete Indication with RETRIEVAL REQUEST, in addition, it also indicates the last PDU that contains from the retrace queue. Message Name Description ASP UP is used to indicate the remote M2UA, and the adaptation layer is ready to receive a service or maintenance message. ASP UP ACK is used to confirm an ASP UP message from the remote M2UA. ASP DOWN is used to indicate the remote M2UA, and the adaptation layer does not have a preparation for receiving business or maintenance messages. ASP Down ACK is used to confirm an ASP Down message that receives the remote M2UA. The ASP Active is sent by the ASP and indicates that it is active and can be used. ASP Active ACK is used to confirm the ASP-Active message sent from the remote M2UA.
Message Name Description ASP Inactive is sent by ASP, indicating that it is no longer an active ASP. ASP INACTIVE ACK is used to confirm the ASP-INACTIVE message received from the remote M2ua.
• Layer management message:
Message Name Description Error is used to notify the peer-to-peer error event. NOTIFY is used to provide M2ua autonomous instructions to the peer M2ua.
3. Message example
• Data
The DATA message includes SS7 MTP2 - User Protocol Data Unit (PDU). The format of the data message parameter is as follows:
The protocol data field includes MTP2 - user application messages, starting from the signaling information eight-bit group (SIO) according to the network byte order.
• Establish (Request, Confirm):
It is already created for creating a link or indication channel. When the MGC wants the SS7 link online, it will send a creation request message. If SG has created an SS7 link at this layer, send Establish Confirm messages and does not take other measures. • ASP UP
The ASP UP message is used to indicate the remote M2ua, the adaptation layer is ready to receive business or maintenance messages.
The INFO string is an optional parameter that can carry any meaningful 8bit ASCII string along with the message. The length of the INFO string parameter ranges from 0 to 255 characters.
2.3.3 Signaling Process
Create a business environment
The creation program of the M2UA business environment is shown in Figure 2-7. A SCTP connection must be created between the SG and MGCs before the M2UA business environment created.
Figure 2-7 Creation program for M2UA business environment
The MGC acts as a client, which first initiates a request for the creation environment. Once the environment is created, M2UA data, MGC maintenance messages, and layer management messages can be passed between the two ends.
2. Data transfer process
If an ASP's M2UA layer has a MAUP message to be sent to SG, it will do the following:
•
Determine correct
SG
;
•
Obtain
M2ua
Link number;
•
Find with the selected
SG
of
SCTP
connection;
•
Determine
SS7
Link
SCTP
The proper stream of the connection;
•
filling
MAUP
news,
M2ua
Message, public message header, generated
M2ua
Message unit;
•
by
SCTP
Connection
MAUP
Message
SG
of
M2ua
. If
SG
Up
M2ua
One
MAUP
Message is sent
ASP
It will do the following:
•
Get interface ID;
•
Determine support
MTP
Link
M2ua
Link number;
•
set up
SCTP
connection;
•
Determine
SS7
Link
SCTP
The proper stream of the connection.
•
filling
MAUP
news,
M2ua
Message, public message header, generated
M2ua
Message unit;
•
by
SCTP
Connection
MAUP
Message
ASP
of
M2ua
.
3. Release Process M2UA Business Environment The release program is shown in Figure 2-8:
Figure 2-8 Release process of M2UA business environment
The SG receives the release of the MGC, starting the release process of the M2UA business environment, and shuts down the SCTP connection.
2.4 m3ua
2.4.1 Overview
Terminal
•
IP
Server process (
IPSP
)
based on
IP
Application process instance. Essentially
IPSP
versus
ASP
Same, just
IPSP
Use a point-to-point
M3ua
Not using the business of the signaling gateway.
•
Signaling gateway process (
SGP
) One
SG
Procedure example, status is activated
/
spare
/
Load sharing.
•
Route keyword selection keyword description
SS7
Signaling parameters and parameter values (such as
DPC
,
SiO DPC
,
SiO DPC OPC, SiO DPC OPC CIC), uniquely defines signaling services that are processed by a particular application server. The parameters in the selection keyword cannot be encoded based on multiple destination signaling points.
2. M3ua concept
M3ua is an SS7 MTP3 user adaptation layer that provides primitive communication services to MTP3 users in an IP network, which provides primitive communication services in the network edge (on SG), implement TDM SS7 and IP interchange. M3UA supports the following features:
•
Seventh Signaling Signal Code
in
SS7
In the signaling network, the signaling gateway is used to represent
IP
A set of nodes in the domain is used to pass the way
SS7
Signaling network.
SG
Aside
SS7
A physical node of the signaling network must have
SS7
Signaling point encoding.
•
Loop function
SGP
with
AS
between
SS7
The allocation of signaling messages is determined by the selection keywords and related circuit contexts.
Composition of routine
SS7
Signaling address
/
Cruptive information includes
MTP3
Routing mark
OPC
,
DPC
,
SiO
,or
MTP3-
User specific field, for example
ISUP
of
CIC
Wait.
•
SS7
Signaling
M3ua
Interoperability
SS7 signaling and M3UA interworking, the M3UA adaptation layer provides defined MTP3 user primitives extension.
•
Congestion management
ASP
or
IPSP
of
M3ua
use
Scon
News
M3ua
The peer layer indicates local congestion. when
SG
of
M3ua
received
ASP
of
Scon
When the news is
SG
determine
SPMC
Positive congestion, according to
MTP
specification
SG
Associated
SS7
Signaling destination
MTP3
Controlled management message.
•
SCTP
Flow map
SGP
with
ASP
of
M3ua
Support to assign signaling services to
SCTP
In the stream.
MTP3-
User service can be based
MTP
Routing mark
SLS
Distribution stream, the number of streams should be less than the low layer
SCTP
The maximum number of couples supported by coupling. Signaling services for sequential requirements must be assigned to the same stream.
• Client / Server Models SGP and ASP can support client and server operations, using M3UA peer endpoints should be equipped
Set to one end is the server, the other end is the client that starts SCTP coupling. Default SGP as a server, ASP is a client, and ASP should initiate SCTP coupling for SGP.
M3ua is transferred on SCTP, the SCTP user port number code registered for M3UA is 2905.
3. M3UA protocol structure
The architecture of the M3UA protocol is shown in Figure 2-9.
MTP3 - User M3UA LM SCTP IP
Figure 2-9 Architecture of the M3UA protocol
MTP3 - User's low-level protocol is M3ua, which provides a standard MTP3 interface to MTP3-users; M3UA's low-level protocol is SCTP, providing coupling of SCTP to M3UA service; M3ua also has special layer management (LM), for it Management service.
The business M3UA provided by M3UA provides the following business features:
• Support for transfer MTP3 - User Messages • Local Management Functions • Support with MTP3 Network Management Functions • Support SGP and ASP SCTP Countries • Support to multiple SGP coupling management
M3ua message format
The M3UA message format contains a public message header, followed by 0 or more parameters defined by the message type, considering forward compatibility, all message types have compatibility parameters.
Public message head
The structural requirements of the MTP3 user adaptation layer protocol message include version, message type, message length, and message content (shown in Figure 2-10). The message header is a common message for all signaling protocols.
0123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Figure 2-10 Public Message Head
• The M3ua Protocol Version Field includes a version of the M3UA adaptation layer. The supported version is:
Value: 00000001; Version: Release 1.0 protocol.
• Message Category and Message Types
Table 2-3 lists the message categories defined by M3ua, Table 2-4, Table 2-5, Table 2-6, Table 2-8, Table 2-8, and Table 2-9 lists the Messages defined by M3UA Types of. Table 2-3 M3UA message category
Message Category Message Category Code (Hex) Management (MGMT) Message 00 Transfer Message 01 SS7 Signal Network Management (SSNM) Message 02 ASP Status Maintenance (ASPSM) Message 03 ASP Service Maintenance (ASPTM) Message 04 is other SigTran Adapted layer spare 05 for other SigTRAN adaptation layer spare 06 for other SigTRAN adaptation layer standby 07 for other SigTRAN adaptation layer alternate 08 Route Keyword Management (RKM) Message 09 IETF Alternate 0A-7F for the message category defined for IETF Extended standby 80-FF
Table 2-4 M3UA Management (MGMT) Message Types
Message Type Message Code (Hex) Error (ERR) 00 Notification (NTFY) 01 IETF Alternate 02-7F for IETF defined MGMT extended backup 80-FF
Table 2-5 M3UA transfer message type
Message Type Message Code (Hex) Alternate 00 Data (DATA) 01 IETF Alternate 02-7F for IETF Defined Transfer Expansion 80-FF
Table 2-6 M3UA Signaling Network Management (SSNM) Message Type
Message type
Message type encoding (hexadecimal)
00
spare
Message Type Message Code (Hexadecimal) Destination Unavailable (DUNA) 01 Destination (DAVA) 02 Destination Status Queries (DAUD) 03 SS7 Signback Net Congestion (SCON) 04 Destination User Part Unavailable ( DUPU) 05 Destination (DRST) (Not used) 06 IETF Alternate 7-7F for IETF defined SSNM extension alternate 80-FF
Table 2-7 M3UA Status Maintenance (ASPSM) Message Types
Message Type Message Code (Hex) Alternate 00 ASP UP (ASPUP) 01 ASP DOWN (ASPDN) 02 HeartBeat (BEAT) 03 ASP UP (Aspup Ack) 04 ASP DOWN ACK (ASPDN ACK) 05 HeartBeat Ack (Beat ACK) 06 IETF Alternate 7-7F ASPSM extension alternate 80-FF defined for IETF
Table 2-8 M3UA Service Maintenance (ASPTM) Message Type Table 2-9 M3UA Route Keyword Management (RKM) Message Type
Message Type Message Code (Hex) Alternate 00 ASP Activation (ASPAC) 01 ASP Live (Aspia) 02 ASP ACK (Aspac ACK) 03 ASP Live ACK (Aspia Ack) 04 IETF Backup 5-7f is IETF Defined ASPTM extension alternate 80-FF
Message Type Message Code (Hex) Alternate 00 Registration Request (REG REQ) 02 Registration Request (Dereg REQ) 03 Dereg RSP 04 IETF Alternate 5-7f is the IETF definition RKM extension alternate 80-ff •
Message length
The message length defines the eight-bit group length of the message, and the length includes the message header. For the last parameter of the message, if the population is included, the message length should be included.
•
Variable length parameter format
M3ua consists of a public message head and a subsequent 0 or several variable length parameters. All formats containing parameters contained in the message are shown in Figure 2-11:
0123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Figure 2-11 Variable length parameter format
A number of parameters can be included in the message, and the parameters can be any order unless there is a clear requirement. The recipient should receive any order parameters.
• The parameter tag parameter tag is 16 bits, used to identify parameter types, which can be 0 to 65534. Adaptation layer
The public parameter is between 0x00 to 0x3f, and the specific parameters of M3UA are between 0x0200 to 0x02FF. The defined public parameter tag is shown in Table 2-10.
Table 2-10 Public parameter tag
Parameter Name Parameter Tag Coding (Sixteen) Alternate 0x0000 Not used in M3UA 0x0001 Not in M3UA 0x0002 Not in M3ua 0x0003 Information Strings 0x0005 No 0x0005 Cruise Conclusion 0x0006 Diagnostic Information 0x0007 Not in M3ua Using 0x0008 HeartBeat Data 0x0009 Not using 0x000A Service Mode Type 0x000B Different Code 0x000c Status 0x000D Not in M3UA 0x000E Did not use 0x000f in M3UA without using 0x0010 ASP identifier 0x0011 The 0x0010 ASP identifier 0x0011 is affected by signaling point encoding 0x0012 Correlation ID 0x0013
The specific parameters of M3UA are shown in Table 2-11. Table 2-11 Specific parameters of M3UA • Parameter length
Parameter Name Parameter Tag Coding (Sixteen Enter) Network Outside 0x0200 Alternate 0x0201 Alternate 0x0202 Alternate 0x0203 User / Cause 0x0204 Congestion Indication 0x0205
Parameter Name Parameter Tag Coding (Hex) Related Destinations 0x0206 Routing Keyword 0x0207 Registration Results 0x0208 Logout Results 0x0209 Local Call Keyword Identifier 0x020A Destination Signature Point Code 0x020B Service Note 0x020C Alternate 0x020D Source Letter Point code list 0x020e circuit range 0x020F protocol data 0x0210 alternate 0x0211 registration status 0x0212 Logout 0x0213 IETF standby 0x0214-0xfffff
The parameter length is 16 bits, including the number of bytes of parameters, including parameter tags, parameter lengths, and parameter value fields. The length of the parameter does not include any filling bytes.
The parameter value is a variable length, which contains information actually transmitted by parameters.
The total length of the parameters (including labels, parameter lengths, and value fields) must be an integer multiple of the four bytes. If the length of the parameter is not four, the sender fills the parameters at the end of the 0, and the length of the pad is not included in the parameter length field. The sender cannot fill more than three bytes, and the recipient ignores the filling byte.
2. Data (DATA) Message Data Messages include public message headers and 0 or more parameters defined by message type. The DATA message contains the SS7 signaling MTP3 user protocol data, which contains a complete MTP3 route standard.
Remember, the DATA message contains the following parameters: the external appearance of the network is optional (not used) Call context optional agreement data must
Correlation ID The parameter format of the DATA message is shown in Figure 2-12: 012
3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Figure 2-12 DATA message parameter format
(1) Network appearance is the parameters used in the message to supplement NI (network logo). In the Data message, the appearance of the network implies the SS7 signaling point encoding format, SS7 signaling network indicates the value, and the MTP3 / MTP3 user protocol type / variable / version. For example, the China Inland and Hong Kong Special Administrative Region belongs to the same NI (domestic main network), but its signaling point format is different. China's inland use 24-bit signaling point coding, Hong Kong area uses 14-bit signaling point encoding. This requires the network appearance parameters in the message to be defined. If the network appearance parameter exists because it defines the format of the protocol data field, it must be
The first parameter in the interest. The M3UA protocol specification does not use the online appearance parameters.
(2) Calling the context selection context is a 32bit value, and the selection keyword is selected one by one in the message.
(3) The protocol data protocol data parameter contains the source SS7 signaling MTP3 message, including business information eight bit groups and routing marks. Protocol data parameters include the following fields: • Service Indicator (Si) • Network Indicator (NI) • Delivery Signal Point Encoding (OPC) • Source Credit Point Encoding (DPC) • Signal Link Selection Code (SLS) User The protocol data includes: MTP3-user protocol unit (eg, ISUP, SCCP, or TUP parameters).
The format of the protocol data parameters is shown in Figure 2-13.
012
3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Empty opc empty DPC empty Si empty ni empty SLS
Wiring participation
Figure 2-13 Format of the protocol data
•
OPC
:
twenty four
Bits;
•
DPC
:
twenty four
Bits;
•
Ni
:
2
Bits;
•
Si
:
4
Bits;
•
SLS
:
4
Bit.
•
Correlation ID
:in
AS
The only recognition of the identification of the protocol data
MSU
.
3. SS7 Signaling Network Management (SSNM) Message
All messages (including SSNM messages) of the M3UA protocol include parameters defined by the message type.
(1) Destination Unavailable SGP in SGP in SG is sent to all related ASPs to indicate that SG has determined that one or more SS7 signaling destinations are not arrogant, it is also used for SGP response ASP messages Da S7 signaling destination. The ASP MTP3 users should stop sending services to the destination that is affected in the Duna message.
(2) Destination (DAVA) SGP Send DAVA messages to all related ASPs to indicate that SG has determined that one or more SS7 destinations are currently available, or respond to DAUD messages (see below). The ASP's MTP3-user protocol should restore the business of the destination that is affected in the Dava message.
(3) Destination Status Query (DAUD) ASP sends a DAUD message to the SGP to query the availability / congestion state of one or more SS7 signaling routes that are affected destination. (4) SS7 signaling network SCON SGP sends SCON messages to all related ASPs to indicate one or more destinations of SS7 signaling network, or send SCON messages to ASP to respond to DATA or DAUD Message; you can also send SCON messages to the M3UA peer layer from the ASP M3UA to M3UA or ASP congestion.
(5) Destination user part is not available (DUPU)
SGP sends a DUPU message to the ASP to notify the SS7 distal peer on the Signal Network node is unavailable. Application Server Process Management (ASPM) message
(6) ASP UP (ASPUP) message
ASP UP (ASPUP) message is used to indicate that the adapter layer is ready to receive SSNM or ASPM management messages for all routing keywords that are ready for ASP configuration.
(7) ASP UP ACK (ASPUP ACK) message
The ASP UP (ASPUP ACK) message is used to confirm the ASP UP message received from the remote M3UA peer.
(8) ASP DOWN (ASPDN) message
ASP DOWN (ASPDN) message is used to indicate that the adapter layer is not prepared to receive Data, SSNM, RKM or ASPTM messages.
(9) ASP DOWN ACK (ASPDN ACK) message
The ASP Down ACK message is used to confirm the ASP Down message received from the remote M3ua peer layer, or ASPM messages received from the ASP that are locked from the management reason.
(10) HeartBeat (beat) message beat message is optional to ensure M3ua peer-to-horizontal layer is available for other M3ua, when M3UA
BEAT messages must be used without using SCTP as a transfer layer. No parameters are not included in the BEAT message.
(11) HeartBeat Ack (Beat Ack) message
Send a beat Ack message to respond to the received BEAT message, which contains all the parameters of the received BEAT message.
4. M3UA Route Keyword Management (RKM) Message
(1) Registration Request (REG REQ) ASP Send Registration Request Message Used to point to the distal M3UA peer to point out it hopes to be a given selection keyword with the remote peer-to-the-alias. The most typical case is that the ASP sends this message to the SGP and wants to receive the REG RSP with the correlation circuit.
(2) Registration Response (RSP) REG RSP message is used to respond to the response from the remote M3UA peer REG REG REG message, which contains a successful indication of the registration request, and returns the unique circuit of successful registration request. For subsequent M3UA business management protocols.
(3) DEREG REQ ASP Send Dereg Req Message to the distal M3UA peer to indicate that the given selection keyword, usually the ASP will send this message to the SGP and want to receive the associated circuit context Return the value of the Dereg RSP message.
(4) DEREG RSP DEREG RSP Message is used to respond to Dereg Req messages from the remote M3ua peer.
5. Application Business Maintenance (ASPTM) message
(1) ASP activation (ASPAC)
The ASP sends an ASPAC message to indicate that the remote M3UA peer is ready to process signaling services for a particular application server. The ASPAC only affects the ASP status of the selection keywords identified by the circuit. (2) ASP ACK ASPAC ACK message is used to confirm the ASPAC message received from the remote M3UA peer. (3) ASP to live (ASPIA)
ASP sends an ASPIA message to the remote M3UA peer layer indicates an ASP that is no longer used in the ASP. The ASPIA message only affects the status of the ASP in the routing keywords identified by the selection context.
(4) ASP Deactivated ACK ASPIA ACK Message is used to confirm the ASP to the ASP to the ASP to the remote M3UA peers.
6. Manage messages
(1) Error (ERR)
If the value of the error event is found in the received message, the ERR message is sent. If you receive a non-desired value in the current state, or the parameter value is invalid. ERR messages must include error code parameters.
The error code parameter is used to indicate the cause of the ERR message, and the error parameter value uses the value specified in Table 2-12.
Table 2-12 Valid value of error parameters
Value Description 0x01 Invalid Version 0x02 M3UA Do not use 0x03 unsupported message category
Value Description 0x04 Unsupported Message Type 0x05 Unsupported Service Processing Mode 0x06 Non - desired Message 09 Protocol error 0x08 M3UA Do not use 0x09 invalid stream identifier 0x0A m3ua Not used in 0x0B m3ua Not used in 0x0C m3ua 0x0D Reject - Manage Block 0x0E Requires ASP Identifier 0x0F Invalid ASP Identifier 0x10 M3UA Does Not Using 0x11 Invalid Parameter Value 0x12 Parameter Difference 0x13 Non-desired Parameters 0x14 Purpose Status Unknown 0x15 Invalid Network Outside 0x16 Loss Parameters 0x17 M3UA Do not use 0x18 m3ua not using 0x19 invalid selection context 0x1a does not configure the ASP configuration
If you receive an invalid or unsupported message, send "invalid version" error, the ERR message contains supported version in the public head, and the ERR message can optionally be supported by the diagnostic information area.
If you receive a non-desired or unsupported message category, you send a "unsupported message category" error.
If you receive a non-desired or unsupported message type, you will send an "unsupported message type" error.
If the ASP sends an ASP activation message that does not support traffic mode type or sending the traffic volume processing mode type incompatible with the application server now, SGP sends "not supported / invalid traffic processing mode", for example SGP does not support load balancing.
If a non-desired defined and recognizable message is received in the current state, "non-desired messages" can be sent (ASP can also discard this message without sending an Err message).
For the correct but non-desired parameters that receive any syntax, the protocol error occurs.
If a message is received on a non-desired SCTP stream (for example, in a non-"0" stream, the "invalid stream identifier" error is sent.
When the ASP-UP or ASP activation message is received and the reject the request (for example, managing the lock) is rejected (for example, managing the blocking), it will send "Reject-managed occlusion" error. If this error is in response to the ASP activation message, the selection context in the ERR message should include the ASP activation message.
If the SGP receives an ASP UP message that does not include an ASP identifier parameter, the SGP requests the "Requirements ASP Identifier" when the ASP UP is required.
If the SGP receives an ASP UP message of an invalid (ie uniquely) ASP identifier, the "invalid ASP identifier" is transmitted when responding to the ASP UP.
If you receive messages of invalid parameter values (received messages that are not "0", you will send an "invalid parameter value" error.
If the parameter in the received message is incorrect, the "parameter field error" is sent. If the message contains invalid parameters, "non-desired parameters" error is sent.
If the SG receives the availability / congestion status of the DAUD message query destination, the SG does not want to provide these states (eg, the sender does not know these states), the "destination state unknown" error is sent.
If the message does not contain the necessary parameters, the "Lost Parameter" error is sent.
If you receive an invalid (no configuration) from the peer layer, the "invalid selection context" error is sent. For such errors, there must be an invalid selection context in the ERR message.
If you receive a message that does not check the context of the context from the peer layer and does not know which application server is referred to by the configuration data, it is sent to send "not an ASP configuration as" error.
(2) Notification (NTFY) NTFY message is used to provide autonomous instructions for M3UA events to the M3UA peer.
2.4.4 M3UA message flow
The following example indicates the M3ua message stream established between the SGP and ASP services, all of which have established SCTP coupling.
1. Establish a coupling and business example between SGP and ASP
(1) There is an ASP in AS
This example gives the flow of M3ua messages in the establishment of SGP and ASP, only one ASP in AS (no backup).
• A single ASP is in an AS / (1 0 backup) without registration, and the M3UA message call example is shown in Figure 2-14.
RC: Selection Selection (optional)
Figure 2-14 Flow Example 1 for establishing a M3UA message 1
• Single ASP in an AS (1 0 backup), dynamic registration
This example is the same as the previous one, but the exchange of registration information is added, and the SGP accepts registration. Under this condition, the M3UA message call example is shown in Figure 2-15.
SGP ASP1 ASP UP
ASP UP ACKLRC: Edition: Select Selection REQ (LRCN, RKN) RK: Selection ::: RC: Select Selection REG RSP (LRCN, RKN)
ASP stilition (RCN)
Figure 2-15 Flow Example 2 for establishing a M3UA message 2
• Single ASP is shown in multiple AS (1 0 backup), and the M3ua message call example is shown in Figure 2-16.
ASP1
SGP
LRC: Edition: Selection Selection RK: Selection ::: RC: Selection Selection
Figure 2-16 Flow Example 3 for establishing a M3UA message 3
2. ASP business troubleshooting example
(1) Two ASP master, an ASP fault Refer to Figure 2-17, the situation of ASP1 exits service is shown in Figure 2-17.
SGP ASP2
Figure 2-17 ASP Business Fault Example 1
Note: If SGP detects M3ua peer loss (M3ua HeartBeat missing or detects SCTP failure), the initial ASP to go messaging (eg, ASP1, and SGP) will not occur.
(2) Two ASP hosts
The following examples are also shown in Figure 2-18, which are active requests initiated by ASP2 and are responsible for all services. This example is shown in Figure 2-18.
SG ASP1 ASP2 ASP Stunning ASP Stunner ACK Pass (((ASP Progressive "
Figure 2-18 ASP Business Fault Example 2
3. Exit ASP normally from AS and clear the coupling example
If the ASP is to exit the business, the ASP in the "ASP-INACTIVE" state (ie, the ASP to deactivate ACK message has been received) can enter the "ASP-DOWN" state. This example is shown in Figure 2-19. ASP1
SGP ASP Defense (RCN) ASP Delays ACK (RCN)
RC: Select selected selection
Deregreq (RCN)
DEREG RSP (LRCN, RCN)
ASP Down
Figures 2-19 exiting the ASP normally from the AS and clears the coupling example
