RFC 3332
Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
RFC 3332: Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) 🎀
okay bestie, this is RFC 3332 🦋 It's a Standards Track doc from the Network Working Group, published in September 2002. The editors are G. Sidebottom (Signatus Technologies), K. Morneault (Cisco), and J. Pastor-Balbas (Ericsson). It doesn't list any RFCs it obsoletes or updates, so it's standing on its own 💅
Status of This Memo ✨
so this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 for the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 📚 and yes, distribution is unlimited, so share it with everyone 💜
Copyright Notice 🌸
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract 🔥
okay so this memo is all about carrying any SS7 MTP3-User signalling (think ISUP and SCCP messages) over IP, using the Stream Control Transmission Protocol 🚀 it also adds protocol elements so the MTP3-User peers can work together seamlessly across the SS7 and IP worlds ✨ the protocol is used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or an IP-resident Database, or between two IP-based applications 💖 and it's assumed that the SG gets its SS7 signalling over a standard SS7 interface, using the SS7 Message Transfer Part (MTP) for transport 🎀
Table of Contents 📋
1. Introduction..................................................3
1.1 Scope.........................................................3
1.2 Terminology...................................................4
1.3 M3UA Overview.................................................6
1.4 Functional Areas.............................................10
1.5 Sample Configurations........................................18
1.6 Definition of M3UA Boundaries................................21
2. Conventions..................................................25
3. M3UA Protocol Elements.......................................25
3.1 Common Message Header........................................26
3.2 Variable Length Parameter....................................29
3.3 Transfer Messages............................................31
3.4 SS7 Signalling Network Management (SSNM) Messages............35
3.5 ASP State Maintenance (ASPSM) Messages.......................45
3.6 Routing Key Management (RKM) Messages........................48
3.7 ASP Traffic Maintenance (ASPTM) Messages.....................59
3.8 Management (MGMT) Messages...................................63
4. Procedures...................................................69
4.1 Procedures to Support the M3UA-User .........................69
4.2 Procedures to Support the Management of SCTP Associations ...70
4.3 AS and ASP State Maintenance.................................72
4.4 Routing Key Management Procedures............................87
4.5 Procedures to Support the Availability or Congestion Status
of SS7 Destination...........................................89
4.6 MTP3 Restart.................................................92
5. Examples of M3UA Procedures..................................93
5.1 Establishment of Association and Traffic
Between SGs and ASPs.........................................93
5.2 ASP traffic Failover Examples................................99
5.3 Normal Withdrawal of an ASP from an Application Server
and Teardown of an Association..............................100
5.4 M3UA/MTP3-User Boundary Examples............................101
5.5 Examples of IPSP communication..............................105
6. Security Considerations.....................................108
6.1 Introduction................................................108
6.2 Threats.....................................................108
6.3 Protecting Confidentiality..................................108
7. IANA Considerations.........................................109
7.1 SCTP Payload Protocol Identifier............................109
7.2 M3UA Port Number............................................109
7.3 M3UA Protocol Extensions....................................109
8. References...................................................111
8.1 Normative References........................................111
8.2 Informative References......................................111
9. Acknowledgements.............................................113
10. Document Contributors.......................................113
Appendix A......................................................114
A.1 Signalling Network Architecture.............................114
A.2 Redundancy Models...........................................117
Editors' Addresses..............................................119
Full Copyright Statement........................................1201. Introduction ✨
okay so the big picture: this memo is the protocol for moving any SS7 MTP3-User signalling (ISUP and SCCP, for example) over IP, using the Stream Control Transmission Protocol [17] 🚀 it also has protocol elements so MTP3-User peers keep working smoothly across both the SS7 and IP domains 💅 this protocol runs between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database [11], or between two IP-based applications 🫶
1.1 Scope 🎀
so here's the deal: there's a need to deliver Switched Circuit Network (SCN) signalling from an SS7 Signalling Gateway (SG) to a Media Gateway Controller (MGC) or IP-resident Database, like the Framework Architecture for Signalling Transport [11] describes 🦋 the delivery mechanism should hit these criteria:
- Support for the transfer of all SS7 MTP3-User Part messages (e.g., ISUP [1,2,3], SCCP [4,5,6], TUP [12], etc.) 💖
- Support for the seamless operation of MTP3-User protocol peers 🌈
- Support for the management of SCTP transport associations and traffic between an SG and one or more MGCs or IP-resident Databases 🧚
- Support for MGC or IP-resident Database process failover and load sharing 👑
- Support for the asynchronous reporting of status changes to management 🔥
in simple transport terms, the SG terminates the SS7 MTP2 and MTP3 protocol layers [7,8,9] 🍓 then it delivers ISUP, SCCP and/or any other MTP3-User protocol messages, plus certain MTP network management events, over SCTP transport associations to MTP3-User peers in MGCs or IP-resident Databases ✨
1.2 Terminology 📖✨
Okay bestie, let's get the vocab down first, because this section is literally the foundation for everything else 🧚💅
Application Server (AS): a logical entity serving one specific Routing Key 🎀 For example, a virtual switch element handling all call processing for a unique range of PSTN trunks, identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a virtual database element handling all HLR transactions for one particular SS7 DPC/OPC/SCCP_SSN combination. The AS holds a set of one or more unique Application Server Processes, and usually one or more of them is actively processing traffic. Also, there's a 1:1 relationship between an AS and a Routing Key, so they're basically a matching pair 🫶
Application Server Process (ASP): a process instance of an Application Server 💖 An ASP acts as either an active or a backup process for an AS, like part of a distributed virtual switch or database. Examples are processes (or process instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP endpoint, and it can be set up to process signalling traffic for more than one Application Server 🦋
Association: this refers to an SCTP association 🌸 It's the transport that carries MTP3-User protocol data units and M3UA adaptation layer peer messages.
IP Server Process (IPSP): a process instance of an IP-based application 🧚 An IPSP is basically the same as an ASP, except it uses M3UA in a point-to-point way. Conceptually, an IPSP does not use the services of a Signalling Gateway node, so no middleman needed 💅
Failover: the ability to reroute signalling traffic, as required, to an alternate Application Server Process, or group of ASPs, within an Application Server when the process currently in use fails or becomes unavailable 🔥 Failover also kicks in when a previously unavailable Application Server Process comes back into service. Comeback arc, iconic 👑
Host: the computing platform that the process (SGP, ASP or IPSP) is running on 💜
Layer Management: a nodal function that handles the inputs and outputs between the M3UA layer and a local management entity 🌈
Linkset: a number of signalling links that directly interconnect two signalling points, used together as a module 🍓
MTP: the Message Transfer Part of the SS7 protocol ⭐
MTP3: MTP Level 3, the signalling network layer of SS7 🦋
MTP3-User: any protocol that normally uses the services of the SS7 MTP3, like ISUP, SCCP, TUP, etc. 💖
Network Appearance: this is an M3UA local reference that's shared by the SG and the AS (usually an integer). Together with a Signaling Point Code, it uniquely identifies an SS7 node by showing which specific SS7 network it belongs to 🔥 It can tell apart signalling traffic for different networks that's being sent between the SG and the ASP over a shared SCTP association. The example scenario is an SG that shows up as an element in multiple separate national SS7 networks, where the same Signaling Point Code value might get reused across networks. Very dramatic, very real 💀
Network Byte Order: most significant byte first, a.k.a. Big Endian 🎀
Routing Key: a Routing Key describes a set of SS7 parameters and parameter values that uniquely define the range of signalling traffic a particular Application Server handles 👑 Parameters inside the Routing Key cannot extend across more than a single Signalling Point Management Cluster. Boundaries, babe 🫶
Routing Context: a value that uniquely identifies a Routing Key 🌸 Routing Context values are either configured through a configuration management interface, or set up using the routing key management procedures defined in this document.
Signalling Gateway Process (SGP): a process instance of a Signalling Gateway 💅 It can act as an active, backup, load-sharing or broadcast process of a Signalling Gateway.
Signalling Gateway: an SG is a signaling agent that receives and sends SCN native signaling at the edge of the IP network [11] ✨ To the SS7 network, an SG looks like an SS7 Signalling Point. An SG contains a set of one or more unique Signalling Gateway Processes, and usually one or more of them is actively processing traffic. When an SG has more than one SGP, the SG is treated as a single logical entity, and the SGPs are assumed to be coordinated into one management view for the SS7 network and for the supported Application Servers. Teamwork makes the dream work 🧚
Signalling Process: a process instance that uses M3UA to talk to other signalling processes 🦋 An ASP, an SGP and an IPSP are all signalling processes.
Signalling Point Management Cluster (SPMC): the complete set of Application Servers shown to the SS7 network under a single MTP entity (Signalling Point) in one specific Network Appearance 💖 SPMCs aggregate the availability, congestion, and user part status of an MTP entity (Signalling Point) that's spread out across the IP domain, so MTP3 management procedures can be supported toward the SS7 network 🌈 Sometimes the SG itself is also a member of the SPMC. In that case, the SG availability, congestion and User_Part status should also be taken into account when considering any supporting MTP3 management actions. Lots of moving parts, lowkey iconic 🔥
Stream: a stream refers to an SCTP stream, which is a unidirectional logical channel set up from one SCTP endpoint to another associated SCTP endpoint 🍓 Within it, all user messages are delivered in-sequence, except for those submitted to the unordered delivery service ✨
1.3 M3UA Overview 🦋
1.3.1 Protocol Architecture 🎀
The framework architecture defined for SCN signalling transport over IP [11] uses multiple components. These include a common signalling transport protocol, and an adaptation module that supports the services a particular SCN signalling protocol expects from its underlying protocol layer 🧚
Inside that framework, this document defines an MTP3-User adaptation module that's suitable for supporting the transfer of messages of any protocol layer identified to the MTP Level 3 as an MTP User 💖 The protocol layers on that list include, but aren't limited to, ISDN User Part (ISUP) [1,2,3], Signalling Connection Control Part (SCCP) [4,5,6] and Telephone User Part (TUP) [12]. TCAP [13,14,15] or RANAP [16] messages get transferred transparently by the M3UA protocol as SCCP payload, since they're SCCP-User protocols 🌸
It is recommended that M3UA use the services of the Stream Control Transmission Protocol (SCTP) [17] as the underlying reliable common signalling transport protocol 🫶 This is so M3UA can take advantage of SCTP features like:
- Explicit packet-oriented delivery (not stream-oriented),
- Sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,
- Optional multiplexing of user messages into SCTP datagrams,
- Network-level fault tolerance through support of multi-homing at either or both ends of an association,
- Resistance to flooding and masquerade attacks, and
- Data segmentation to conform to discovered path MTU size.
In certain scenarios, like back-to-back connections without redundancy requirements, the SCTP functions above might not be needed, and TCP MAY be used as the underlying common transport protocol 💅
1.3.2 Services Provided by the M3UA Layer ✨
The M3UA Layer at an ASP or IPSP gives its upper layer the same set of primitives that the MTP Level 3 gives its local MTP3-Users at an SS7 SEP 👑 So the ISUP and/or SCCP layer at an ASP or IPSP has no idea that the MTP3 services are actually being offered remotely from an MTP3 Layer at an SGP, not from a local MTP3 layer. The MTP3 layer at an SGP might not know its local users are really remote user parts over M3UA either. Basically, M3UA extends access to the MTP3 layer services to a remote IP-based application 🧚 The M3UA layer does not provide the MTP3 services itself. However, when an ASP is connected to more than one SG, the M3UA layer at that ASP should maintain the status of configured SS7 destinations and route messages according to the availability and congestion status of the routes to those destinations via each SG 🦋
The M3UA layer may also be used for point-to-point signalling between two IP Server Processes (IPSPs) 🌈 In this case, the M3UA layer provides the same set of primitives and services at its upper layer as the MTP3. But here the expected MTP3 services are not offered remotely from an SGP. The MTP3 services are still provided, but the procedures supporting them are a subset of the MTP3 procedures, since the IPSP to IPSP relationship is simple and point-to-point 💖
1.3.2.1 Support for the Transport of MTP3-User Messages 🎀
The M3UA layer provides the transport of MTP-TRANSFER primitives across an established SCTP association, either between an SGP and an ASP or between IPSPs 🌸
At an ASP, when a destination is reachable via multiple SGPs, the M3UA layer must also choose which SGP the message is routed through, or support load balancing across the SGPs while minimizing missequencing 🔥
The M3UA layer does not impose the 272-octet signalling information field (SIF) length limit specified by the SS7 MTP Level 2 protocol [7,8,9] 💅 Larger information blocks can be carried directly by M3UA/SCTP, without the upper layer segmentation/re-assembly procedure specified in recent SCCP or ISUP versions. However, in the context of an SG, the maximum 272-octet block size must be followed when interworking with an SS7 network that doesn't support transferring larger information blocks to the final destination 🙈 This avoids potential ISUP or SCCP fragmentation requirements at the SGPs. The provisioning and configuration of the SS7 network determines the restriction on the maximum block size. Some configurations (e.g., Broadband MTP [21]) may permit larger block sizes 🌈
1.3.2.2 Native Management Functions ⭐
The M3UA layer can indicate errors associated with received M3UA messages, and notify local management and/or the peer M3UA as appropriate 🧚
1.3.2.3 Interworking with MTP3 Network Management Functions 👑
At the SGP, the M3UA layer interworks with MTP3 management functions so the user SCN signalling applications keep running smoothly across both the SS7 and IP domains. This includes:
- Providing an indication to MTP3-Users at an ASP that a destination in the SS7 network is not reachable.
- Providing an indication to MTP3-Users at an ASP that a destination in the SS7 network is now reachable.
- Providing an indication to MTP3-Users at an ASP that messages to a destination in the SS7 network are experiencing SS7 congestion.
- Providing an indication to the M3UA layer at an ASP that the routes to a destination in the SS7 network are restricted.
- Providing an indication to MTP3-Users at an ASP that a MTP3-User peer is unavailable.
The M3UA layer at an ASP keeps track of the state of routes to remote SS7 destinations, and may start an audit of the availability, restricted or congested state of those remote SS7 destinations 💖 That information is requested from the M3UA layer at the SGP 🫶
The M3UA layer at an ASP may also tell the SG that the M3UA layer itself, the ASP, or the ASP's Host is congested 😭
1.3.2.4 Support for the Management of SCTP Associations between the SGP and ASPs. 💅
okay so the M3UA layer at the SGP keeps track of whether every configured remote ASP is available 🫶. It manages the SCTP Associations and the traffic between the M3UA peers using that info. It also tracks whether each remote ASP is active or inactive, plus its congestion state. main character energy for sure 🎀
The M3UA layer MAY be told by local management to set up an SCTP association with a peer M3UA node ✨. It can do this with the M-SCTP_ESTABLISH primitives (see Section 1.6.3 for the management primitives). Those cover requesting, indicating and confirming that an SCTP association with a peer M3UA node has been established 💖. To avoid doubled-up SCTP associations between two M3UA peers, one side (the client) SHOULD be designated as the one that sets it up. Or the M3UA configuration info can be kept so redundant associations get spotted, like by knowing the expected local and remote SCTP endpoint addresses 🧚.
Local management MAY ask the M3UA layer for the status of the underlying SCTP associations, using the M-SCTP_STATUS request and confirm primitives 🌸. Also, the M3UA MAY autonomously tell local management why an SCTP association was released. That reason might be decided locally inside M3UA, or come in as a primitive from SCTP 👑.
Also, the M3UA layer MAY let local management know when an ASP or AS changes status 🦋. That MAY be done with the M-ASP_STATUS request or M-AS_STATUS request primitives 💅.
1.3.2.5 Support for the Management of Connections to Multiple SGPs
as Figure 1 shows, an ASP can be hooked up to multiple SGPs 🌈. So a particular SS7 destination might be reachable through more than one SGP and/or SG, meaning more than one route 🛣️. MTP3 users only track status per destination, not per route. That means the M3UA layer must keep track of each route's status (availability, restriction and/or congestion), work out the overall availability or congestion of the destination from those route statuses, and tell the MTP3 users about that derived status whenever it changes 🔥.
1.4 Functional Areas ✨
1.4.1 Signalling Point Code Representation
picture this: inside an SS7 network, a Signalling Gateway (SG) might be in charge of representing a bunch of IP-domain nodes to the SS7 network, for routing purposes 🧚. The SG is also a signalling point in its own right, so it could have its own SS7 Point Code for MTP3 Management 🎀. That same SG Point Code might also be used to reach local MTP3-Users at the SG, like a local SCCP layer 💜.
An SG may be logically split up to run in multiple SS7 network appearances. In that case, the SG could have a Point Code in each network appearance, representing a set of IP-domain nodes into each SS7 network 🦋. Alias Point Codes [8] may also be used within an SG network appearance 💅.
Where an SG has more than one SGP, the MTP3 routeset, SPMC and remote AS/ASP states of each SGP SHOULD be coordinated across all the SGPs 🫶. Rerouting of traffic between the SGPs MAY also be supported 🔥.
Application Servers can sit under the same Point Code as the SG, get their own individual Point Codes, or be grouped with other Application Servers for Point Code preservation purposes 🌸. A single Point Code may be used to represent the SG and all the Application Servers together, if desired ✨.
If an ASP or group of ASPs is available to the SS7 network through more than one SG, each with its own Point Code, the ASP(s) will typically get a Point Code that's separate from any SG Point Code 🌈. This lets those SGs look like "STPs" to the SS7 network, each with an ongoing "route" to the same ASP(s). If the ASP(s) become unavailable from one of the SGs, this setup lets MTP3 route management messaging run between the SG and the SS7 network. That means simple SS7 rerouting through an alternate SG, without changing the Destination Point Code Address of SS7 traffic to the ASP(s) 💖.
Where a particular AS can be reached through more than one SGP, the corresponding Routing Keys in the SGPs should be identical. (Note: the SGP Routing Key configuration data can be temporarily out-of-sync during configuration updates 🙈.)
+--------+
| |
+------------+ SG 1 +--------------+
+-------+ | SS7 links | "STP" | IP network | ----
| SEP +---+ +--------+ +---/ \
| or | |* | ASPs |
| STP +---+ +--------+ +---\ /
+-------+ | | | | ----
+------------+ SG 2 +--------------+
| "STP" |
+--------+
Figure 1 Example with mated SGs- Note: SG-to-SG communication (i.e., "C-links") is recommended for carrier grade networks, using an MTP3 linkset or an equivalent. That lets traffic reroute between the SGs if route failures happen 🔥. Where SGPs are used, inter-SGP communication might be used too. The inter-SGP protocol is outside the scope of this document 🙃.
The following example shows a signalling gateway split into two network appearances 🦋.
SG
+-------+ +---------------+
| SEP +--------------| SS7 Ntwk |M3UA| ----
+-------+ SS7 links | "A" | | / \
|__________| +-----------+ ASPs |
| | | \ /
+-------+ | SS7 Ntwk | | ----
| SEP +--------------+ "B" | |
+-------+ +---------------+
Figure 2 Example with multiple Network1.4.2 Routing Contexts and Routing Keys
1.4.2.1 Overview
okay so which SS7 messages go between the SGP and the Application Servers is decided by the Routing Keys and their linked Routing Contexts 🗝️. A Routing Key is basically a set of SS7 parameters used to filter SS7 messages. The Routing Context parameter is a 4-byte value (an integer) tied to that Routing Key in a 1:1 relationship 💜. So the Routing Context can be thought of as an index into a sending node's Message Distribution Table, which holds the Routing Key entries 🧚.
Possible SS7 address/routing info that makes up a Routing Key entry includes, for example, the OPC, DPC and SIO from the MTP3 routing label, or MTP3-User specific fields like the ISUP CIC or SCCP subsystem number 🎀. Some example Routing Keys are: the DPC alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the DPC/SSN combination 🌸. Which info defines an M3UA Routing Key depends on the application and network, and none of these examples is actually mandated 💅.
An Application Server Process may be configured to process signalling traffic for more than one Application Server, over a single SCTP Association ✨. In ASP Active and ASP Inactive management messages, the signalling traffic to start or stop is told apart by the Routing Context parameter 🦋. At an ASP, the Routing Context parameter uniquely identifies the range of signalling traffic tied to each Application Server that the ASP is set up to receive 💖.
1.4.2.2 Routing Key Limitations
Routing Keys SHOULD be unique, in the sense that each received SS7 signalling message SHOULD have a full or partial match to a single routing result 🫶. The parameter range values inside a Routing Key don't have to be contiguous 🌈. For example, an AS could be set up to handle call processing for multiple ranges of PSTN trunks that don't have contiguous CIC values 📞.
1.4.2.3 Managing Routing Contexts and Routing Keys
There are two ways to provision a Routing Key at an SGP 🎀. A Routing Key may be configured statically using an implementation dependent management interface. Or it can be set up dynamically using the M3UA Routing Key registration procedure 👑.
When a management interface is used to configure Routing Keys, the message distribution function in the SGP isn't limited to the parameters defined in this document 🙈. Other implementation dependent distribution algorithms may be used 🔥.
1.4.2.4 Message Distribution at the SGP
To send messages received from the SS7 MTP3 network to the right IP destination, the SGP must run a message distribution function using info from the received MTP3-User message 🧚.
To make that happen, the SGP might, for example, keep something like a network address translation table. It maps incoming SS7 message info to an Application Server for a particular application and range of traffic 🌸. This could be done by comparing parts of the incoming SS7 message to the Routing Keys currently defined in the SGP 💜.
Those Routing Keys could map straight to an Application Server that's enabled by one or more ASPs 🦋. Those ASPs send the SGP dynamic status info about their availability, traffic handling capability and congestion, using the management messages defined in the M3UA protocol 💅.
The list of ASPs in an AS is assumed to be dynamic. It takes into account the availability, traffic handling capability and congestion status of each ASP on the list, plus configuration changes and possible failover mechanisms ✨.
Normally, one or more ASPs are active (i.e., currently processing traffic) in the AS. But in certain failure and transition cases, there may be no active ASP available 😭. Broadcast, loadsharing and backup scenarios are all supported 🫶.
When there's no matching Routing Key entry for an incoming SS7 message, a default treatment MAY be specified 🌈. The possible solutions are to set up a default Application Server at the SGP that sends all unallocated traffic to a (set of) default ASP(s). Or the message can be dropped with a notification sent to layer management 💖. How unallocated traffic gets treated is implementation dependent 🔥.
1.4.2.5 Message Distribution at the ASP
The ASP must choose an SGP to send a message to the SS7 network 🦋. It does this by looking at the Destination Point Code (and maybe other parts of the outgoing message, like the SLS value) 🧚. The ASP must also check whether the related Routing Context is active or not (see Section 4.3.4.3) 💅.
Implementation Note: when more than one route (or SGP) is possible for routing to the SS7 network, the ASP could, for example, keep a dynamic table of the available SGP routes for the SS7 destinations 🌸. That table can account for the SS7 destination availability/restricted/congestion status received from the SGP(s), the availability status of each SGP, configuration changes and failover mechanisms 🎀. There is, however, no M3UA messaging to manage the status of an SGP (e.g., SGP-Up/Down/Active/Inactive messaging) 🙈.
Whenever an SCTP association to an SGP exists, the SGP is assumed to be ready to respond to M3UA ASPSM messages (refer to Section 3) 🫶.
1.4.3 SS7 and M3UA Interworking
in the case of SS7 and M3UA interworking, the M3UA adaptation layer is designed to extend the MTP3 defined user primitives 🌈✨.
1.4.3.1 Signalling Gateway SS7 Layers
okay so the SG is the one responsible for terminating MTP Level 3 of the SS7 protocol 💅 and then it offers an IP-based extension to its users 🌸
from the SS7 side, the Signalling Gateway is expected to transmit and receive SS7 Message Signalling Units (MSUs) to and from the PSTN over a standard SS7 network interface 📞. it uses the SS7 Message Transfer Part (MTP) [7,8,9] to give those messages reliable transport 🔥
a standard SS7 network interface doesn't have to mean MTP Level 2 signalling links, tho 🦋 ATM-based High Speed Links work too, using the services of the Signalling ATM Adaptation Layer (SAAL) [18,19] ✨
Note: it's also possible for IP-based interfaces to be present, using the services of the MTP2-User Adaptation Layer (M2UA) [27] or M2PA [28] 🫶
these could be terminated at a Signalling Transfer Point (STP) or Signalling End Point (SEP) 🧚 and using the services of MTP3, the SG could be capable of communicating with remote SS7 SEPs in a quasi-associated fashion, where STPs may be present in the SS7 path between the SEP and the SG 💜
1.4.3.2 SS7 and M3UA Interworking at the SG
the SGP provides a functional interworking of transport functions between the SS7 network and the IP network by also supporting the M3UA adaptation layer 🔥 it lets MTP3-User signalling messages move to and from an IP-based Application Server Process where the peer MTP3-User protocol layer exists 🦋
for SS7 user part management, it is required that the MTP3-User protocols at ASPs receive indications of SS7 signalling point availability, SS7 network congestion, and remote User Part unavailability, as would be expected in an SS7 SEP node 👑 to make that happen, the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives received at the MTP3 upper layer interface at the SG need to be propagated to the remote MTP3-User lower layer interface at the ASP 💖
MTP3 management messages (such as TFPs or TFAs received from the SS7 network) MUST NOT be encapsulated as Data message Payload Data and sent either from SG to ASP or from ASP to SG. The SG MUST terminate these messages and generate M3UA messages as appropriate. 💀
1.4.3.3 Application Server
a cluster of application servers is responsible for providing the overall support for one or more SS7 upper layers 🌈 from an SS7 standpoint, a Signalling Point Management Cluster (SPMC) provides complete support for the upper layer service for a given point code 👑 as an example, an SPMC providing MGC capabilities could provide complete support for ISUP (and any other MTP3 user located at the point code of the SPMC) for a given point code 🎀
in the case where an ASP is connected to more than one SGP, the M3UA layer must maintain the status of configured SS7 destinations and route messages according to the availability/congestion/restricted status of the routes to these SS7 destinations 🧠
1.4.3.4 IPSP Considerations
since IPSPs use M3UA in a point-to-point fashion, there is no concept of routing of messages beyond the remote end 🙈 therefore, SS7 and M3UA interworking is not necessary for this model ✨
1.4.4 Redundancy Models
1.4.4.1 Application Server Redundancy
all MTP3-User messages (e.g., ISUP, SCCP) which match a provisioned Routing Key at an SGP get mapped to an Application Server 🍓
the Application Server is the set of all ASPs associated with a specific Routing Key 🫶 each ASP in this set may be active, inactive or unavailable. active ASPs handle traffic, and inactive ASPs might be used when active ASPs become unavailable 🦋
the failover model supports an "n+k" redundancy model, where "n" ASPs is the minimum number of redundant ASPs required to handle traffic and "k" ASPs are available to take over for a failed or unavailable ASP 🔥 a "1+1" active/backup redundancy is a subset of this model 💅 and a simplex "1+0" model is also supported as a subset, with no ASP redundancy 🌸
1.4.5 Flow Control
local Management at an ASP may wish to stop traffic across an SCTP association to temporarily remove the association from service, or to perform testing and maintenance activity 🛠️ the function could optionally be used to control the start of traffic onto a newly available SCTP association 🌈
1.4.6 Congestion Management
the M3UA layer is informed of local and IP network congestion by means of an implementation-dependent function (e.g., an implementation dependent indication from the SCTP of IP network congestion) 🧚
at an ASP or IPSP, the M3UA layer indicates congestion to local MTP3-Users by means of an MTP-STATUS primitive, as per current MTP3 procedures, to invoke appropriate upper layer responses 💜
when an SG determines that the transport of SS7 messages to a Signalling Point Management Cluster (SPMC) is encountering congestion, the SG MAY trigger SS7 MTP3 Transfer Controlled management messages to originating SS7 nodes, per the congestion procedures of the relevant MTP3 standard 😭 the triggering of SS7 MTP3 Management messages from an SG is an implementation-dependent function 🎀
the M3UA layer at an ASP or IPSP MAY indicate local congestion to an M3UA peer with an SCON message 💅 when an SG receives a congestion message (SCON) from an ASP, and the SG determines that an SPMC is now encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled management messages to concerned SS7 destinations, according to the congestion procedures of the relevant MTP3 standard ✨
1.4.7 SCTP Stream Mapping.
the M3UA layer at both the SGP and ASP also supports the assignment of signalling traffic into streams within an SCTP association 🌸 traffic that requires sequencing SHOULD be assigned to the same stream 🔥 to accomplish this, MTP3-User traffic may be assigned to individual streams based on, for example, the SLS value in the MTP3 Routing Label or the ISUP CIC assignment, subject of course to the maximum number of streams supported by the underlying SCTP association 🦋
1.4.8 Client/Server Model
it is recommended that the SGP and ASP be able to support both client and server operation 🫶 the peer endpoints using M3UA SHOULD be configured so that one always takes on the role of client and the other the role of server for initiating SCTP associations 👑 the default orientation would be for the SGP to take on the role of server while the ASP is the client 💖 in this case, ASPs SHOULD initiate the SCTP association to the SGP 🧚
in the case of IPSP to IPSP communication, the peer endpoints using M3UA SHOULD be configured so that one always takes on the role of client and the other the role of server for initiating SCTP associations 🌈
the SCTP and TCP Registered User Port Number Assignment for M3UA is 2905 🎀
1.5 Sample Configuration
1.5.1 Example 1: ISUP Message Transport
******** SS7 ***************** IP ********
* SEP *---------* SGP *--------* ASP *
******** ***************** ********
+------+ +---------------+ +------+
| ISUP | | (NIF) | | ISUP |
+------+ +------+ +------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+-+------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| L1 | | L1 | | IP | | IP |
+------+ +------+ +------+ +------+
|_______________| |______________|- SEP - SS7 Signalling End Point 🌸
- SCTP - Stream Control Transmission Protocol 🦋
- NIF - Nodal Interworking Function ✨
in this example, the SGP provides an implementation-dependent nodal interworking function (NIF) that allows the MGC to exchange SS7 signalling messages with the SS7-based SEP 🔥 the NIF within the SGP serves as the interface within the SGP between the MTP3 and M3UA 💅 this nodal interworking function has no visible peer protocol with either the MGC or SEP 🙈 it also provides network status information to one or both sides of the network 💖
for internal SGP modeling purposes, at the NIF level, SS7 signalling messages that are destined to the MGC are received as MTP-TRANSFER indication primitives from the MTP Level 3 upper layer interface, translated to MTP-TRANSFER request primitives, and sent to the local M3UA-resident message distribution function for ongoing routing to the final IP destination 🧚 messages received from the local M3UA network address translation and mapping function as MTP-TRANSFER indication primitives are sent to the MTP Level 3 upper layer interface as MTP-TRANSFER request primitives, for ongoing MTP Level 3 routing to an SS7 SEP 🌈 for the purposes of providing SS7 network status information, the NIF also delivers MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives received from the MTP Level 3 upper layer interface to the local M3UA-resident management function 🎀 in addition, as an implementation and network option, restricted destinations are communicated from MTP network management to the local M3UA-resident management function 👑
1.5.2 Example 2: SCCP Transport between IPSPs
******** IP ********
* IPSP * * IPSP *
******** ********
+------+ +------+
|SCCP- | |SCCP- |
| User | | User |
+------+ +------+
| SCCP | | SCCP |
+------+ +------+
| M3UA | | M3UA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
|________________|this example shows an architecture where no Signalling Gateway is used 🦋 in this example, SCCP messages are exchanged directly between two IP-resident IPSPs with resident SCCP-User protocol instances, such as RANAP or TCAP 💜 SS7 network interworking is not required, therefore there is no MTP3 network management status information for the SCCP and SCCP-User protocols to consider 🙈 any MTP-PAUSE, MTP-RESUME or MTP-STATUS indications from the M3UA layer to the SCCP layer should consider the status of the SCTP Association and underlying IP network, and any congestion information received from the remote site 🔥✨
1.5.3 Example 3: SGP Resident SCCP Layer, with Remote ASP 🧚
Okay bestie, this one's a glow-up 💖 Here the SS7 side and the IP side meet at an SGP, and the SGP itself runs an SCCP layer.
******** SS7 ***************** IP ********
* SEP *---------* *--------* *
* or * * SGP * * ASP *
* STP * * * * *
******** ***************** ********
+------+ +---------------+ +------+
| SCCP-| | SCCP | | SCCP-|
| User | +---------------+ | User |
+------+ | _____ | +------+
| SCCP | | | | | | SCCP |
+------+ +------+-+------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+ +------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| L1 | | L1 | | IP | | IP |
+------+ +------+ +------+ +------+
|_______________| |______________|
STP - SS7 Signalling Transfer PointSo the SGP has its own SCCP instance 💅, and that instance can do SCCP Global Title Translation (GTT) for messages logically addressed to the SG SCCP. If the GTT result gives an SS7 DPC or DPC/SSN address of an SCCP peer sitting in the IP domain, the resulting MTP-TRANSFER request primitive goes to the local M3UA-resident network address translation and mapping function, which keeps routing it to the final IP destination 🦋.
The SCCP in the SGP can also do the GTT thing for messages sent to it by SCCP peers in the IP domain 🌸. In that case, MTP-TRANSFER indication primitives go from the local M3UA-resident network address translation and mapping function up to SCCP for GTT. If the GTT result is the address of an SCCP peer in the SS7 network, the resulting MTP-TRANSFER request primitive is handed to MTP3 for delivery to an SS7-resident node ✨.
It's even possible for the SCCP GTT at the SGP to land on an SCCP peer in the IP domain. Then the resulting MTP-TRANSFER request primitive gets sent back to the M3UA layer for delivery to an IP destination 🔥.
For internal SGP modeling, this can be done with an implementation-dependent nodal interworking function inside the SGP. It sits below SCCP and routes MTP-TRANSFER request/indication messages to and from both MTP3 and M3UA, based on the SS7 DPC or DPC/SSN address information. Here's the tea: this nodal interworking function has no visible peer protocol with either the ASP or the SEP 🫶.
Note that the services and interface M3UA provides are the same as in Example 1, and the functions happening in the SCCP entity are transparent to the M3UA layer. The SCCP protocol functions are not reproduced in the M3UA protocol 💜.
1.6 Definition of M3UA Boundaries 🎀
1.6.1 Definition of the Boundary between M3UA and an MTP3-User.
Okay, so the boundary between M3UA and an MTP3-User is defined by these primitives, taken from ITU Q.701 [7]:
MTP-TRANSFER requestMTP-TRANSFER indicationMTP-PAUSE indicationMTP-RESUME indicationMTP-STATUS indication
1.6.2 Definition of the Boundary between M3UA and SCTP
Example upper layer primitives provided by SCTP are listed in Reference [17] Section 10 🦋.
1.6.3 Definition of the Boundary between M3UA and Layer Management
This is the Layer Management (LM) boundary, and it's a whole list 🌈. Each entry has a name, a direction, and a purpose.
M-SCTP_ESTABLISH request(Direction:LM -> M3UA): LM asks the ASP to establish an SCTP association with its peer.M-STCP_ESTABLISH confirm(Direction:M3UA -> LM): the ASP tells LM that it has established an SCTP association with its peer.M-SCTP_ESTABLISH indication(Direction:M3UA -> LM): M3UA tells LM that a remote ASP has established an SCTP association.M-SCTP_RELEASE request(Direction:LM -> M3UA): LM asks the ASP to release an SCTP association with its peer.M-SCTP_RELEASE confirm(Direction:M3UA -> LM): the ASP tells LM that it has released the SCTP association with its peer.M-SCTP_RELEASE indication(Direction:M3UA -> LM): M3UA tells LM that a remote ASP has released an SCTP Association, or that the SCTP association has failed.M-SCTP_RESTART indication(Direction:M3UA -> LM): M3UA tells LM that an SCTP restart indication has been received.M-SCTP_STATUS request(Direction:LM -> M3UA): LM asks M3UA to report the status of an SCTP association.M-SCTP_STATUS confirm(Direction:M3UA -> LM): M3UA responds with the status of an SCTP association.M-SCTP STATUS indication(Direction:M3UA -> LM): M3UA reports the status of an SCTP association.M-ASP_STATUS request(Direction:LM -> M3UA): LM asks M3UA to report the status of a local or remote ASP.M-ASP_STATUS confirm(Direction:M3UA -> LM): M3UA reports the status of a local or remote ASP.M-AS_STATUS request(Direction:LM -> M3UA): LM asks M3UA to report the status of an AS.M-AS_STATUS confirm(Direction:M3UA -> LM): M3UA reports the status of an AS.M-NOTIFY indication(Direction:M3UA -> LM): M3UA reports that it has received a Notify message from its peer.M-ERROR indication(Direction:M3UA -> LM): M3UA reports that it has received an Error message from its peer, or that a local operation has been unsuccessful.M-ASP_UP request(Direction:LM -> M3UA): LM asks the ASP to start its operation and send an ASP Up message to its peer.M-ASP_UP confirm(Direction:M3UA -> LM): the ASP reports that it has received an ASP UP Ack message from its peer.M-ASP_UP indication(Direction:M3UA -> LM): M3UA reports that it has successfully processed an incoming ASP Up message from its peer.M-ASP_DOWN request(Direction:LM -> M3UA): LM asks the ASP to stop its operation and send an ASP Down message to its peer.M-ASP_DOWN confirm(Direction:M3UA -> LM): the ASP reports that it has received an ASP Down Ack message from its peer.M-ASP_DOWN indication(Direction:M3UA -> LM): M3UA reports that it has successfully processed an incoming ASP Down message from its peer, or that the SCTP association has been lost or reset.M-ASP_ACTIVE request(Direction:LM -> M3UA): LM asks the ASP to send an ASP Active message to its peer.M-ASP_ACTIVE confirm(Direction:M3UA -> LM): the ASP reports that it has received an ASP Active Ack message from its peer.M-ASP_ACTIVE indication(Direction:M3UA -> LM): M3UA reports that it has successfully processed an incoming ASP Active message from its peer.M-ASP_INACTIVE request(Direction:LM -> M3UA): LM asks the ASP to send an ASP Inactive message to its peer.M-ASP_INACTIVE confirm(Direction:LM -> M3UA): the ASP reports that it has received an ASP Inactive Ack message from its peer.M-ASP_INACTIVE indication(Direction:M3UA -> LM): M3UA reports that it has successfully processed an incoming ASP Inactive message from its peer.M-AS_ACTIVE indication(Direction:M3UA -> LM): M3UA reports that an AS has moved to the AS-ACTIVE state.M-AS_INACTIVE indication(Direction:M3UA -> LM): M3UA reports that an AS has moved to the AS-INACTIVE state.M-AS_DOWN indication(Direction:M3UA -> LM): M3UA reports that an AS has moved to the AS-DOWN state.
If dynamic registration of RK is supported by the M3UA layer, the layer MAY support the following additional primitives 🧚♀️:
M-RK_REG request(Direction:LM -> M3UA): LM asks the ASP to register RK(s) with its peer by sending a REG REQ message.M-RK_REG confirm(Direction:M3UA -> LM): the ASP reports that it has received a REG RSP message from its peer with registration status successful.M-RK_REG indication(Direction:M3UA -> LM): M3UA informs LM that it has successfully processed an incoming REG REQ message.M-RK_DEREG request(Direction:LM -> M3UA): LM asks the ASP to deregister RK(s) with its peer by sending a DEREG REQ message.M-RK_DEREG confirm(Direction:M3UA -> LM): the ASP reports that it has received a DEREG REQ message with deregistration status successful from its peer.M-RK_DEREG indication(Direction:M3UA -> LM): M3UA informs LM that it has successfully processed an incoming DEREG REQ from its peer.
2. Conventions ✨
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they show up in this document, are to be read as described in [20] 📖.
3. M3UA Protocol Elements 🎀
The general M3UA message format is a Common Message Header, followed by zero or more parameters as defined by the Message Type. For forward compatibility, all Message Types may have attached parameters, even if none are specified in this version 🌸.
3.1 Common Message Header ✨
The protocol messages for MTP3-User Adaptation require a message header that holds the adaptation layer version, the message type, and the message length.
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Message Class | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ /All fields in an M3UA message MUST be transmitted in the network byte order, unless otherwise stated 🔥.
3.1.1 M3UA Protocol Version: 8 bits (unsigned integer)
The version field has the version of the M3UA adaptation layer. The supported versions are the following 💜:
1 Release 1.03.1.2 Message Classes and Types 🦋
Okay so the Message Class is an 8-bit unsigned integer, and these are the valid Message Class values, bestie 💅
0 Management (MGMT) Messages
1 Transfer Messages
2 SS7 Signalling Network Management (SSNM) Messages
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
5 Reserved for Other Sigtran Adaptation Layers
6 Reserved for Other Sigtran Adaptation Layers
7 Reserved for Other Sigtran Adaptation Layers
8 Reserved for Other Sigtran Adaptation Layers
9 Routing Key Management (RKM) Messages
10 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Message Class extensionsThe Message Type is also an 8-bit unsigned integer 🎀 Each Message Class has its own list of message types, so the number only means something once you know which class you're in. Here's the full breakdown:
Management (MGMT) Messages (See Section 3.8)
0 Error (ERR)
1 Notify (NTFY)
2 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions
Transfer Messages (See Section 3.3)
0 Reserved
1 Payload Data (DATA)
2 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Transfer extensions
SS7 Signalling Network Management (SSNM) Messages (See Section
3.4)
0 Reserved
1 Destination Unavailable (DUNA)
2 Destination Available (DAVA)
3 Destination State Audit (DAUD)
4 Signalling Congestion (SCON)
5 Destination User Part Unavailable (DUPU)
6 Destination Restricted (DRST)
7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined SSNM extensions
ASP State Maintenance (ASPSM) Messages (See Section 3.5)
0 Reserved
1 ASP Up (ASPUP)
2 ASP Down (ASPDN)
3 Heartbeat (BEAT)
4 ASP Up Acknowledgement (ASPUP ACK)
5 ASP Down Acknowledgement (ASPDN ACK)
6 Heartbeat Acknowledgement (BEAT ACK)
7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions
ASP Traffic Maintenance (ASPTM) Messages (See Section 3.7)
0 Reserved
1 ASP Active (ASPAC)
2 ASP Inactive (ASPIA)
3 ASP Active Acknowledgement (ASPAC ACK)
4 ASP Inactive Acknowledgement (ASPIA ACK)
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPTM extensions
Routing Key Management (RKM) Messages (See Section 3.6)
0 Reserved
1 Registration Request (REG REQ)
2 Registration Response (REG RSP)
3 Deregistration Request (DEREG REQ)
4 Deregistration Response (DEREG RSP)
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined RKM extensions3.1.3 Reserved: 8 bits 🌸
The Reserved field SHOULD be set to all '0's, and the receiver SHOULD ignore it. Easy peasy ✨
3.1.4 Message Length: 32-bits (unsigned integer) 💜
The Message Length tells you how long the whole message is in octets, and that count includes the Common Header 🧚 The Message Length MUST include any parameter padding bytes, if there are any.
Note: A receiver SHOULD accept the message whether or not the final parameter padding is included in the message length. Be flexible, bestie 🫶
3.2 Variable Length Parameter Format 🍓
M3UA messages are built from a Common Header, followed by zero or more variable length parameters, depending on the message type. Every parameter uses a Tag Length-Value format, and it looks like this 😭
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+When a message has more than one parameter, the parameters can show up in any order, unless something explicitly says otherwise. A receiver SHOULD accept the parameters in any order, so nobody gets bent out of shape about ordering 💖
Parameter Tag: 16 bits (unsigned integer) 🎀
The Tag field is a 16-bit identifier for the parameter type, and it can be anything from 0 to 65534. Parameters used by adaptation layers in general fall in the range 0x00 to 0x3f. M3UA-specific parameters have Tags in the range 0x0200 to 0x02ff. Here's the full list of Tags:
Common Parameters are TLV parameters that are shared across the different adaptation layers:
Parameter Name Parameter ID
============== ============
Reserved 0x0000
Not Used in M3UA 0x0001
Not Used in M3UA 0x0002
Not Used in M3UA 0x0003
INFO String 0x0004
Not Used in M3UA 0x0005
Routing Context 0x0006
Diagnostic Information 0x0007
Not Used in M3UA 0x0008
Heartbeat Data 0x0009
Not Used in M3UA 0x000a
Traffic Mode Type 0x000b
Error Code 0x000c
Status 0x000d
Not Used in M3UA 0x000e
Not Used in M3UA 0x000f
Not Used in M3UA 0x0010
ASP Identifier 0x0011
Affected Point Code 0x0012
Correlation ID 0x0013M3UA-Specific parameters are TLV parameters that belong only to M3UA, so they're the M3UA-only squad 👑
Network Appearance 0x0200
Reserved 0x0201
Reserved 0x0202
Reserved 0x0203
User/Cause 0x0204
Congestion Indications 0x0205
Concerned Destination 0x0206
Routing Key 0x0207
Registration Result 0x0208
Deregistration Result 0x0209
Local_Routing Key Identifier 0x020a
Destination Point Code 0x020b
Service Indicators 0x020c
Reserved 0x020d
Originating Point Code List 0x020e
Circuit Range 0x020f
Protocol Data 0x0210
Reserved 0x0211
Registration Status 0x0212
Deregistration Status 0x0213
Reserved by the IETF 0x0214 to 0xffffThe value 65535 is reserved for IETF-defined extensions. Any value that isn't defined in a specific parameter description is also reserved for the IETF to use later 🔥
Parameter Length: 16 bits (unsigned integer) 🌈
The Parameter Length field holds the size of the parameter in bytes. That count includes the Parameter Tag, Parameter Length, and Parameter Value fields, so a parameter with an empty Parameter Value would have a Length of 4. The Parameter Length does NOT include any padding bytes 🙈
Parameter Value: variable length 🦋
The Parameter Value field is where the actual information for the parameter lives ✨
The total length of a parameter, counting the Tag, Parameter Length, and Value fields, MUST be a multiple of 4 bytes. If the parameter isn't a multiple of 4 bytes, the sender pads it at the end (after the Parameter Value field) with all zero bytes. The padding length is NOT included in the parameter length field. A sender SHOULD NOT pad with more than 3 bytes, and the receiver MUST ignore the padding bytes 💅
3.3 Transfer Messages 🧚
The following section describes the Transfer messages and their parameter contents 💖
3.3.1 Payload Data Message (DATA) ✨
okay bestie, the DATA message is where the actual SS7 MTP3-User protocol data lives 💌. It's an MTP-TRANSFER primitive, and it carries the complete MTP3 Routing Label too 🧚. It has these variable length parameters:
Network Appearance Optional
Routing Context Optional
Protocol Data Mandatory
Correlation Id OptionalThe following format MUST be used for the Data Message 🎀:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0210 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0013 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Network Appearance: 32-bits (unsigned integer) 🌍
The Network Appearance parameter tells you which SS7 network context the message belongs to, and it implicitly tells you the SS7 Point Code format, the SS7 Network Indicator value, and the MTP3 and possibly the MTP3-User protocol type/variant/version used inside that specific SS7 network. If an SG works in just one SS7 network context, or each SCTP association is dedicated to its own SS7 network context, the Network Appearance parameter is not required. Otherwise it can be configured to be present so the receiver can use it 👀.
The Network Appearance parameter value is of local significance only, coordinated between the SGP and ASP. So if an ASP is connected to more than one SGP, the same SS7 network context may be identified by different Network Appearance values depending on which SGP a message is being transmitted or received through 🔄.
Where the optional Network Appearance parameter is present, it must be the first parameter in the message, because it defines the format of the Protocol Data field 🥇.
IMPLEMENTATION NOTE: For simplicity of configuration it may be desirable to use the same NA value across all nodes sharing a particular network context 🫶.
Routing Context: 32-bits (unsigned integer) 🗝️
The Routing Context parameter contains the Routing Context value associated with the DATA message. Where a Routing Key has not been coordinated between the SGP and ASP, sending Routing Context is not required. Where multiple Routing Keys and Routing Contexts are used across a common association, the Routing Context MUST be sent to identify the traffic flow, which helps with the internal distribution of Data messages 🦋.
Protocol Data: variable length 📦
The Protocol Data parameter contains the original SS7 MTP3 message, including the Service Information Octet and Routing Label ✨.
The Protocol Data parameter contains the following fields:
- Service Indicator,
- Network Indicator,
- Message Priority.
- Destination Point Code,
- Originating Point Code,
- Signalling Link Selection Code (SLS).
- User Protocol Data. Includes:
- MTP3-User protocol elements (e.g., ISUP, SCCP, or TUP parameters).
The Protocol Data parameter is encoded as follows 💅:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI | NI | MP | SLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Protocol Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Originating Point Code: 32 bits (unsigned integer) Destination Point Code: 32 bits (unsigned integer)
The Originating and Destination Point Code fields contain the OPC and DPC from the routing label of the original SS7 message, in Network Byte Order, justified to the least significant bit. Unused bits are coded `0'.
Service Indicator: 8 bits (unsigned integer)
The Service Indicator field contains the SI field from the original SS7 message, justified to the least significant bit. Unused bits are coded `0'.
Network Indicator: 8-bits (unsigned integer)
The Network Indicator contains the NI field from the original SS7 message, justified to the least significant bit. Unused bits are coded `0'.
Message Priority: 8 bits (unsigned integer)
The Message Priority field contains the MP bits (if any) from the original SS7 message, for both ANSI-style and TTC-style [29] message priority bits. The MP bits are aligned to the least significant bit. Unused bits are coded `0'.
Signalling Link Selection: 8 bits (unsigned integer)
The Signalling Link Selection field contains the SLS bits from the routing label of the original SS7 message, justified to the least significant bit and in Network Byte Order. Unused bits are coded `0'.
User Protocol Data: (byte string) 🧁
The User Protocol Data field contains a byte string of MTP-User information from the original SS7 message, starting with the first byte of the original SS7 message following the Routing Label.
Correlation Id: 32-bits (unsigned integer) 🔖
The Correlation Id parameter uniquely identifies the MSU carried in the Protocol Data within an AS. This Correlation Id parameter is assigned by the sending M3UA 🫶.
3.4 SS7 Signalling Network Management (SSNM) Messages 🌸
3.4.1 Destination Unavailable (DUNA) ✨
okay so the DUNA message is the one an SGP sends from an SG to all the concerned ASPs 💌 It's basically the SG going "hey bestie, I've figured out one or more SS7 destinations can't be reached rn" 😭 The SGP also sends it back when an ASP sends a message to an unreachable SS7 destination, so the ASP knows to stop 🙅♀️ Here's the lowkey clutch part: the SG is allowed (it's an implementation option!) to hold back on sending more of those "response" DUNA messages about a certain unreachable SS7 destination for a while, so the other side has time to react 🕰️ And if there's no alternate route through another SG, the MTP3-User at the ASP is expected to stop sending traffic to that destination through this SG, following the defined MTP3-User procedures 🛑
The DUNA message contains the following parameters:
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
INFO String OptionalThe format for DUNA Message parameters is as follows:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Network Appearance: 32-bit unsigned integer 🌸
See Section 3.3.1
Routing Context: n x 32-bits (unsigned integer) 🦋
The optional Routing Context parameter carries the Routing Context values linked to the DUNA message. If a Routing Key hasn't been coordinated between the SGP and ASP, sending Routing Context isn't required 🙌 But when multiple Routing Keys and Routing Contexts are running over one common association, the Routing Context(s) MUST be sent so the receiver can tell which traffic flows the DUNA applies to. That's what keeps outgoing traffic management and the MTP-PAUSE indications going to the right MTP3-Users on the receiving end 💅
Affected Point Code: n x 32-bits 🎀
The Affected Point Code parameter is a list of Affected Destination Point Code fields. Each one is three octets, so it can fit 14-, 16- and 24-bit binary formatted SS7 Point Codes 🧚 Affected Point Codes shorter than 24 bits get padded on the left out to the 24-bit boundary. Here's how it looks for ANSI and ITU Point Code examples:
ANSI 24-bit Point Code:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Network | Cluster | Member |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB-----------------------------------------LSB|ITU 14-bit Point Code:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB--------------------LSB|It's optional to send an Affected Point Code parameter with more than one Affected PC, but it's mandatory to receive one 🫶 Packing in multiple Affected PCs can be handy when an MTP3 management message or a linkset event hits the availability of a whole list of destinations at an SG at the same time 🔥
Mask: 8-bits (unsigned integer) 💜
The Mask field can pick out a contiguous range of Affected Destination Point Codes. That's useful when an MTP3 management message or a linkset event changes the availability of a whole series of destinations at an SG at once 🌈
The Mask parameter is an integer that represents a bit mask, applied to the related Affected PC field. The mask shows how many bits of the Affected PC field matter and which ones are effectively "wildcarded" 🙈 For example, a mask of "8" means the last eight bits of the PC are "wildcarded". For an ANSI 24-bit Affected PC, that's the same as saying every PC in an ANSI Cluster is unavailable 😭 A mask of "3" means the last three bits of the PC are "wildcarded". For a 14-bit ITU Affected PC, that's the same as saying an ITU
Region is unavailable. A mask value equal to (or greater than) the number of bits in the PC means the entire network appearance is affected, and that's how you tell the ASP the network is isolated 🚨
INFO String: variable length 🧸
The optional INFO String parameter can carry any meaningful UTF-8 [10] character string along with the message. It's 0 to 255 octets long. No procedures are currently defined for it, but the INFO String MAY be used for debugging purposes 🐛
3.4.2 Destination Available (DAVA) 🌤️
The DAVA message is the glow-up version of DUNA 🌟 It's sent from an SGP to all concerned ASPs to say the SG has figured out one or more SS7 destinations are reachable again (and not restricted). It's also sent in response to a DAUD message, if that makes sense. If the ASP M3UA layer had no routes to those affected destinations before, the ASP MTP3-User protocol gets informed and can resume traffic to the affected destination 🥳 From then on, the ASP M3UA layer routes MTP3-user traffic through the SG that started the DAVA message 💖
The DAVA message contains the following parameters:
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
INFO String OptionalThe format and description of the Network Appearance, Routing Context, Affected Point Code and INFO String parameters is the same as for the DUNA message (See Section 3.4.1). 🫠 Same vibes, same rules, no need to re-learn it, bestie ✨
3.4.3 Destination State Audit (DAUD) 🔍
The DAUD message MAY be sent from the ASP to the SGP to audit the availability/congestion state of SS7 routes from the SG to one or more affected destinations. It's basically the ASP checking in like "yo, is this route still good?" 💅
The DAUD message contains the following parameters:
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
INFO String OptionalThe format and description of DAUD Message parameters is the same as for the DUNA message (See Section 3.4.1). It's giving déjà vu, but iconic 💜
3.4.4 Signalling Congestion (SCON) 🚦
okay so SCON is the message an SGP sends to all the concerned ASPs to say "heads up, the SS7 network is congested toward one or more destinations" 🚦. it can also go to one specific ASP as a reply to a DATA or DAUD message, whichever fits best 💅. some MTP flavours (ANSI MTP is the big one 👀) can send SCON whenever the congestion level changes. and here's the lowkey iconic part: an ASP's M3UA layer can send SCON to its M3UA peer too, to say its M3UA layer or the whole ASP is congested 🫠. the SCON message MAY also be sent that way ✨.
The SCON message contains the following parameters:
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
Concerned Destination Optional
Congestion Indications Optional
INFO String OptionalThe format for SCON Message parameters is as follows:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0206 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Concerned DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0205 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Cong. Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Network Appearance, Routing Context, Affected Point Code and INFO String parameters work exactly the same as in the DUNA message (see Section 3.4.1) 🫶. the Affected Point Code parameter can be used to flag congestion for multiple destinations or whole ranges of them 🔥.
Concerned Destination: 32-bits
this one is optional and only shows up when the SCON is going from an ASP to the SGP 🎀. it holds the point code of whoever sent the message that set off the SCON. it has one Concerned Destination Point Code field, which is three octets, so it can fit 14-, 16- and 24-bit binary SS7 Point Codes 🧚. anything shorter than 24 bits gets padded on the left out to the 24-bit boundary 🌸. then any Transfer Controlled (TFC) message the SG sends back goes to the Concerned Point Code, and it uses the single Affected DPC from the SCON to fill in the (affected) Destination field of that TFC message 💖.
Congested Indications: 32-bits
this one is optional too 🌈. it has a Congestion Level field, and it's used for national MTP networks that have multiple congestion thresholds, like ANSI MTP3 👑. for MTP congestion methods that only have one level (the ITU international method is the example), this parameter just isn't included 🙈.
Congestion Level field: 8-bits (unsigned integer)
the Congestion Level field goes with all of the Affected DPC(s) in the Affected Destinations parameter, and it's one of these values:
0 No Congestion or Undefined
1 Congestion Level 1
2 Congestion Level 2
3 Congestion Level 3the congestion levels themselves are defined in the congestion method of the right national MTP recommendations [7,8] 📚.
3.4.5 Destination User Part Unavailable (DUPU) 💀
the DUPU message is how an SGP tells the concerned ASPs that a remote peer MTP3-User Part (think ISUP or SCCP) at some SS7 node is unavailable 😭.
The DUPU message contains the following parameters:
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
User/Cause Mandatory
INFO String OptionalThe format for DUPU message parameters is as follows:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0012 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Affected PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0204 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+User/Cause: 32-bits
the Unavailability Cause and MTP3-User Identity fields, which go with the Affected PC in the Affected Point Code parameter, are encoded like this 🎀:
Unavailability Cause field: 16-bits (unsigned integer)
this is the reason the MTP3-User is unavailable 🥺. the valid values are in the table below, and they match the ones in the SS7 MTP3 User Part Unavailable message. depending on the MTP3 protocol in the Network Appearance, extra values might be used too, and the spec for that MTP3 variant/version recommendation is the final word 📖.
0 Unknown
1 Unequipped Remote User
2 Inaccessible Remote UserMTP3-User Identity field: 16-bits (unsigned integer)
this one says which MTP3-User is unavailable (ISUP, SCCP, and so on) 💅. some of the valid values are below, and they line up with the UPU message and the Service Indicator. extra values can show up depending on the MTP3 variant/version in the network appearance, and again the relevant recommendation is definitive ✨.
0 to 2 Reserved
3 SCCP
4 TUP
5 ISUP
6 to 8 Reserved
9 Broadband ISUP
10 Satellite ISUP
11 Reserved
12 AAL type 2 Signalling
13 Bearer Independent Call Control (BICC)
14 Gateway Control Protocol
15 Reservedthe Affected Point Code parameter works like it does in the DUNA message (see Section 3.4.1), with two differences 🌸. the Mask field isn't used, and only one Affected DPC is included. ranges and lists of Affected DPCs can't be signalled in a DUPU message, which is consistent with how UPU works in the SS7 network 🧚. the Affected Destinations parameter in a UPU message that an SGP gets from the SS7 network only contains one destination, so yeah, one at a time bestie 🍓.
the Network Appearance, Routing Context and INFO String parameters work exactly the same as in the DUNA message (see Section 3.4.1) 🫶.
3.4.6 Destination Restricted (DRST) 🚧
okay so the DRST message is an optional one the SGP can send to all the concerned ASPs 💅 to say the SG has figured out that one or more SS7 destinations are now restricted from where the SG is sitting. it can also be a reply to a DAUD message if that makes sense. the M3UA layer at the ASP is expected to send traffic to the affected destination through an alternate SG with route(s) of equal priority, but only if that alternate route actually exists and is available 🛣️. if the ASP currently thinks the affected destination is unavailable, the MTP3-User should be told that traffic to that destination can be resumed ✨. in that case the M3UA layer should route the traffic through the SG that sent the DRST message 🫶.
this message is optional for the SG to send, and it's optional for the ASP to act on anything in it 🙈. it's for use in the "STP" case from Section 1.4.1.
the DRST message contains the following parameters:
Network Appearance Optional
Routing Context Optional
Affected Point Code Mandatory
INFO String Optionalthe format and description of the Network Appearance, Routing Context, Affected Point Code and INFO String parameters is the same as for the DUNA message (See Section 3.4.1) 🎀.
3.5 ASP State Maintenance (ASPSM) Messages 🌸
3.5.1 ASP Up 🌱
the ASP Up message is how you tell a remote M3UA peer that your adaptation layer is ready to receive any ASPSM/ASPTM messages for all the Routing Keys the ASP is set up to serve 🔥.
the ASP Up message contains the following parameters:
ASP Identifier Optional
INFO String Optionalthe format for ASP Up message parameters looks like this 👀:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ASP Identifier: 32-bit unsigned integer 🪪
the optional ASP Identifier parameter holds a unique value that's locally significant among the ASPs that support an AS. the SGP should save the ASP Identifier to be used, if necessary, with the Notify message (see Section 3.8.2) 💜.
the format and description of the optional INFO String parameter is the same as for the DUNA message (See Section 3.4.1) ✨.
3.5.2 ASP Up Acknowledgement (ASP Up Ack) 💖
the ASP UP Ack message is how you acknowledge an ASP Up message that came in from a remote M3UA peer 🫶.
the ASP Up Ack message contains the following parameters:
INFO String (optional)the format for ASP Up Ack message parameters looks like this:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the format and description of the optional INFO String parameter is the same as for the DUNA message (See Section 3.4.1) 🌈. the INFO String in an ASP Up Ack message is independent from the INFO String in the ASP Up message (i.e., it does not have to echo back the INFO String received) 🙌.
3.5.3 ASP Down 🌧️
the ASP Down message tells a remote M3UA peer that the adaptation layer is NOT ready to receive DATA, SSNM, RKM or ASPTM messages 😭.
the ASP Down message contains the following parameters:
INFO String Optionalthe format for the ASP Down message parameters looks like this:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the format and description of the optional INFO String parameter is the same as for the DUNA message (See Section 3.4.1) 🍓.
3.5.4 ASP Down Acknowledgement (ASP Down Ack) 🌙
the ASP Down Ack message is how you acknowledge an ASP Down message that came in from a remote M3UA peer 💅.
the ASP Down Ack message contains the following parameters:
INFO String Optionalthe format for the ASP Down Ack message parameters looks like this:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the format and description of the optional INFO String parameter is the same as for the DUNA message (See Section 3.4.1) ✨.
the INFO String in an ASP Down Ack message is independent from the INFO String in the ASP Down message (i.e., it does not have to echo back the INFO String received) 🧚.
3.5.5 Heartbeat (BEAT) 💓
the BEAT message is an optional way to make sure the M3UA peers are still around for each other 🫀. it's recommended for use when the M3UA runs over a transport layer other than SCTP, since SCTP has its own heartbeat 🌸.
the BEAT message contains the following parameters:
Heartbeat Data Optionalthe format for the BEAT message is as follows:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the sending node decides what goes in the Heartbeat Data parameter. it could include, for example, a Heartbeat Sequence Number and/or Timestamp 🕰️. the receiver of a BEAT message doesn't process this field, since it only matters to the sender 🙈. the receiver MUST respond with a BEAT Ack message 🔥.
3.5.6 Heartbeat Acknowledgement (BEAT Ack) 🫶
the BEAT Ack message is sent in response to a BEAT message that was received. it includes all the parameters of the received BEAT message, without any change 💜.
3.6 Routing Key Management (RKM) Messages [Optional] 🗝️
3.6.1 Registration Request (REG REQ) 📝
the REG REQ message is how an ASP tells a remote M3UA peer that it wants to register one or more given Routing Keys with that peer 🙌. usually an ASP sends this to an SGP, and it's expecting a REG RSP message back with an associated Routing Context value 💅.
the REG REQ message contains the following parameters:
Routing Key MandatoryOne or more Routing Key parameters MAY be included. the format for the REG REQ message looks like this:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Key 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Key n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Routing Key: variable length 🔑
the Routing Key parameter is mandatory 🥹. the sender of this message expects that the receiver will create a Routing Key entry and assign a unique Routing Context value to it, but only if that Routing Key entry doesn't already exist 🌈.
the Routing Key parameter may be present multiple times in the same message. this lets you register multiple Routing Keys in a single message 🧚.
the format of the Routing Key parameter is as follows.
Okay bestie, the Routing Key is basically a little box of filters 📦✨ Here's the full layout, and yes, it's giving spreadsheet energy 💅
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Range List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Range List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note 🫶 The Destination Point Code, Service Indicators, Originating Point Code List and Circuit Range List parameters MAY be repeated as a grouping within the Routing Key parameter, in the structure shown above.
Local-RK-Identifier 🔑
Okay so the Local-RK-Identifier is a 32-bit unsigned integer, and it's the mandatory one 🎀 It's how we match things up! The ASP picks the value, and then the REG RSP message uses it to correlate back to the original registration request, so nothing gets mixed up 🦋 The value must remain unique until that REG RSP message shows up. No duplicates allowed, bestie 🙈
Here's how the field is laid out:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Traffic Mode Type 🚦
Traffic Mode Type is a 32-bit (unsigned integer) and it's optional 🌸 It tells you which traffic mode the ASP(s) inside an Application Server are running in. Format time:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The valid values are in this table, and that's literally the whole list 💜
1 Override
2 Loadshare
3 BroadcastDestination Point Code 📍
This one is mandatory, no skipping! It identifies the Destination Point Code of the incoming SS7 traffic that the ASP is registering for 💖 The format matches the Affected Destination parameter in the DUNA message (See Section 3.4.1), so if you already know that one, you're set ✨ Here it is:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Network Appearance 🌐
The optional Network Appearance field tells you which SS7 network context the Routing Key belongs to, and it has the same format as the one in the DATA message (See Section 3.3.1) 🦋 If this parameter is missing from the Routing Key, that means any Network Appearance value is fine. Its format:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Service Indicators (SI): n X 8-bit integers 🧩
The optional SI [7,8] field holds one or more Service Indicators, picked from the values described in the MTP3-User Identity field of the DUPU message 💅 If the SI parameter is left out of the Routing Key, that means any SI value works, except of course MTP management, because obviously 🙄 If an SI parameter doesn't have a multiple of four SIs, it gets padded out to 32-byte alignment, so it stays neat and tidy ✨
The SI format:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020c | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #1 | SI #2 | SI #3 | SI #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SI #n | 0 Padding, if necessary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OPC List 🛰️
The Originating Point Code List holds one or more SS7 OPC entries, and it's formatted just like the Destination Point Code parameter 💜 If the OPC List is absent from the Routing Key, that means any OPC value is accepted, and honestly that's very chill 😌
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Circuit Range 🎟️
Okay, this part is lowkey the most detailed 🤓 An ISUP controlled circuit is uniquely identified by its SS7 OPC, DPC and CIC value 💖 So to identify Circuit Ranges in an M3UA Routing Key, the optional Circuit Range parameter lists one or more circuit ranges, each one identified by an OPC plus an Upper/Lower CIC value. The DPC is implicit, since it's mandatory and already sitting in the DPC parameter of the Routing Key. If the Circuit Range parameter is missing, that means any Circuit Range values are fine, for ISUP/TUP traffic. The Origination Point Code is encoded just like the Destination Point Code parameter, and the CIC values are 16-bit integers 🌈
The Circuit Range format goes like this:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020f | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #1 | Upper CIC Value #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #2 | Upper CIC Value #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower CIC Value #n | Upper CIC Value #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.6.2 Registration Response (REG RSP) 🎀
okay bestie, so the REG RSP message is the reply to a REG REQ from a remote M3UA peer 💅 It tells you if each registration slayed or flopped 😭, and when one works, it hands back a unique Routing Context value 🦋 that you'll use for all your M3UA Traffic Management stuff after that ✨
The REG RSP message contains the following parameters:
Registration Result MandatoryOne or more Registration Result parameters MUST be included. 🔥 The format for the REG RSP message is as follows:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Registration Results:
The Registration Result parameter contains the registration result for a single Routing Key in an REG REQ message. ✨ The number of results in a single REG RSP message MUST be anywhere from one to the total number of number of Routing Key parameters found in the corresponding REG REQ message. Where multiple REG RSP messages are used in reply to REG REQ message, a specific result SHOULD be in only one REG RSP message. The format of each result is as follows:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-RK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0212 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Local-RK-Identifier: 32-bit integer 🦋
The Local-RK-Identifier contains the same value as found in the matching Routing Key parameter found in the REG REQ message (See Section 3.6.1).
Registration Status: 32-bit integer 💀
The Registration Result Status field indicates the success or the reason for failure of a registration request. Its values may be:
0 Successfully Registered
1 Error - Unknown
2 Error - Invalid DPC
3 Error - Invalid Network Appearance
4 Error - Invalid Routing Key
5 Error - Permission Denied
6 Error - Cannot Support Unique Routing
7 Error - Routing Key not Currently Provisioned
8 Error - Insufficient Resources
9 Error - Unsupported RK parameter Field
10 Error - Unsupported/Invalid Traffic Handling ModeRouting Context: 32-bit integer 🌸
The Routing Context field contains the Routing Context value for the associated Routing Key if the registration was successful. It is set to "0" if the registration was not successful.
3.6.3 Deregistration Request (DEREG REQ) 🦋
The DEREG REQ message is sent by an ASP to indicate to a remote M3UA peer that it wishes to deregister a given Routing Key. Typically, an ASP would send this message to an SGP, and expects to receive a DEREG RSP message in return with the associated Routing Context value. ✨
The DEREG REQ message contains the following parameters:
Routing Context MandatoryThe format for the DEREG REQ message is as follows:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Routing Context: n X 32-bit integers 🍓
The Routing Context parameter contains (a list of) integers indexing the Application Server traffic that the sending ASP is currently registered to receive from the SGP but now wishes to deregister.
3.6.4 Deregistration Response (DEREG RSP) 💖
The DEREG RSP message is used as a response to the DEREG REQ message from a remote M3UA peer.
The DEREG RSP message contains the following parameters:
Deregistration Result MandatoryOne or more Deregistration Result parameters MUST be included. 🔥 The format for the DEREG RSP message is as follows:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Result n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Deregistration Results:
The Deregistration Result parameter contains the deregistration status for a single Routing Context in a DEREG REQ message. The number of results in a single DEREG RSP message MAY be anywhere from one to the total number of number of Routing Context values found in the corresponding DEREG REQ message.
Where multiple DEREG RSP messages are used in reply to DEREG REQ message, a specific result SHOULD be in only one DEREG RSP message. The format of each result is as follows:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0213 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deregistration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Routing Context: 32-bit integer 🌈
The Routing Context field contains the Routing Context value of the matching Routing Key to deregister, as found in the DEREG REQ message.
Deregistration Status: 32-bit integer 🫶
The Deregistration Result Status field indicates the success or the reason for failure of the deregistration. Its values may be:
0 Successfully Deregistered
1 Error - Unknown
2 Error - Invalid Routing Context
3 Error - Permission Denied
4 Error - Not Registered
5 Error - ASP Currently Active for Routing Context3.7 ASP Traffic Maintenance (ASPTM) Messages ✨
3.7.1 ASP Active 🦋
okay so the ASP Active message is how an ASP tells its remote M3UA peer "hey, I'm ready to handle signalling traffic for this Application Server" 💅✨. it only changes the ASP state for the Routing Keys identified by the Routing Contexts, if those are present 🎀
the ASP Active message contains these parameters:
Traffic Mode Type Optional
Routing Context Optional
INFO String Optionalhere's the format for the ASP Active message 👑
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Traffic Mode Type (32-bit unsigned integer) 🌸
this one tells everyone what traffic mode the ASP is working in within an AS. the valid values are:
1 Override
2 Loadshare
3 Broadcastwithin a particular Routing Context, Override, Loadshare and Broadcast SHOULD NOT be mixed 🙈 Override means the ASP is in Override mode and takes over ALL the traffic in an Application Server (aka primary/backup operation), overriding any currently active ASPs in the AS 👑. Loadshare means the ASP shares the traffic distribution with any other currently active ASPs 🫶. Broadcast means the ASP gets the same messages as every other currently active ASP 🌈
Routing Context (n X 32-bit integers) 🧚
this optional parameter is a (list of) integers that index the Application Server traffic the sending ASP is configured or registered to receive 💜. there's a one-to-one relationship between an index entry and an SGP Routing Key or AS Name. because an AS can only appear in one Network Appearance, the Network Appearance parameter is NOT required in the ASP Active message, which is so convenient 💖
an Application Server Process can be configured to process traffic for more than one logical Application Server, and from an ASP's point of view a Routing Context defines the range of signalling traffic it's currently configured to receive from the SGP ✨. for example, an ASP could support call processing for multiple ranges of PSTN trunks and receive the related signalling traffic, identified by separate SS7 DPC/OPC/CIC ranges 🦋
INFO String is optional, and its format and description are the same as for the DUNA message (See Section 3.4.1) 🎀
3.7.2 ASP Active Acknowledgement (ASP Active Ack) 💖
the ASP Active Ack message is used to acknowledge an ASP Active message received from a remote M3UA peer 🫶
the ASP Active Ack message contains these parameters:
Traffic Mode Type Optional
Routing Context Optional
INFO String Optionalhere's the format for the ASP Active Ack message 💅
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the format and description of the optional INFO String parameter is the same as for the DUNA message (See Section 3.4.1) 🌸
the INFO String in an ASP Active Ack message is independent from the INFO String in the ASP Active message, so it does NOT have to echo back the INFO String it received 🧚
the format of the Traffic Mode Type and Routing Context parameters is the same as for the ASP Active message (See Section 3.7.1) 💜
3.7.3 ASP Inactive 🌈
the ASP Inactive message is sent by an ASP to tell a remote M3UA peer that it's no longer an active ASP to be used from within a list of ASPs 😭. it only affects the ASP state in the Routing Keys identified by the Routing Contexts, if present ✨
the ASP Inactive message contains these parameters:
Routing Context Optional
INFO String Optionalhere's the format for the ASP Inactive message parameters 🦋
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the format and description of the optional Routing Context and INFO String parameters is the same as for the ASP Active message (See Section 3.5.5.) 🎀
3.7.4 ASP Inactive Acknowledgement (ASP Inactive Ack) 🫶
the ASP Inactive Ack message is used to acknowledge an ASP Inactive message received from a remote M3UA peer 💖
the ASP Inactive Ack message contains these parameters:
Routing Context Optional
INFO String Optionalhere's the format for the ASP Inactive Ack message 🔥
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the format and description of the optional INFO String parameter is the same as for the DUNA message (See Section 3.4.1.) 🌸
the INFO String in an ASP Inactive Ack message is independent from the INFO String in the ASP Inactive message, so it does NOT have to echo back the INFO String it received 🧚
the format of the Routing Context parameter is the same as for the ASP Inactive message (See Section 3.7.3). 💜
3.8 Management (MGMT) Messages 🎀
3.8.1 Error ✨
Okay so the Error message is how you tell your peer "hey, something went wrong with that message you just sent" 💅 It's used to notify a peer of an error event tied to an incoming message. Like, the message type might be unexpected for the state they're in, or a parameter value might be invalid. Not it 💀
The Error message has these parameters, bestie 🧚
Error Code Mandatory
Routing Context Mandatory*
Network Appearance Mandatory*
Affected Point Code Mandatory*
Diagnostic Information Optional
(*) Only mandatory for specific Error CodesAnd here's the layout of the Error message 🎀
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000c | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag - 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected Point Code 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected Point Code n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0200 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Diagnostic Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Error Code: 32-bits (unsigned integer) 🔢
The Error Code is the reason tag for the Error Message 🏷️ It's a 32-bit unsigned integer, and the value can be one of these:
0x01 Invalid Version
0x02 Not Used in M3UA
0x03 Unsupported Message Class
0x04 Unsupported Message Type
0x05 Unsupported Traffic Mode Type
0x06 Unexpected Message
0x07 Protocol Error
0x08 Not used in M3UA
0x09 Invalid Stream Identifier
0x0a Not used in M3UA
0x0b Not used in M3UA
0x0c Not used in M3UA
0x0d Refused - Management Blocking
0x0e ASP Identifier Required
0x0f Invalid ASP Identifier
0x10 Not Used in M3UA
0x11 Invalid Parameter Value
0x12 Parameter Field Error
0x13 Unexpected Parameter
0x14 Destination Status Unknown
0x15 Invalid Network Appearance
0x16 Missing Parameter
0x17 Not Used in M3UA
0x18 Not Used in M3UA
0x19 Invalid Routing Context
0x1a No Configured AS for ASPThe "Invalid Stream Identifier" error 🙈 is sent if a message is received on an unexpected SCTP stream (e.g., a MGMT message was received on a stream other than "0"). Error messages MUST NOT be generated in response to other Error messages. Hard rule, no exceptions 🫶
The "Unsupported Message Class" error is sent if a message with an unexpected or unsupported Message Class is received.
The "Unsupported Message Type" error is sent if a message with an unexpected or unsupported Message Type is received.
The "Unsupported Traffic Mode Type" error is sent by a SGP if an ASP sends an ASP Active message with an unsupported Traffic Mode Type or a Traffic Mode Type that is inconsistent with the presently configured mode for the Application Server. An example would be a case in which the SGP did not support loadsharing.
The "Unexpected Message" error MAY be sent if a defined and recognized message is received that is not expected in the current state (in some cases the ASP may optionally silently discard the message and not send an Error message). For example, silent discard is used by an ASP if it received a DATA message from an SGP while it was in the ASP-INACTIVE state. If the Unexpected message contained Routing Context(s), the Routing Context(s) SHOULD be included in the Error message. Main character energy 🦋
The "Protocol Error" error is sent for any protocol anomaly (i.e., reception of a parameter that is syntactically correct but unexpected in the current situation.
The "Invalid Stream Identifier" error is sent if a message is received on an unexpected SCTP stream (e.g., a Management message was received on a stream other than "0"). Yes, it's repeated, it's giving important 📌
The "Refused - Management Blocking" error is sent when an ASP Up or ASP Active message is received and the request is refused for management reasons (e.g., management lockout"). If this error is in response to an ASP Active message, the Routing Context(s) in the ASP Active message SHOULD be included in the Error message. 🚫
The "ASP Identifier Required" is sent by a SGP in response to an ASP Up message which does not contain an ASP Identifier parameter when the SGP requires one. The ASP SHOULD resend the ASP Up message with an ASP Identifier. Try again, babe 🌸
The "Invalid ASP Identifier" is sent by an SGP in response to an ASP Up message with an invalid (i.e., non-unique) ASP Identifier.
The "Invalid Parameter Value " error is sent if a message is received with an invalid parameter value (e.g., a DUPU message was received with a Mask value other than "0".
The "Parameter Field Error" would be sent if a message is received with a parameter having a wrong length field.
The "Unexpected Parameter" error would be sent if a message contains an invalid parameter.
The "Destination Status Unknown" Error MAY be sent if a DAUD is received at an SG enquiring of the availability/congestion status of a destination, and the SG does not wish to provide the status (e.g., the sender is not authorized to know the status). For this error, the invalid or unauthorized Point Code(s) MUST be included along with the Network Appearance and/or Routing Context associated with the Point Code(s). Privacy queen 👑
The "Invalid Network Appearance" error is sent by a SGP if an ASP sends a message with an invalid (unconfigured) Network Appearance value. For this error, the invalid (unconfigured) Network Appearance MUST be included in the Network Appearance parameter.
The "Missing Parameter" error would be sent if a mandatory parameter were not included in a message.
The "Invalid Routing Context" error is sent if a message is received from a peer with an invalid (unconfigured) Routing Context value. For this error, the invalid Routing Context(s) MUST be included in the Error message.
The "No Configured AS for ASP" error is sent if a message is received from a peer without a Routing Context parameter and it is not known by configuration data which Application Servers are referenced. ✨
Diagnostic Information: variable length 🧩
When included, the optional Diagnostic information can be any information germane to the error condition, to assist in identification of the error condition. The Diagnostic information SHOULD contain the offending message. Receipts, bestie 🧾💜
3.8.2 Notify ✨
okay so the Notify message is how an M3UA peer gets an autonomous heads-up about M3UA events 🔔 no asking required, it just tells you what's up bestie 💅
The Notify message contains the following parameters:
Status Mandatory
ASP Identifier Optional
Routing Context Optional
INFO String Optionalthe format is giving very structured vibes 🎀:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000d | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0011 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Status Type: 16-bits (unsigned integer) 💖
The Status Type parameter tells you what kind of Notify message you're getting. These are the valid Status Type values:
1 Application Server State Change (AS-State_Change)
2 OtherStatus Information: 16-bits (unsigned integer) 🌸
The Status Information parameter gives you the juicy details for the notification, and what it means depends on the Status Type. If the Status Type is AS-State_Change, these Status Information values are used:
1 reserved
2 Application Server Inactive (AS-INACTIVE)
3 Application Server Active (AS-ACTIVE)
4 Application Server Pending (AS-PENDING)these notifications get sent from an SGP to an ASP whenever a particular Application Server changes status 🦋. The value reflects the new state of the Application Server, so it's always the latest tea ☕.
If the Status Type is Other, then these Status Information values are defined:
1 Insufficient ASP Resources Active in AS
2 Alternate ASP Active
3 ASP Failurethese notifications are NOT about the SGP reporting a state change of an ASP or AS. Read that twice, it matters 🙈
for the Insufficient ASP Resources case, the SGP is telling an ASP_INACTIVE ASP in the AS that another ASP is needed to handle the load of the AS (Loadsharing or Broadcast mode) 🧚. For the Alternate ASP Active case, an ASP gets informed when an alternate ASP moves to the ASP-ACTIVE state in Override mode. The ASP Identifier (if available) of the Alternate ASP MUST be placed in the message. For the ASP Failure case, the SGP is telling the ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN 💀. The ASP Identifier (if available) of the failed ASP MUST be placed in the message.
The format and description of the optional ASP Identifier is the same as for the ASP Up message (See Section 3.5.1). The format and description of the Routing Context and Info String parameters is the same as for the ASP Active message (See Section 3.7.1) 🫶
4. Procedures 🛠️
okay the M3UA layer has to respond to a bunch of local primitives from other layers, plus the messages it gets from its peer M3UA layer 📬. This section is the playbook for how it reacts to all of that 👑.
4.1 Procedures to Support the M3UA-User 💅
4.1.1 Receipt of Primitives from the M3UA-User
when an MTP-TRANSFER request primitive comes in from an upper layer at an ASP/IPSP, or from the nodal interworking function at an SGP, the M3UA layer sends a matching DATA message (see Section 3) to its M3UA peer 🚀. The peer receiving that DATA message sends an MTP-TRANSFER indication primitive up to its upper layer ✨.
The M3UA message distribution function (see Section 1.4.2.1) figures out the Application Server (AS) by comparing the info in the MTP-TRANSFER request primitive with a provisioned Routing Key 🔑.
From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE state gets picked, a DATA message is built, and it's sent out on the matching SCTP association 🎀. If more than one ASP is in the ASP-ACTIVE state (aka traffic is being loadshared across more than one ASP), one of those ASPs gets picked from the list 🌈. If the ASPs are in Broadcast Mode, all active ASPs get picked and the message goes to each one of them 📣. The selection algorithm is up to the implementation 🤷♀️, and it could be something like round robin or based on the SLS or ISUP CIC 🍓. Choosing it carefully is a must, since it depends on the application's assumptions and how well the ASP-ACTIVE ASPs in the AS coordinate their state 🧠.
on top of that, the message has to go out on the right SCTP stream too, again making sure the message sequencing needs of the signalling application are met 🦋. DATA messages MUST be sent on an SCTP stream other than stream '0' 🙅♀️.
When there's no Routing Key match, or only a partial match, for an incoming SS7 message, a default treatment MAY be specified 🌸. The options are: have a default Application Server at the SGP that sends all unallocated traffic to a (set of) default ASP(s), or drop the message and notify Layer Management with an M-ERROR indication primitive 🧚♀️. How unallocated traffic gets treated is up to the implementation 💜.
4.2 Receipt of Primitives from the Layer Management 🎀
when Layer Management sends primitives, the M3UA layer takes the requested action and sends back an appropriate response primitive to Layer Management 💖.
An M-SCTP_ESTABLISH request primitive from Layer Management at an ASP or IPSP kicks off the establishment of an SCTP association 🚪. The M3UA layer tries to set up an SCTP association with the remote M3UA peer by sending an SCTP-ASSOCIATE primitive to the local SCTP layer 🤝.
once an SCTP association is successfully up, SCTP sends an SCTP-COMMUNICATION_UP notification primitive to the local M3UA layer 🎉. At the SGP or IPSP that started the request, the M3UA layer sends an M-SCTP_ESTABLISH confirm primitive to Layer Management when setup is done ✅. At the peer M3UA layer, an M-SCTP_ESTABLISH indication primitive goes up to Layer Management after an incoming SCTP association setup succeeds 📥.
An M-SCTP_RELEASE request primitive from Layer Management starts the teardown of an SCTP association 🧹. The M3UA layer does a graceful shutdown by sending an SCTP-SHUTDOWN primitive to the SCTP layer 🌙.
when the graceful shutdown is finished, the SCTP layer sends an SCTP-SHUTDOWN_COMPLETE notification primitive to the local M3UA layer 🏁. At the M3UA layer that started the request, the M3UA layer sends an M-SCTP_RELEASE confirm primitive to Layer Management once shutdown is complete 💌. At the peer M3UA layer, an M-SCTP_RELEASE indication primitive goes up to Layer Management after an abort or a successful shutdown of an SCTP association 👋.
An M-SCTP_STATUS request primitive lets Layer Management check the local status of a particular SCTP association 🔍. The M3UA layer just maps the M-SCTP_STATUS request to an SCTP-STATUS primitive for the SCTP layer 🪞. When SCTP responds, the M3UA layer maps the association status info to an M-SCTP_STATUS confirm primitive. No peer protocol gets involved here 🙅♀️.
Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-to-LM primitive mappings can be described for the other SCTP Upper Layer primitives in RFC2960 [17], like INITIALIZE, SET PRIMARY, CHANGE HEARTBEAT, REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, SET PROTOCOL PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, AND NETWORK STATUS CHANGE 📚. Or, if you prefer, those SCTP Upper Layer primitives (and Status too) can be modeled as a Layer Management interaction directly with the SCTP Layer 🧩.
M-NOTIFY indication and M-ERROR indication primitives tell Layer Management about the notification or error info in a received M3UA Notify or Error message, respectively 🔔. These indications can also be generated from local M3UA events ⚡.
An M-ASP_STATUS request primitive lets Layer Management check the status of a particular local or remote ASP 🔎. The M3UA layer answers with the status in an M-ASP_STATUS confirm primitive. No M3UA peer protocol is invoked 🙃.
An M-AS_STATUS request lets Layer Management check the status of a particular AS 📊. The M3UA layer responds with an M-AS_STATUS confirm primitive. No M3UA peer protocol is invoked 💤.
M-ASP_UP request, M-ASP_DOWN request, M-ASP_ACTIVE request and M-ASP_INACTIVE request primitives let Layer Management at an ASP start state changes 🚦. After a successful completion, the M3UA layer gives Layer Management a matching confirm primitive ✔️. If an invocation fails, an Error indication primitive is provided in the primitive 😬. These requests result in outgoing ASP Up, ASP Down, ASP Active and ASP Inactive messages to the remote M3UA peer at an SGP or IPSP 📤.
4.2.1 Receipt of M3UA Peer Management Messages
after state changes succeed because of ASP Up, ASP Down, ASP Active and ASP Inactive messages from a peer M3UA, the M3UA layer MAY invoke the matching M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE and M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-AS_DOWN indication primitives up to Layer Management 🌟.
M-NOTIFY indication and M-ERROR indication primitives tell Layer Management about the notification or error info in a received M3UA Notify or Error message 💌. These indications can also be generated from local M3UA events 🎯.
All non-Transfer and non-SSNM messages, except BEAT and BEAT Ack, SHOULD be sent with sequenced delivery so the ordering stays intact 📏. ASPTM messages MAY be sent on one of the streams that carries the data traffic for the Routing Context(s), which helps minimize possible message loss 🛟. BEAT and BEAT Ack messages MAY be sent using out-of-order delivery, and MAY be sent on any stream 🦄✨
4.3 AS and ASP State Maintenance 💖
Okay so the M3UA layer on the SGP keeps track of the state of each remote ASP, in each Application Server that the ASP is configured to receive traffic for 🎀. It uses that info as input to the M3UA message distribution function. Same energy where IPSPs use M3UA point-to-point: the M3UA layer in an IPSP keeps tabs on the state of remote IPSPs 🦋. For these procedures we only describe the SGP/ASP case, but the SGP side also applies to an IPSP sending traffic to an AS made up of a set of remote IPSPs ✨.
4.3.1 ASP States
The state of each remote ASP, in each AS it's configured to operate in, lives in the M3UA layer on the SGP 👑. A particular ASP's state in a particular AS changes because of events, and those events include:
- Reception of messages from the peer M3UA layer at the ASP;
- Reception of some messages from the peer M3UA layer at other ASPs in the AS (e.g., ASP Active message indicating "Override");
- Reception of indications from the SCTP layer; or
- Local Management intervention.
The ASP state transition diagram is shown in Figure 3 🌈. The possible states of an ASP are:
ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the related SCTP association is down 💀. Every ASP starts out in this state. An ASP in this state SHOULD NOT be sent any M3UA messages, except for Heartbeat, ASP Down Ack and Error messages.ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the related SCTP association is up) but application traffic is stopped 🌸. In this state the ASP SHOULD NOT be sent any DATA or SSNM messages for the AS for which the ASP is inactive.ASP-ACTIVE: The remote M3UA peer at the ASP is available and application traffic is active (for a particular Routing Context or set of Routing Contexts) 🔥.
SCTP CDI denotes the local SCTP layer's Communication Down Indication to the Upper Layer Protocol (M3UA) on an SGP. The local SCTP layer sends this indication when it detects the loss of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood as either a SHUTDOWN_COMPLETE notification or a COMMUNICATION_LOST notification from the SCTP layer.
SCTP RI is the local SCTP layer's Restart indication to the upper layer protocol (M3UA) on an SG. The local SCTP sends this indication when it detects a restart from the ASP's peer SCTP layer 🧚.
Figure 3: ASP State Transition Diagram, per AS
+--------------+
| |
+----------------------| ASP-ACTIVE |
| Other +-------| |
| ASP in AS | +--------------+
| Overrides | ^ |
| | ASP | | ASP
| | Active | | Inactive
| | | v
| | +--------------+
| | | |
| +------>| ASP-INACTIVE |
| +--------------+
| ^ |
ASP Down/ | ASP | | ASP Down /
SCTP CDI/ | Up | | SCTP CDI/
SCTP RI | | v SCTP RI
| +--------------+
| | |
+--------------------->| ASP-DOWN |
| |
+--------------+4.3.2 AS States
The state of the AS is maintained in the M3UA layer on the SGPs 🌟. An AS's state changes because of events, and these events include:
- ASP state transitions
- Recovery timer triggers
The possible states of an AS are:
AS-DOWN: The Application Server is unavailable 🙈. This state implies that all related ASPs are in the ASP-DOWN state for this AS. Initially the AS is in this state. An Application Server is in the AS-DOWN state when it is removed from a configuration.AS-INACTIVE: The Application Server is available but no application traffic is active (i.e., one or more related ASPs are in the ASP-INACTIVE state, but none in the ASP-ACTIVE state). The recovery timer T(r) is not running or has expired.AS-ACTIVE: The Application Server is available and application traffic is active. This state implies that at least one ASP is in the ASP-ACTIVE state 💜.AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP-DOWN, and it was the last remaining active ASP in the AS. A recovery timer T(r) SHOULD be started and all incoming signalling messages SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the AS-ACTIVE state and all the queued messages are sent to the ASP 🫶.
If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no alternative, the SGP may stop queuing messages and discard all previously queued messages. The AS will move to the AS-INACTIVE state.
If at least one ASP is in ASP-INACTIVE state, otherwise it will move to AS-DOWN state.
Figure 4 shows an example AS state machine for the case where the AS/ASP data is preconfigured. For other cases where the AS/ASP configuration data is created dynamically, there would be differences in the state machine, especially at creation of the AS 🎀.
Figure 4: AS State Transition Diagram
+----------+ one ASP trans to ACTIVE +-------------+
| AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE |
| |<--- | |
+----------+ \ +-------------+
^ | \ Tr Expiry, ^ |
| | \ at least one | |
| | \ ASP in ASP-INACTIVE | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | all ASP \ one ASP | | Last ACTIVE
trans | | trans to \ trans to | | ASP trans to
to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE
ASP- | | \ ACTIVE | | or ASP-DOWN
INACTIVE| | \ | | (start Tr)
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | --| |
| AS-DOWN | | AS-PENDING |
| | | (queuing) |
| |<----------------------------| |
+----------+ Tr Expiry and no ASP +-------------+
in ASP-INACTIVE state)
Tr = Recovery TimerFor example, where the AS/ASP configuration data is not created until Registration of the first ASP, the AS-INACTIVE state is entered directly upon the first successful REG REQ from an ASP 🧁. Another example is where the AS/ASP configuration data is not created until the first ASP successfully enters the ASP-ACTIVE state. In this case the AS-ACTIVE state is entered directly 👑.
4.3.3 M3UA Management Procedures for Primitives
Before the establishment of an SCTP association, the ASP state at both the SGP and ASP is assumed to be in the state ASP-DOWN 🌙.
Once the SCTP association is established (see Section 4.2) and assuming that the local M3UA-User is ready, the local M3UA ASP Maintenance (ASPM) function initiates the relevant procedures. It uses the ASP Up/ASP Down/ASP Active/ASP Inactive messages to convey the ASP state to the SGP (see Section 4.3.4) 💅.
If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or SCTP-RESTART indication primitive from the underlying SCTP layer, it informs Layer Management by invoking the M-SCTP_STATUS indication primitive. The state of the ASP is moved to ASP-DOWN. At an ASP, the MTP3-User is informed of the unavailability of any affected SS7 destinations through the use of MTP-PAUSE indication primitives 😭.
In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re-establish the SCTP Association. This MAY be done by the M3UA layer automatically, or Layer Management MAY re-establish using the M-SCTP_ESTABLISH request primitive 🔁.
In the case of an SCTP-RESTART indication at an ASP, the ASP is now considered by its M3UA peer to be in the ASP-DOWN state. The ASP, if it is to recover, must begin any recovery with the ASP-Up procedure. 🚨
4.3.4 ASPM Procedures for Peer-to-Peer Messages
4.3.4.1 ASP Up Procedures
okay so after an ASP has successfully set up an SCTP association to an SGP, the SGP just waits 👀 for the ASP to send an ASP Up message, which basically says "hey bestie, I'm here and my M3UA peer is available" 🦋. The ASP is always the one who starts the ASP Up message 💅. This can get kicked off by an M-ASP_UP request primitive from Layer Management, or an M3UA management function can start it automatically. Both options are totally allowed, so pick your vibe ✨. This action MAY be initiated at the ASP by an M-ASP_UP request primitive from Layer Management or MAY be initiated automatically by an M3UA management function.
when an ASP Up message shows up at an SGP and, internally, the remote ASP is in the ASP-DOWN state and isn't locked out for local management reasons, the SGP marks that ASP as ASP-INACTIVE and tells Layer Management with an M-ASP_Up indication primitive 🎀. if the SGP knows from current configuration data which Application Servers the ASP is set up to operate in, it updates the ASP state to ASP-INACTIVE in each AS that it's a member of 🫶.
Alternatively, the SGP may move the ASP into a pool of Inactive ASPs that are available for future configuration within Application Server(s), which gets decided in a later Registration Request or ASP Active procedure 🧚. if the ASP Up message contains an ASP Identifier, the SGP should save the ASP Identifier for that ASP. The SGP MUST send an ASP Up Ack message in response to a received ASP Up message, even if the ASP is already marked as ASP-INACTIVE at the SGP. no exceptions, periodt 💅.
if for any local reason (e.g., management lockout) the SGP cannot respond with an ASP Up Ack message, it responds to the ASP Up message with an Error message with the reason "Refused - Management Blocking" 🙈.
at the ASP, the ASP Up Ack message it receives is not acknowledged. Layer Management gets informed with an M-ASP_UP confirm primitive ✨.
when the ASP sends an ASP Up message, it starts timer T(ack). if the ASP doesn't get a response to its ASP Up message within T(ack), the ASP MAY restart T(ack) and resend ASP Up messages until it gets an ASP Up Ack message 🔁. T(ack) is provisionable, with a default of 2 seconds ⏱️. Alternatively, retransmission of ASP Up messages MAY be put under control of Layer Management. In that method, expiry of T(ack) results in an M-ASP_UP confirm primitive carrying a negative indication 😭.
the ASP must wait for the ASP Up Ack message before sending any other M3UA messages (e.g., ASP Active or REG REQ) 🛑. if the SGP receives any other M3UA messages before an ASP Up message is received (other than ASP Down, see Section 4.3.4.2), the SGP MAY discard them 🗑️.
if an ASP Up message is received and, internally, the remote ASP is in the ASP-ACTIVE state, an ASP Up Ack message gets returned, and an Error message ("Unexpected Message) shows up too. The remote ASP state then changes to ASP-INACTIVE in all relevant Application Servers 💀.
if an ASP Up message is received and, internally, the remote ASP is already in the ASP-INACTIVE state, an ASP Up Ack message is returned and that's it, no further action is taken 💖.
4.3.4.1.1 M3UA Version Control
if an ASP Up message with an unsupported version is received, the receiving end responds with an Error message. That message indicates the version the receiving node supports, and it notifies Layer Management 🌈.
this is super useful when protocol version upgrades are happening across a network 🍓. a node that's been upgraded to a newer version should support the older versions that are used on the other nodes it's talking to. Because ASPs are the ones who initiate the ASP Up procedure, it's assumed that the Error message would normally come from the SGP 🫶.
4.3.4.1.2 IPSP Considerations (ASP Up)
an IPSP may be considered in the ASP-INACTIVE state after an ASP Up or ASP Up Ack has been received from it. An IPSP can be considered in the ASP-DOWN state after an ASP Down or ASP Down Ack has been received from it. The IPSP may inform Layer Management of the change in state of the remote IPSP using M-ASP_UP or M-ASP_DN indication or confirmation primitives 🦋.
Alternatively, an interchange of ASP Up messages from each end can be performed. This option follows the ASP state transition diagram, and it would need four messages to complete 🔥.
if for any local reason (e.g., management lockout) an IPSP cannot respond to an ASP Up message with an ASP Up Ack message, it responds to that ASP Up message with an Error message with the reason "Refused Management Blocking" and leaves the remote IPSP in the ASP-DOWN state 🙈.
4.3.4.2 ASP-Down Procedures
the ASP will send an ASP Down message to an SGP when it wants to be removed from service in all the Application Servers it's a member of, and when it no longer wants to receive any DATA, SSNM or ASPTM messages 👋. This action MAY be initiated at the ASP by an M-ASP_DOWN request primitive from Layer Management, or MAY be initiated automatically by an M3UA management function 🧚.
whether the ASP is permanently removed from any AS is a matter of configuration management 🎀. In the case where the ASP previously used the Registration procedures (see Section 4.4.1) to register within Application Servers, but it hasn't deregistered from all of them before sending the ASP Down message, the SGP MUST consider the ASP as Deregistered in every Application Server it's still a member of. That's a must, bestie 💅.
the SGP marks the ASP as ASP-DOWN, informs Layer Management with an M-ASP_Down indication primitive, and returns an ASP Down Ack message to the ASP ✨.
The SGP MUST send an ASP Down Ack message in response to a received ASP Down message from the ASP, even if the ASP is already marked as ASP-DOWN at the SGP 🫶.
at the ASP, the ASP Down Ack message it receives is not acknowledged. Layer Management gets informed with an M-ASP_DOWN confirm primitive. if the ASP receives an ASP Down Ack without having sent an ASP Down message, the ASP should now consider itself to be in the ASP-DOWN state 🌸.
if the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state, the ASP should then initiate procedures to return itself to its previous state 🔁.
when the ASP sends an ASP Down message, it starts timer T(ack). if the ASP doesn't receive a response to its ASP Down message within T(ack), the ASP MAY restart T(ack) and resend ASP Down messages until it receives an ASP Down Ack message ⏱️. T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Down messages MAY be put under control of Layer Management. In that method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a negative indication 😭💜
4.3.4.3 ASP Active Procedures 💖
Okay bestie, so once the ASP gets an ASP Up Ack from the SGP or IPSP, it's finally allowed to say "I'm ready to work!" 💅 That's the ASP Active message. The ASP MAY send it whenever it wants after that Ack. Layer Management can kick it off with an M-ASP_ACTIVE request primitive, or an M3UA management function can send it automatically 🦋
If the ASP wants to handle traffic for more than one Application Server over the same SCTP association, the ASP Active message(s) SHOULD carry a list of one or more Routing Contexts so everyone knows which Application Servers it's talking about 🎀 The ASP doesn't have to shove every Routing Context into one message, though. It can ask to go active in all of them at once, or split them up. Multiple ASP Active messages MAY be used to activate the Application Servers one at a time or in little groups 🌸 And if an ASP Active message has no Routing Context parameter at all, the receiver has to already know which Application Server(s) the ASP belongs to, from configuration data. No guessing allowed! 🧚
For every Application Server the ASP can actually activate, the SGP or IPSP sends back one or more ASP Active Ack messages with the Routing Context(s) included, and it reflects any Traffic Mode Type value from the ASP Active message 💜 The Routing Context parameter MUST be included in the ASP Active Ack message(s) if the received ASP Active message had any Routing Contexts. Then the SGP moves the ASP into the right ASP traffic state inside the Application Server(s). It uses the Traffic Mode Type request if there is one, or local configuration data if there isn't. Layer Management gets an M-ASP_Active indication too ✨ If the SGP or IPSP gets any Data messages before an ASP Active message shows up, it MAY throw them away 🙈 Once the SGP or IPSP sends the ASP Active Ack, it's officially ready to send and receive traffic for those Routing Contexts. The ASP SHOULD NOT send Data or SSNM messages for the related Routing Context(s) until it gets that ASP Active Ack, or it risks losing messages. Not a vibe 😭
Multiple ASP Active Ack messages MAY be used to answer an ASP Active message with several Routing Contexts, so the SGP or IPSP can acknowledge different (sets of) Routing Contexts on their own schedule 🌈 If the ASP can't be activated for a given Routing Context value, the SGP or IPSP MUST send an Error message (Invalid Routing Context) for each one of those values. Iconic error handling, honestly 👑
Now, if an "out-of-the-blue" ASP Active message shows up (so the ASP never registered with the SG, or the SG has no static configuration for it), the message MAY be silently discarded. Ghosted 💀
The SGP MUST send an ASP Active Ack message back to the ASP whenever it gets an ASP Active message from that ASP and the ASP is already marked ASP-ACTIVE at the SGP. Obsessed with this rule ngl 🫶
Over at the ASP, the ASP Active Ack it receives doesn't get acknowledged in return. Layer Management gets an M-ASP_ACTIVE confirm primitive instead 🍓 It's totally possible for the ASP to get Data message(s) before the ASP Active Ack, since those two can travel on different SCTP streams. Message loss can happen too, because the ASP doesn't count itself as ASP-ACTIVE until it actually receives the ASP Active Ack. Plan around it, bestie 💅
When the ASP sends an ASP Active message, it starts timer T(ack). If no response shows up within T(ack), the ASP MAY restart T(ack) and resend the ASP Active messages until it gets an ASP Active Ack. T(ack) is provisionable, and the default is 2 seconds ⏰ Or, if you want, retransmission of ASP Active messages MAY be handed over to Layer Management. In that case, when T(ack) expires, Layer Management gets an M-ASP_ACTIVE confirm primitive with a negative indication 🎀
There are three modes of Application Server traffic handling in the SGP M3UA layer: Override, Loadshare and Broadcast 🌸 When it's included, the Traffic Mode Type parameter in the ASP Active message says which mode the Application Server should use. If the SGP decides the requested mode is unsupported or doesn't match the mode already configured for the AS, it answers with an Error message (Unsupported / Invalid Traffic Handling Mode) 🙅♀️ If the traffic handling mode isn't already known from configuration data, the mode from the first ASP Active message that moves the Application Server into AS-ACTIVE MAY be used to set it. Main character energy for that first ASP 👑
In Override mode, when the SGP gets an ASP Active message, it redirects all of the AS's traffic to the ASP that sent it ✨ Any ASP that was active before is now ASP-INACTIVE and SHOULD stop receiving traffic from the SGP within the AS. Then the SGP or IPSP MUST send a Notify message (Alternate ASP_Active) to the previously active ASP and SHOULD stop traffic to and from that ASP. The ASP that gets this Notify MUST consider itself ASP-INACTIVE now, unless it already knows that from talking to the Overriding ASP. Bye bye, old ASP 🦋
In Loadshare mode, when an SGP or IPSP gets an ASP Active message, it starts sending traffic to the ASP that sent the message, plus all the other ASPs that are already active in the AS 🌈 How the SGP balances the load across the active ASPs is implementation dependent. It could be round-robin, for example, or it could look at info in the Data message, like the SLS, SCCP SSN, or ISUP CIC value 🧚
When an SGP or IPSP gets the ASP Active message for the first ASP in a Loadshare AS, it MAY decide not to send traffic to that new ASP until it's sure there are enough resources for the expected load. For example, it could wait until there are "n" ASPs in state ASP-ACTIVE in the AS. In that case, the SGP or IPSP SHOULD hold back the Notify (AS-ACTIVE) until those resources are ready 💜
For the n+k redundancy case, the ASPs in that AS should work out among themselves how many of them are active, and they should only start sending traffic once n ASPs are active 🫶
Every ASP in a loadsharing mode AS must be able to process any Data message received for that AS, so the traffic can failover or rebalance without anyone panicking 🔥
In Broadcast mode, when an SGP or IPSP gets an ASP Active message, it starts sending traffic to the ASP that sent it, plus all the other ASPs already active in the AS 🍓 The SGP's broadcasting algorithm is simple: every message goes to each of the active ASPs. Very democratic 🌸
Same deal as Loadshare here: when an SGP or IPSP gets the ASP Active message for the first ASP in a Broadcast AS, it MAY decide not to send traffic to that new ASP until there are enough resources for the expected load (like "n" ASPs in state ASP-ACTIVE in the AS). In that case, the SGP or IPSP SHOULD hold back the Notify (AS-ACTIVE) until the resources are sufficient ✨
And for n+k redundancy again, the ASPs in that AS should coordinate how many of them are active, and they should only start sending traffic once n ASPs are active 🎀
Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP MUST tag the first DATA message broadcast in each traffic flow with a unique Correlation Id parameter. The point of that Id is to let the newly active ASP sync up its processing of each traffic flow with the other ASPs in the broadcast group 🧚💖
4.3.4.3.1 IPSP Considerations (ASP Active) 🌈
Either IPSP can start the communication 🫶 When an IPSP gets an ASP Active, it should mark the peer as ASP-ACTIVE and send back an ASP Active Ack message. An ASP that receives an ASP Active Ack message may mark the peer as ASP-Active, as long as it isn't already in the ASP-ACTIVE state 🔥
There's also another option: both ends can send each other ASP Active messages. This follows the ASP state transition diagram, and it's extra nice because each end gets to pick a particular AS to activate. That's super useful when an IPSP is serving more than one AS 💅 Just know it takes four messages to finish 😭
4.3.4.4 ASP Inactive Procedures ⏸️
Okay so when an ASP wants to step back from getting traffic within an AS 💅, it sends an ASP Inactive message to the SGP or IPSP. This action MAY be initiated at the ASP by an M-ASP_INACTIVE request primitive from Layer Management or MAY be initiated automatically by an M3UA management function. 🎀 If an ASP is handling traffic for more than one Application Server over one shared SCTP association, the ASP Inactive message carries one or more Routing Contexts to say which Application Servers it's talking about. 🧚
If an ASP Inactive message has no Routing Context parameter, the receiver must know, through configuration data, which Application Servers the ASP belongs to, and then move the ASP to the ASP-INACTIVE state in all of them. 💜 In Override mode, if another ASP already took over the traffic in the AS with an ASP Active ("Override") message, the ASP that sends the ASP Inactive message is already seen by the SGP as being in ASP-INACTIVE. 🦋 An ASP Inactive Ack message goes back to the ASP once all traffic to it has been stopped. 🫶
In Loadshare mode, the SGP moves the ASP to ASP-INACTIVE and the AS traffic gets reallocated across the remaining ASP-ACTIVE ASPs, following whatever loadsharing algorithm the AS is using. ✨ A Notify message ("Insufficient ASP resources active in AS") MAY be sent to all inactive ASPs, if required. 😭 An ASP Inactive Ack message goes to the ASP after all traffic is halted and Layer Management gets told with an M-ASP_INACTIVE indication primitive. 💅
In Broadcast mode, the SGP moves the ASP to ASP-INACTIVE and the AS traffic is broadcast only to the remaining ASP-ACTIVE ASPs. 🌈 A Notify message ("Insufficient ASP resources active in AS") MAY be sent to all inactive ASPs, if required. An ASP Inactive Ack message goes to the ASP after all traffic is halted and Layer Management is informed with an M-ASP_INACTIVE indication primitive. 🍓
Multiple ASP Inactive Ack messages MAY be used in reply to an ASP Inactive message that has multiple Routing Contexts, so the SGP or IPSP can acknowledge different sets of Routing Contexts independently. 🔥 The SGP or IPSP sends an Error message ("Invalid Routing Context") for every invalid or unconfigured Routing Context value in a received ASP Inactive message. 🙈
The SGP MUST send an ASP Inactive Ack message in response to a received ASP Inactive message from the ASP when the ASP is already marked as ASP-INACTIVE at the SGP. 👑
At the ASP, the received ASP Inactive Ack message is not acknowledged. Layer Management gets an M-ASP_INACTIVE confirm primitive. If the ASP receives an ASP Inactive Ack without having sent an ASP Inactive message, the ASP should now consider itself to be in the ASP-INACTIVE state. If the ASP was previously in the ASP-ACTIVE state, the ASP should then start the procedures to return itself to its previous state. 🌸
When the ASP sends an ASP Inactive message, it starts timer T(ack). If the ASP doesn't get a response to that ASP Inactive message within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive messages until it gets an ASP Inactive Ack message. 🥺 T(ack) is provisionable, with a default of 2 seconds. Alternatively, retransmission of ASP Inactive messages MAY be put under control of Layer Management. In that method, expiry of T(ack) results in an M-ASP_Inactive confirm primitive carrying a negative indication. 💀
If no other ASPs in the Application Server are in the state ASP-ACTIVE, the SGP MUST send a Notify message ("AS-Pending") to all of the ASPs in the AS that are in the state ASP-INACTIVE. 🚨 The SGP SHOULD start buffering the incoming messages for T(r) seconds, after which messages MAY be discarded. T(r) is configurable by the network operator. 🧁 If the SGP gets an ASP Active message from an ASP in the AS before T(r) expires, the buffered traffic is directed to that ASP and the timer is cancelled. If T(r) expires, the AS moves to the AS-INACTIVE state. 🫧
4.3.4.4.1 IPSP Considerations (ASP Inactive) 🤝
An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP after an ASP Inactive or ASP Inactive Ack message has been received from it. 💫
Alternatively, an interchange of ASP Inactive messages can be performed from each end. This option follows the ASP state transition diagram and has the extra perk of letting each end pick a particular AS to deactivate. 💖 It's especially useful when an IPSP is serving more than one AS. It would need four messages to complete. 📦
4.3.4.5 Notify Procedures 📣
A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. 🎯 At the ASP, Layer Management is informed with an M-NOTIFY indication primitive. The Notify message must be sent whether the AS state change was caused by an ASP failure or by reception of an ASP State management (ASPSM) / ASP Traffic Management (ASPTM) message. 🌟 In the second case, the Notify message MUST be sent after any related acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack). 🎀
When a Notify message ("AS-PENDING") is sent by an SGP that now has no ASPs active to service the traffic, or when a Notify ("Insufficient ASP resources active in AS") message is sent in Loadshare or Broadcast mode, the Notify message does not explicitly compel the ASP(s) that receive it to become active. The ASPs stay in control of what traffic action is taken, and when. 🧠
If a Notify message doesn't contain a Routing Context parameter, the receiver must know, through configuration data, which Application Servers the ASP is a member of and take the appropriate action in each AS. 🗂️
4.3.4.5.1 IPSP Considerations (NTFY) 🛰️
Notify works the same way as in the SG-AS case. One of the IPSPs can send this message to any remote IPSP that is not in the ASP-DOWN state. 🦋
4.3.4.6 Heartbeat Procedures 💓
The optional Heartbeat procedures MAY be used when operating over transport layers that don't have their own heartbeat mechanism for detecting loss of the transport association (i.e., other than SCTP). 🫶
Either M3UA peer may optionally send Heartbeat messages periodically, subject to a provisionable timer T(beat). Upon receiving a Heartbeat message, the M3UA peer MUST respond with a Heartbeat Ack message. 💅
If no Heartbeat Ack message (or any other M3UA message) is received from the M3UA peer within 2*T(beat), the remote M3UA peer is considered unavailable. Transmission of Heartbeat messages stops, and the signalling process SHOULD attempt to re-establish communication if it is configured as the client for the disconnected M3UA peer. 😭
The Heartbeat message may optionally contain an opaque Heartbeat Data parameter that MUST be echoed back unchanged in the related Heartbeat Ack message. The sender, when examining the contents of the returned Heartbeat Ack message, MAY choose to consider the remote M3UA peer as unavailable. 🧁 The contents and format of the Heartbeat Data parameter are implementation-dependent and only of local interest to the original sender. The contents may be used, for example, to support a Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a timestamp mechanism (to evaluate delays). ⏱️
Note: Heartbeat related events are not shown in Figure 3 "ASP state transition diagram". 📝
4.4 Routing Key Management Procedures [Optional] 🔑
4.4.1 Registration ✨
okay so an ASP MAY dynamically register with an SGP as an ASP within an Application Server using the REG REQ message 💖 The Routing Key parameter in that REG REQ message is where all the details about the Routing Key live 🎀
the SGP looks at what's inside the Routing Key parameter and checks it against the Routing Keys it already has provisioned 👀 if the incoming Routing Key matches an existing SGP Routing Key entry, and the ASP isn't already on the list of ASPs for that Application Server, the SGP MAY authorize the ASP to be added to the AS 💅 or, if the Routing Key doesn't exist yet but the data is valid and unique, an SGP that supports dynamic configuration MAY authorize making a brand new Routing Key and Application Server and adding the ASP to that new AS 🧚 either way, the SGP sends a Registration Response message back to the ASP with the same Local-RK-Identifier that came in the first request, plus a Registration Result of "Successfully Registered" ✨ a unique Routing Context value gets assigned to the SGP Routing Key and included too 🦋 how the SGP picks that Routing Context value is up to the implementation, but it must be guaranteed to be unique for each Application Server or Routing Key the SGP supports 🔒
if the SGP doesn't support the registration procedure at all, it sends an Error message back to the ASP with the error code "Unsupported Message Type" 🙈
if the SGP decides the Routing Key data is invalid, or has invalid parameter values, it returns a Registration Response message with a Registration Result of "Error Invalid Routing Key", "Error - Invalid DPC", or "Error - Invalid Network Appearance", whichever fits 💀
if the SGP decides a unique Routing Key can't be created, it returns a Registration Response message with a Registration Status of "Error - "Cannot Support Unique Routing" 😭 and an incoming signalling message received at an SGP should not match against more than one Routing Key 🫶
if the SGP doesn't authorize an otherwise valid registration request, it sends a REG RSP message back to the ASP with the Registration Result "Error - Permission Denied" 🚫
if the SGP finds that a received Routing Key doesn't currently exist and the SGP doesn't support dynamic configuration, it returns a Registration Response message with a Registration Result of "Error - Routing Key not Currently Provisioned" 🥀
if the SGP finds that a received Routing Key doesn't currently exist, the SGP supports dynamic configuration, but it doesn't have the capacity to add new Routing Key and Application Server entries, it returns a Registration Response message with a Registration Result of "Error - Insufficient Resources" 🍓
if the SGP decides one or more of the Routing Key parameters aren't supported for creating new Routing Key entries, it returns a Registration Response message with a Registration Result of "Error - Unsupported RK parameter field" 🌸 this result MAY be used if, for example, the SGP doesn't support RK Circuit Range Lists in a Routing Key because it doesn't support ISUP traffic, or because it doesn't provide CIC range granularity 📞
a Registration Response with "Error - Unsupported Traffic Handling Mode" comes back if the Routing Key in the REG REQ has a Traffic Handling Mode that doesn't match the mode currently configured for the matching Application Server 🎀
an ASP MAY register multiple Routing Keys at once by putting a bunch of Routing Key parameters into a single REG REQ message 🌈 the SGP MAY answer each registration request in one REG RSP message, giving the success or failure result for each Routing Key in its own Registration Result parameter 💜 or, the SGP MAY instead send several REG RSP messages, each carrying one or more Registration Result parameters 🦋 the ASP uses the Local-RK-Identifier parameter to match up requests and responses 🧩
once an ASP is successfully registered in an AS, the SGP can now send related SS7 Signalling Network Management messaging, if that didn't already start when the ASP moved to the ASP-INACTIVE state ✨
4.4.2 Deregistration 🫧
an ASP MAY dynamically deregister with an SGP as an ASP within an Application Server using the DEREG REQ message 💫 a Routing Context parameter in the DEREG REQ message says which Routing Keys to deregister 🗝️ an ASP SHOULD move to the ASP-INACTIVE state for an Application Server before it tries to deregister the Routing Key (so, deregister after you get an ASP Inactive Ack) 🌷 also, an ASP SHOULD deregister from every Application Server it's a member of before trying to move to the ASP-Down state 🙌
the SGP looks at the Routing Context parameter and checks that the ASP is actually registered in the Application Server(s) tied to the included Routing Context(s) 🔍 if that checks out, the ASP gets deregistered as an ASP in those Application Servers 👋
deregistering doesn't automatically mean the Routing Key and Application Server config gets deleted at the SG 🧠 other ASPs might still be associated with the Application Server, in which case the Routing Key data SHOULD NOT be deleted 🫶 but if a deregistration leaves an Application Server with no ASPs at all, an SG MAY delete the Routing Key data 🗑️
the SGP acknowledges the deregistration request by sending a DEREG RSP message back to the requesting ASP 💌 the result lives in the Deregistration Result parameter, which says success or failure, plus the cause 💅
an ASP MAY deregister multiple Routing Contexts at once by putting several Routing Contexts into a single DEREG REQ message 🌟 the SGP MAY respond to each deregistration request in a single DEREG RSP message, giving the success or failure result for each Routing Context in its own Deregistration Result parameter 🎀
4.4.3 IPSP Considerations (REG/DEREG) 🦋
the Registration and Deregistration procedures work for IPSP cases in the exact same way as they do for AS-SG cases 🤝 an IPSP may register an RK in the remote IPSP 🌸 and an IPSP is responsible for deregistering the RKs that it has registered 🫡
4.5 Procedures to Support the Availability or Congestion Status of SS7 Destination 🚦
4.5.1 At an SGP 📡
when an SGP gets an MTP-PAUSE, MTP-RESUME, or MTP-STATUS indication primitive from the nodal interworking function, the SGP M3UA layer sends a matching SS7 Signalling Network Management (SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4) to the M3UA peers at the concerned ASPs 💌 the M3UA layer has to fill in the various fields of the SSNM messages consistently with what the primitives said 🧾
the SGP M3UA layer works out which concerned ASPs need to be told based on the specific SS7 network the primitive is relevant to 🗺️ that way, every ASP configured to send or receive traffic within a particular network appearance gets informed 🙌 and if the SGP runs inside just one SS7 network appearance, then all ASPs get informed 🌈
DUNA, DAVA, SCON, and DRST messages may be sent one after another and processed by the receiver in the order they were sent 🔁
sequencing isn't required for DUPU or DAUD messages, which MAY be sent unsequenced 🎲
4.5.2 At an ASP 🧚
4.5.2.1 Single SG Configurations 💫
at an ASP, when it gets an SS7 Signalling Network Management (SSNM) message from the remote M3UA Peer, the M3UA layer invokes the matching primitive indications for the resident M3UA-Users 🎀 local management gets informed too 🧠
if a local event causes SS7 destinations to become unavailable or congested, the M3UA layer at the ASP SHOULD pass up the appropriate indications in the primitives to the M3UA User, just like it would if equivalent SSNM messages had arrived 🫶 for example, losing an SCTP association to an SGP might make a set of SS7 destinations unavailable 😬 in that case, MTP-PAUSE indication primitives to the M3UA User are the right move 💜
4.5.2.2 Multiple SG Configurations 🌐
at an ASP, when it gets a Signalling Network Management message from the remote M3UA Peer, the M3UA layer updates the status of the affected route(s) via the originating SG 🛤️ then it figures out whether the overall availability or congestion status of the affected destination(s) has changed 🔍 if it has, the M3UA layer invokes the appropriate primitive indications to the resident M3UA-Users, and local management gets informed 📣
Implementation Note: To accomplish this, the M3UA layer at an ASP maintains the status of routes via the SG, much like an MTP3 layer maintains route-set status. 🧩
4.5.3 ASP Auditing ✨
okay so an ASP can optionally ask the SGP what's up with an SS7 destination (or a whole bunch of them) 🔍. It's basically the "hey, are you still alive over there?" text 💬. The ASP sends a Destination Audit (DAUD) message to the SGP asking for the current availability and, if the national congestion method with multiple congestion levels and message priorities is in use, the congestion status of one or more SS7 Destination Point Codes. 💖
The DAUD message MAY be sent unsequenced. The DAUD MAY be sent by the ASP in these situations:
- Periodic. A Timer that got set when the ASP received a
DUNA,SCONorDRSTmessage has run out 😤, and no laterDAVA,DUNA,SCONorDRSTmessage has updated the availability or congestion status of the affected Destination Point Codes. The Timer resets when the ASP sends aDAUD. In this case theDAUDgoes to the SGP that originally sent theSSNMmessage. ⏰ - Isolation. The ASP is newly ASP-ACTIVE, or it has been cut off from an SGP for a long time 🥺. The ASP MAY request the availability or congestion status of one or more SS7 destinations it expects to talk to. 🧚
IMPLEMENTATION NOTE: okay this one is important bestie 🚨. In the first case above, the auditing procedure must not be invoked when a received SCON message has a congestion level value of "no congestion" or undefined" (i.e., congestion Level = "0"). 🙅♀️ That's because the value either means congestion is clearing up, or that the ITU MTP3 international congestion method is being used. In the international congestion method, the MTP3 layer at the SGP doesn't keep track of congestion status for any destinations, so the SGP has zero congestion info to send back in response to a DAUD. For that same reason, in the second case above, a DAUD message can't reveal any congested destination(s). 💀
The SGP SHOULD respond to a DAUD message with the MTP3 availability and congested status of the routeset linked to each Destination Point Code in the DAUD message. 📬 The status of each requested SS7 destination comes back in a DUNA message (if unavailable), a DAVA message (if available), or a DRST (if restricted, and only if the SGP supports this feature). 🎀 If the SGP keeps congestion status for the SS7 destination and the destination is congested, the SGP MUST also send an SCON message before the DAVA or DRST message. 🔥 If the SS7 destination is available and congested, the SGP MUST respond with an SCON message and then a DAVA message. If the SS7 destination is restricted and congested, the SGP MUST respond with an SCON message immediately followed by a DRST message. 💅 And if the SGP has no info on the availability status of the SS7 destination, it sends back a DUNA message, because it has no routing info to get traffic to that destination. 😭
Any DUNA or DAVA message sent in response to a DAUD message MAY contain a list of Affected Point Codes. 🌸
An SG MAY refuse to give out the availability or congestion status of a destination if, for example, the ASP isn't authorized to know it. 🙈 The SG MAY respond with an Error Message (Error Code = "Destination Status Unknown"). 🔐
4.6 MTP3 Restart 🔄
So this is the part where the MTP3 in the SG goes through an MTP restart. Event communication SHOULD be handled like this:
When the SG finds out that the SS7 network is isolated, the SGPs send an indication to every concerned available ASP (meaning ASPs in the ASP-ACTIVE state) using DUNA messages for the concerned destinations. 📣
When the SG finishes the MTP Restart procedure, the M3UA layers at the SGPs tell all concerned ASPs in the ASP-ACTIVE state about any available or restricted SS7 destinations, using the DAVA/DRST messages. ✨ No message is needed for destinations that are still unavailable after the restart procedure. 🫶
When the M3UA layer at an ASP receives a DUNA message saying an SS7 destination is unavailable at an SG, the MTP Users get an MTP-PAUSE indication and stop sending traffic to that destination. 🛑 When M3UA receives a DAVA/DRST message, the MTP Users get an MTP-RESUME indication and can resume traffic to the newly available SS7 destination, as long as the ASP is in the ASP-ACTIVE state toward this SGP. 🦋
The ASP MAY choose to audit the availability of unavailable destinations by sending DAUD messages. 🕵️♀️ For example, this would happen when an AS becomes active at an ASP and doesn't have current destination statuses. If an MTP restart is in progress at the SG, the SGP returns a DUNA message for that destination, even if it got an indication that the destination became available or restricted. 🙃
In the IPSP case, MTP restart could be considered if the IPSP also has a connection to an SS7 network. 🤔 In that case, the same behavior described above for the SGP would apply to the restarting IPSP. This would also be true if the IPSPs were seen as exchanging MTP Peer PDUs, instead of MTP primitives between the MTP User and MTP Provider. 💜 In other words, M3UA doesn't provide an equivalent to Traffic Restart Allowed messages that signal the end of the restart procedure between peer IPSPs that are also connected to an SS7 network. 🧚♀️
5. Examples of M3UA Procedures 🎀
NOTE: Not all the Notify messages that are appropriate per the Notify procedures are shown in these examples. 📝
5.1 Establishment of Association and Traffic between SGPs and ASPs 🌈
These scenarios show example M3UA message flows for setting up traffic between an SGP and an ASP, or between two IPSPs. 💫 In every case, it's assumed the SCTP association is already set up. 🧦
5.1.1 Single ASP in an Application Server ("1+0" sparing), 🍓
These scenarios show example M3UA message flows for setting up traffic between an SGP and an ASP where only one ASP is configured within an AS (no backup). 🙌
5.1.1.1 Single ASP in Application Server ("1+0" sparing), No Registration 💅
SGP ASP1
| |
|<-------------ASP Up-----------|
|-----------ASP Up Ack--------->|
| |
|<------- ASP Active(RCn)-------| RC: Routing Context
|-----ASP Active Ack (RCn)----->| (optional)
| |
|-----NTFY(AS-ACTIVE)(RCn)----->|
| |Note: If the ASP Active message has an optional Routing Context parameter, the ASP Active message only applies to the specified RC value(s). For an unknown RC value, the SGP responds with an Error message. 🚫
5.1.1.2 Single ASP in Application Server ("1+0" sparing), Dynamic Registration 🌟
This scenario is the same as 5.1.1.1, but with the optional exchange of registration info. 🧠 In this case, the SGP accepts the Registration. 🥳
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
|<----REGISTER REQ(LRCn,RKn)----| LRC: Local Routing
| | Context
|----REGISTER RESP(LRCn,RCn)--->| RK: Routing Key
| | RC: Routing Context
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |
|-----NTFY(AS-ACTIVE)(RCn)----->|
| |Note: If a registration attempt doesn't work (e.g., invalid RKn), the Register Response message will have an unsuccessful indication, and the ASP won't send an ASP Active message after that. 😬
5.1.1.3 Single ASP in Multiple Application Servers (each with "1+0" sparing), Dynamic Registration (Case 1 - Multiple Registration Requests) 🦄
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
|<----REGISTER REQ(LRC1,RK1)----| LRC: Local Routing
| | Context
|----REGISTER RESP(LRC1,RC1)--->| RK: Routing Key
| | RC: Routing Context
| |
|<------- ASP Active(RC1)-------|
|-----ASP Active Ack (RC1)----->|
| |
| |
|<----REGISTER REQ(LRCn,RKn)----|
| |
|----REGISTER RESP(LRCn,RCn)--->|
| |
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |Note: If a registration attempt doesn't work (e.g., invalid RKn), the Register Response message will have an unsuccessful indication, and the ASP won't send an ASP Active message after that. Each LRC/RK pair registration is treated independently. 🧩
It's not necessary to follow a Registration Request/Response pair with an ASP Active message before sending the next Registration Request. ⚡ The ASP Active message can be sent at any time after the related successful registration. 💖
5.1.1.4 Single ASP in Multiple Application Servers (each with "1+0" sparing), Dynamic Registration (Case 2 - Single Registration Request) ✨
okay bestie, this one is one ASP chilling in multiple Application Servers, and each of those has "1+0" sparing (so no backup, just one ASP per AS 💅). Instead of registering each Routing Context one at a time, the ASP sends a single REGISTER REQ with a whole list of LRC/RK pairs. Iconic efficiency 🧚
SGP ASP1
| |
|<------------ASP Up------------|
|----------ASP Up Ack---------->|
| |
|<---REGISTER REQ({LRC1,RK1},---|
| ..., |
| {LRCn,RKn}),--|
| |
|---REGISTER RESP({LRC1,RC1},-->|
| ..., |
| (LRCn,RCn}) |
| |
|<------- ASP Active(RC1)-------|
|-----ASP Active Ack (RC1)----->|
| |
: :
: :
| |
|<------- ASP Active(RCn)-------|
|-----ASP Active Ack (RCn)----->|
| |Note: if a registration attempt doesn't work out (e.g., an Invalid RKn 💀), the Register Response message will carry an unsuccessful indication, and the ASP will not subsequently send an ASP Active message for that one. Each LRC/RK pair registration gets judged on its own, so one flop doesn't ruin the whole batch 🫶
The ASP Active message can be sent at any time after the related successful registration, and it may have more than one RC. Main character timing, honestly 🌸
5.1.2 Two ASPs in Application Server ("1+1" sparing) 🦋
This scenario is about an SGP and two ASPs in the same Application Server. ASP1 is set up to be ASP-ACTIVE, and ASP2 is the "backup" for when communication fails or ASP1 gets withdrawn from service. ASP2 can be a hot, warm, or cold backup, and which one depends on how much call/transaction state ASP1 and ASP2 share, or whether they can talk about call state when something goes wrong. The message flow looks the same whether the ASP Active messages say "Override", "Loadshare" or "Broadcast" mode, although this example would typically use Override mode 🔥
SGP ASP1 ASP2
| | |
|<--------ASP Up---------| |
|-------ASP Up Ack------>| |
| | |
|<----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------>|
| | |
| | |
|<-------ASP Active------| |
|------ASP Active Ack--->| |
| | |5.1.3 Two ASPs in an Application Server ("1+1" sparing, loadsharing case) 👯♀️
This is basically the same vibe as Section 5.1.2, except both ASPs get brought up to ASP-ACTIVE and then they loadshare the traffic together 🌈 Here, one ASP is enough to handle the whole traffic load on its own, so it's giving redundancy with a side of teamwork.
SGP ASP1 ASP2
| | |
|<---------ASP Up--------| |
|--------ASP Up Ack----->| |
| | |
|<-----------------------------ASP Up---------------|
|----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active (Ldshr)---| |
|-----ASP-Active Ack---->| |
| | |
|---NOTIFY (AS-ACTIVE)-->| |
|---------------------------NOTIFY (AS-ACTIVE------>|
| | |
|<---------------------------ASP Active (Ldshr)-----|
|------------------------------ASP Active Ack------>|
| | |5.1.4 Three ASPs in an Application Server ("n+k" sparing, loadsharing case) 🎀
Okay, now we have an SGP and three ASPs in the same Application Server 🙈 Two of them get brought to ASP-ACTIVE and share the load. A minimum of two ASPs are required to handle the total traffic load, so this is the 2+1 sparing setup. Two working, one spare, very organized 💅
SGP ASP1 ASP2 ASP3
| | | |
|<------ASP Up------| | |
|-----ASP Up Ack--->| | |
| | | |
|<-------------------------ASP Up-------| |
|------------------------ASP Up Ack---->| |
| | | |
|<--------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack---->|
| | | |
| | | |
|<--ASP Act (Ldshr)-| | |
|----ASP Act Ack--->| | |
| | | |
| | | |
|<-------------------ASP Act. (Ldshr)---| |
|----------------------ASP Act Ack----->| |
| | | |
|---------Notify (AS-ACTIVE)----------->| |
|----------------------Notify (AS-ACTIVE)------------------>|5.2 ASP Traffic Failover Examples 🚨
5.2.1 (1+1 Sparing, Withdrawal of ASP, Backup Override) 💔➡️💖
Picking up right where Section 5.1.2 left off, ASP1 decides to withdraw from service, and the failover happens 🦋
SGP ASP1 ASP2
| | |
|<-----ASP Inactive------| |
|----ASP Inactive Ack--->| |
| | |
|----NTFY(AS-PENDING)--->| |
|-----------------------NTFY(AS-PENDING)----------->|
| | |
|<----------------------------- ASP Active----------|
|-----------------------------ASP Active Ack------->|
| | |
|----NTFY(AS-ACTIVE)---->| |
|-----------------------NTFY(AS-ACTIVE)------------>|Note: if the SGP M3UA layer detects the loss of the M3UA peer (e.g., M3UA heartbeat loss or detection of SCTP failure), the initial ASP Inactive message exchange (i.e., SGP to ASP1) would not occur. Oof, skipped the formalities 😭
5.2.2 (1+1 Sparing, Backup Override) 👑
Following on from Section 5.1.2, this time ASP2 wants to Override ASP1 and take over the traffic. Power move 💅
SGP ASP1 ASP2
| | |
|<----------------------------- ASP Active----------|
|------------------------------ASP Active Ack------>|
|----NTFY(Alt ASP-Act)-->| |
| | |5.2.3 (n+k Sparing, Loadsharing case, Withdrawal of ASP) 🌸
Following on from Section 5.1.4, ASP1 withdraws from service. The SG has to keep track of the minimum ASP resources it needs, because the Notify message only goes out when that's known. For example, if the SG knows that "n+k" = "2+1" for a Loadshare AS and "n" currently equals 1, it can send the Notify 🧠✨
SGP ASP1 ASP2 ASP3
| | | |
|<----ASP Inact.----| | |
|---ASP Inact Ack-->| | |
| | | |
|--------------------------------NTFY(Ins. ASPs)----------->|
| | | |
|<----------------------------------------ASP Act (Ldshr)---|
|------------------------------------------ASP Act (Ack)--->|
| | | |Note: if the SGP detects loss of the ASP1 M3UA peer (e.g., M3UA heartbeat loss or detection of SCTP failure), the initial ASP Inactive message exchange (i.e., SGP-ASP1) would not occur. Same tea as before, bestie 🫖
5.3 Normal Withdrawal of an ASP from an Application Server and Teardown of an Association 🧹
An ASP that's now confirmed in the state ASP-INACTIVE (meaning it has received an ASP Inactive Ack message) can move on to the ASP-DOWN state, if it's going to be removed from service. This follows on from Section 5.2.1 or 5.2.3, where ASP1 has moved to the "Inactive" state. Clean exit energy ✨
SGP ASP1
| |
|<-----ASP Inactive (RCn)------| RC: Routing Context
|----ASP Inactive Ack (RCn)--->|
| |
|<-----DEREGISTER REQ(RCn)-----| See Notes
| |
|---DEREGISTER RESP(LRCn,RCn)->|
| |
: :
| |
|<-----------ASP Down----------|
|---------ASP Down Ack-------->|
| |Note: the Deregistration procedure will typically be used if the ASP previously used the Registration procedures for configuration within the Application Server. ASP Inactive and Deregister message exchanges may contain multiple Routing Contexts 🍓
The ASP should be in the ASP-INACTIVE state and should have deregistered in all its Routing Contexts before attempting to move to the ASP-DOWN state. Tidy up first, then leave the party 🎉
5.4 M3UA/MTP3-User Boundary Examples 🧚
5.4.1 At an ASP 💜
This section describes the primitive mapping between the MTP3 User and the M3UA layer at an ASP. It's the handoff point where the two layers meet, and it's giving very important bridge energy 🌉
5.4.1.1 Support for MTP-TRANSFER Primitives at the ASP ⭐
5.4.1.1.1 Support for MTP-TRANSFER Request Primitive ✨
okay so, when the MTP3-User on the ASP has data to send to a remote MTP3-User, it uses the MTP-TRANSFER request primitive 📨. The M3UA layer at the ASP then does all of this when it gets that request from the M3UA user:
- Determine the correct SGP;
- Determine the correct association to the chosen SGP;
- Determine the correct stream in the association (e.g., based on SLS);
- Determine whether to complete the optional fields of the DATA message;
- Map the MTP-TRANSFER request primitive into the Protocol Data field of a DATA message;
- Send the DATA message to the remote M3UA peer at the SGP, over the SCTP association.
SGP ASP
| |
|<-----DATA Message-------|<--MTP-TRANSFER req.
| |5.4.1.1.2 Support for the MTP-TRANSFER Indication Primitive 💌
this one is the receiving side, and it's giving main character energy 🎀. When the M3UA layer on the ASP gets a DATA message from the M3UA peer at the remote SGP, it does the following:
- Evaluate the optional fields of the DATA message, if present;
- Map the Protocol Data field of a DATA message into the MTP-TRANSFER indication primitive;
- Pass the MTP-TRANSFER indication primitive to the user part. In case of multiple user parts, the optional fields of the Data message are used to determine the concerned user part.
SGP ASP
| |
|------Data Message------>|-->MTP-Transfer ind.
| |5.4.1.1.3 Support for ASP Querying of SS7 Destination States 🔍
sometimes things go sideways, like a temporary loss of connectivity to the SGP, and then the M3UA layer at the ASP may decide to audit SS7 destination availability and congestion states 🙈. Note: there is no primitive for the MTP3-User to request this audit from the M3UA layer, because it's initiated by an internal M3UA management function, so the MTP3-User can't ask for it directly 💅.
SGP ASP
| |
|<----------DAUD-----------|
|<----------DAUD-----------|
|<----------DAUD-----------|
| |
| |5.4.2 At an SGP 🌸
this section is all about the primitive mapping between the MTP3-User and the M3UA layer at an SGP. Let's get into it 🦋.
5.4.2.1 Support for MTP-TRANSFER Request Primitive at the SGP
when the M3UA layer at the SGP has received DATA messages from its peer that are destined for the SS7 network, it does the following:
- Evaluate the optional fields of the DATA message, if present, to determine the Network Appearance;
- Map the Protocol data field of the DATA message into an MTP-TRANSFER request primitive;
- Pass the MTP-TRANSFER request primitive to the MTP3 of the concerned Network Appearance.
SGP ASP
| |
<---MTP-TRANSFER req.|<---------DATA -----------|
| |5.4.2.2 Support for MTP-TRANSFER Indication Primitive at the SGP 🔁
when the MTP3 layer at the SGP has data to pass to its user parts, it uses the MTP-TRANSFER indication primitive. The M3UA layer at the SGP then does the following when it receives an MTP-TRANSFER indication primitive:
- Determine the correct AS using the distribution function;
- Select an ASP in the ASP-ACTIVE state
- Determine the correct association to the chosen ASP;
- Determine the correct stream in the SCTP association (e.g., based on SLS);
- Determine whether to complete the optional fields of the DATA message;
- Map the MTP-TRANSFER indication primitive into the Protocol Data field of a DATA message;
- Send the DATA message to the remote M3UA peer in the ASP, over the SCTP association
SGP ASP
| |
--MTP-TRANSFER ind.->|-----------DATA --------->|
| |5.4.2.3 Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS Indication Primitives 📣
the MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from the MTP3 upper layer interface at the SGP need to be made available to the remote MTP3 User Part lower layer interface at the concerned ASP(s). Everybody needs to know the tea 🍵.
5.4.2.3.1 Destination Unavailable 🚫
the MTP3 layer at the SGP generates an MTP-PAUSE indication primitive when it locally determines that an SS7 destination is unreachable. The M3UA layer maps this primitive to a DUNA message. The SGP M3UA layer determines the set of concerned ASPs to be informed based on internal SS7 network information associated with the MTP-PAUSE indication primitive indication.
SGP ASP
| |
--MTP-PAUSE ind.-->|---------DUNA----------->|--MTP-PAUSE ind.-->
| |5.4.2.3.2 Destination Available ✅
the MTP3 at the SGP generates an MTP-RESUME indication primitive when it locally determines that an SS7 destination that was previously unreachable is now reachable. The M3UA layer maps this primitive to a DAVA message. The SGP M3UA determines the set of concerned ASPs to be informed based on internal SS7 network information associated with the MTP-RESUME indication primitive.
SGP ASP
| |
--MTP-RESUME ind.-->|-----------DAVA--------->|--MTP-RESUME ind.-->
| |5.4.2.3.3 SS7 Network Congestion 🚦
the MTP3 layer at the SGP generates an MTP-STATUS indication primitive when it locally determines that the route to an SS7 destination is congested. The M3UA layer maps this primitive to a SCON message. It determines which ASP(s) to send the SCON message to based on the intended Application Server.
SGP ASP
| |
--MTP-STATUS ind.-->|-----------SCON--------->|--MTP-STATUS ind.-->
| |5.4.2.3.4 Destination User Part Unavailable 🙅
the MTP3 layer at the SGP generates an MTP-STATUS indication primitive when it receives a UPU message from the SS7 network. The M3UA layer maps this primitive to a DUPU message. It determines which ASP(s) to send the DUPU to based on the intended Application Server.
SGP ASP
| |
--MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.-->
| |5.5 Examples for IPSP communication 🎬
these scenarios show a basic example of IPSP communication across the three phases of the connection: establishment, data exchange, and disconnection. It's assumed that the SCTP association is already set up. Both single exchange and double exchange behavior are included, for illustrative purposes 💜.
5.5.1 Single exchange:
IPSP-A IPSP-B
| |
|-------------ASP Up------------>|
|<----------ASP Up Ack-----------|
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
| |
|<========= DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->| (optional)
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |Routing Context values are previously agreed to be the same in both directions 🤝.
5.5.2 Double exchange:
IPSP-A IPSP-B
| |
|<-------------ASP Up------------|
|-----------ASP Up Ack---------->|
| |
|-------------ASP Up------------>| (optional)
|<----------ASP Up Ack-----------| (optional)
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
|------- ASP Active(RCa)-------->| RC: Routing Context
|<-----ASP Active Ack (RCa)------| (optional)
| |
|<========= DATA (RCa) =========|
|========== DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->|
| |
|------ASP Inactive (RCa)------->| RC: Routing Context
|<----ASP Inactive Ack (RCa)-----|
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
|------------ASP Down----------->| (optional)
|<--------ASP Down Ack-----------| (optional)
| |In this approach, one single exchange of ASP Up message can be considered enough, since the other peer's response can be taken as notice that it is in the ASP_UP state 🌈.
For the same reason, only one ASP Down message is needed. Once an IPSP receives an ASP_Down ack message, it is itself considered to be in the ASP_Down state and is not allowed to receive ASPSM messages 🙈💀.
6. Security Considerations 🔐
6.1 Introduction 💖
M3UA is designed to carry signalling messages for telephony services. As such, M3UA has to account for the security needs of several parties: the end users of the services, the network providers, and the applications involved. Additional requirements may come from local regulation. While these parties have some overlapping security needs, any security solution should fulfill all of the different parties' needs 😭🫶.
6.2 Threats 💅
Okay bestie, there is no quick fix, one-size-fits-all solution for security 😭 As a transport protocol, M3UA has these security objectives 🫶:
- Availability of reliable and timely user data transport. 🌸
- Integrity of user data transport. 🎀
- Confidentiality of user data. 🔒
M3UA is recommended to be transported on SCTP. SCTP [17] gives you some transport-related security features, like some protection against:
- Blind Denial of Service Attacks
- Flooding
- Masquerade
- Improper Monopolization of Services
When M3UA is running in a professionally managed corporate or service provider network, it is reasonable to expect that this network includes an appropriate security policy framework. The "Site Security Handbook" [22] should be consulted for guidance 📖
When the network M3UA runs in involves more than one party, it may not be reasonable to expect that all parties have implemented security in a sufficient manner. ngl this is where it gets real 😬 In such a case, it is recommended that IPSEC is used to ensure confidentiality of user payload. Consult [23] for more information on configuring IPSEC services 🧚
6.3 Protecting Confidentiality 🎀
Particularly for mobile users, the requirement for confidentiality may include the masking of IP addresses and ports. In this case, application level encryption is not sufficient, so IPSEC ESP [24] SHOULD be used instead ✨ Regardless of which level performs the encryption, the IPSEC ISAKMP [25] service SHOULD be used for key management 🔑
7. IANA Considerations 🦋
7.1 SCTP Payload Protocol Identifier
IANA has assigned an M3UA value for the Payload Protocol Identifier in the SCTP DATA chunk. The following SCTP Payload Protocol Identifier is registered:
M3UA "3"The SCTP Payload Protocol Identifier value "3" SHOULD be included in each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA protocol. The value "0" (unspecified) is also allowed, but any other values MUST not be used. This Payload Protocol Identifier is not directly used by SCTP, but it MAY be used by certain network entities to identify the type of information being carried in a DATA chunk 🌈
The User Adaptation peer MAY use the Payload Protocol Identifier as a way of determining additional information about the data being presented to it by SCTP 💜
7.2 M3UA Port Number
IANA has registered SCTP (and UDP/TCP) Port Number 2905 for M3UA. It is recommended that SGPs use this SCTP port number for listening for new connections. SGPs MAY also use statically configured SCTP port numbers instead 🍓
7.3 M3UA Protocol Extensions
This protocol may also be extended through IANA in three ways:
- through definition of additional message classes,
- through definition of additional message types, and
- through definition of additional message parameters
The definition and use of new message classes, types and parameters is an integral part of SIGTRAN adaptation layers. So these extensions are assigned by IANA through an IETF Consensus action, as defined in Guidelines for Writing an IANA Considerations Section in RFCs (25]
The proposed extension must in no way adversely affect the general working of the protocol 🫶
7.3.1 IETF Defined Message Classes
The documentation for a new message class MUST include the following information:
- (a) A long and short name for the new message class;
- (b) A detailed description of the purpose of the message class.
7.3.2 IETF Defined Message Types
The documentation for a new message type MUST include the following information:
- (a) A long and short name for the new message type;
- (b) A detailed description of the structure of the message;.
- (c) A detailed definition and description of intended use for each field within the message;
- (d) A detailed procedural description of the use of the new message type within the operation of the protocol;
- (e) A detailed description of error conditions when receiving this message type.
When an implementation receives a message type which it does not support, it MUST respond with an Error (ERR) message ("Unsupported Message Type") 🙈
7.3.3 IETF Defined Parameter Extension
Documentation of the message parameter MUST contain the following information:
- (a) Name of the parameter type;
- (b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2;
- (c) Detailed definition of each component of the parameter value;
- (d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same message.
8. References 📚
8.1 Normative References
[1] ITU-T Recommendations Q.761 to Q.767, "Signalling System No.7 (SS7) - ISDN User Part (ISUP)"
[2] ANSI T1.113 - "Signaling System Number 7 - ISDN User Part"
[3] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services"
[4] ITU-T Recommendations Q.711 to Q.715, "Signalling System No. 7 (SS7) - Signalling Connection Control Part (SCCP)"
[5] ANSI T1.112 "Signaling System Number 7 - Signaling Connection Control Part"
[6] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Signalling Connection Control Part (SCCP) (connectionless and connection-oriented class 2) to support international interconnection; Part 1: Protocol specification"
[7] ITU-T Recommendations Q.701 to Q.705, "Signalling System No. 7 (SS7) - Message Transfer Part (MTP)"
[8] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part"
[9] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Message Transfer Part (MTP) to support international interconnection; Part 1: Protocol specification"
[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
8.2 Informative References
[11] Ong, L., Rytina, M., Garcia, H., Schwarzbauer, L., Coene, H., Lin, I., Juhasz, M. and C. Holdrege, "Framework Architecture for Signaling Transport", RFC 2719, October 1999.
[12] ITU-T Recommendation Q.720, "Telephone User Part"
[13] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7 (SS7) - Transaction Capabilities (TCAP)"
[14] ANSI T1.114 "Signaling System Number 7 - Transaction Capabilities Application Part"
[15] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2; Part 1: Protocol specification"
[16] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd Generation partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface: General Aspects and Principles"
[17] Stewart, R., Xie, Q., Mornmeault, K., Sharp, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transport Protocol", RFC 2960, October 2000.
[18] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer - Service Specific Coordination Function for signalling at the Network Node Interface (SSCF at NNI)"
[19] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP)"
[20] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[21] ITU-T Recommendation Q.2210 "Message Transfer Part Level 3 functions and messages using the services of ITU Recommendation Q.2140"
[22] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[23] Ramakrishnan, S., Floyd, S. and D. Black, "Security Architecture for the Internet Protocol", RFC 3168, November 1998.
[24] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[25] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998.
[26] Narten, T. and H. Alverstrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[27] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J. Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer", RFC 3331, August 2002.
[28] George, T., et. al., "SS7 MTP2-User Peer-to-Peer Adaptation Layer", Work in Progress.
[29] Telecommunication Technology Committee (TTC) Standard JT-Q704, "Message Transfer Part Signaling Network Functions", April 28, 1992.
9. Acknowledgements 🫶
The authors would like to thank Antonio Roque Alvarez, Joyce Archibald, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, Antonio Caete, Nikhil Jain, Roland Jesske, Joe Keller, Kurt Kite, Ming Lin, Steve Lorusso, Naoto Makinae, Howard May, Francois Mouillaud, Barry Nagelberg, Neil Olson, Heinz Prantner, Shyamal Prasad, Mukesh Punhani, Selvam Rengasami, John Schantz, Ray Singh, Michael Tuexen, Nitin Tomar, Gery Verwimp, Tim Vetter, Kazuo Watanabe, Ben Wilson and many others for their valuable comments and suggestions. so many legends 💖
10. Document Contributors 🌟
- Ian Rytina - Ericsson
- Guy Mousseau - Nortel Networks
- Lyndon Ong - Ciena
- Hanns Juergen Schwarzbauer - Siemens
- Klaus Gradischnig - Detecon Inc.
- Mallesh Kalla - Telcordia
- Normand Glaude - Performance Technologies
- Brian Bidulock - OpenSS7
- John Loughney - Nokia
Appendix A ✨
A.1 Signalling Network Architecture ✨
okay so a Signalling Gateway (SG) is what carries MTP3-User signalling traffic from the SS7 network out to a bunch of distributed ASPs (think MGCs and IP Databases) 🌐 and bestie, M3UA on its own is NOT built to hit the performance and reliability bar for that job. 💀 but the combo of distributed architecture plus redundant networks is what gives you reliable signalling over IP 🫶 and M3UA is flexible enough to run and manage in all kinds of physical setups, so Network Operators can actually hit their own performance and reliability goals 💅
so carrier grade SS7 reliability is super strict 😭 Network Operators might need zero single points of failure between an SS7 node and an IP-based application. the usual way to get there is redundant SGPs or SGs, redundant hosts, and redundant QOS-bounded IP network paths for SCTP Associations between SCTP End Points 🔥 and obviously the reliability of the SG, the MGC and the other IP-based functional elements also counts, no skipping that 🙈 the spread of ASPs and SGPs across the available Hosts MAY also be considered 🌸 for example, for one Application Server, its related ASPs could be spread over at least two Hosts 🎀
here's a physical network architecture that matters for SS7 carrier grade operation in the IP network domain, shown in Figure 5 below 👑
SGs MGCs
Host#1 ************** ************** Host#3
* ********__*__________________________*__******** * =
* *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1
* ******** * \ / * ******** *
* ********__*______\__/________________*__******** *
* *SGP2.1*__*_______\/______ _____*__* ASP2 * *
* ******** * /\ | | * ******** *
* : * / \ | | * : *
* ******** * / \ | | * ******** *
* * SGPn * * | | | | * * ASPn * *
* ******** * | | | | * ******** *
************** | | | | **************
| | \ /
Host#2 ************** | | \ / ************** Host#4
* ********__*_____| |______\/_______*__******** * =
* *SGP1.2*__*_________________/\_______*__* ASP1 * * MGC2
* ******** * / \ * ******** *
* ********__*_______________/ \_____*__******** *
* *SGP2.2*__*__________________________*__* ASP2 * *
* ******** * * ******** *
* : * SCTP Associations * : *
* ******** * * ******** *
* * SGPn * * * * ASPn * *
* ******** * * ******** *
************** **************
SGP1.1 and SGP1.2 are part of SG1
SGP2.1 and SGP2.2 are part of SG2
Figure 5 - Physical Modelin this model 🦋 each host can run loads of application processes. with the MGC, an ASP can serve one or more Application Servers and it shows up as an SCTP end point. and one or more Signalling Gateway Processes together make up one Signalling Gateway 🧚
this example can also be used for IPSP-IPSP signalling 💜 each IPSP can have its services spread across 2 hosts or more, with multiple server processes on each host ✨
in the picture above, each signalling process (SGP, ASP or IPSP) is the end point of more than one SCTP association, and those lead to more than one other signalling process 🌈 so a signalling process has to be able to push M3UA messages out to lots of simultaneous active associations at once 😭 that message distribution is based on the status of provisioned Routing Keys, the status of the signalling routes to signalling points in the SS7 network, and the redundancy model (active-standby, load sharing, broadcast, n+k) of the remote signalling processes 💅
for carrier grade networks, if one signalling process fails or gets cut off, stable calls or transactions should not be lost 🫶 which means signalling processes sometimes need to share call/transaction state or pass call state to each other 👀 for ASPs doing call processing, they may also need to coordinate with the related Media Gateway to hand over MGC control for a particular trunk termination 🎀 BUT sharing or talking about call/transaction state is outside the scope of this document, so we're leaving that one alone 🙈
this model is just an example, nothing more 💖 M3UA puts no restrictions on the exact layout of the network elements, the message distribution algorithms, or how the signalling processes are distributed 🦋 what it DOES do is give you a framework and a set of messages for a flexible, scalable signalling network architecture, aimed at reliability and performance ✨
A.2 Redundancy Models 👑
A.2.1 Application Server Redundancy 🌸
at the SGP, an Application Server list holds active and inactive ASPs to support ASP broadcast, loadsharing and failover procedures 💅 the list of ASPs inside a logical Application Server is kept up to date in the SGP so it matches the active Application Server Process(es) 🫶
for example, in the network shown in Figure 1, all messages to DPC x could go to ASP1 in Host3 or ASP1 in Host4 🌈 the AS list at SGP1 in Host 1 might look like this:
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Inactivein this "1+1" redundancy case, ASP1 in Host3 gets any incoming message with DPC=x 🧚 and ASP1 in Host4 would normally be brought to the "active" state when ASP1/Host1 fails or loses connectivity 😭
the AS List at SGP1 in Host1 could also be set up in loadshare mode 💜
Routing Key {DPC=x) - "Application Server #1"
ASP1/Host3 - State = Active
ASP1/Host4 - State = Activehere both ASPs get a portion of the traffic 🦋 for example, the two ASPs could together act as a database, where incoming queries can go to any active ASP ✨
a Network Operator needs to take care when picking the routing information to use as the Routing Key for a particular AS 👀
for example, if Application Servers are defined using ranges of ISUP CIC values, the Operator is implicitly splitting up control of the related circuit groups 💀 some CIC value range assignments may interfere with ISUP circuit group management procedures 🙈
during failover, it is recommended that stable calls do not fail when the ASPs are handling call processing 🎀 calls in "transition" may fail, though measures of communication between the ASPs involved can help reduce that 💖 for example, the two ASPs may share call state via shared memory, or use an ASP to ASP protocol to pass call state information 🌈 any ASP-to-ASP protocol for this is outside the scope of this document 💅
A.2.2 Signalling Gateway Redundancy 🧚
Signalling Gateways can also be spread across multiple hosts 🌐 much like the AS model, SGs may be made of one or more SG Processes (SGPs), spread across one or more hosts, using an active/backup or a loadsharing model 🫶 should an SGP lose all or part of its SS7 connectivity and other SGPs exist, the SGP may terminate the SCTP associations to the concerned ASPs 😭
so it's possible for an ASP to route signalling messages destined for the SS7 network through more than one SGP 👑 in this model, a Signalling Gateway is deployed as a cluster of hosts acting as one single SG 💖 a primary/backup redundancy model is possible, where the SCTP association to a primary SGP being unavailable could be used to reroute affected traffic to an alternate SGP 🦋 a loadsharing model is possible too, where signalling messages are loadshared between multiple SGPs ✨ and a broadcast model is also possible, where signalling messages are sent to each active SGP in the SG 🌸 the distribution of MTP3-user messages over the SGPs should be done in a way that minimizes message missequencing, as required by the SS7 User Parts 💅
it may also be possible for an ASP to use more than one SG to reach a specific SS7 end point, in a model that looks like an SS7 STP mated pair 🎀 typically, SS7 STPs are deployed in mated pairs with traffic loadshared between them 🫶 other models are also possible, subject to the limits of the local SS7 network provisioning guidelines 🔥
from the M3UA layer's point of view at an ASP, a particular SG can transfer traffic to a provisioned SS7 destination X if an SCTP association with at least one SGP of that SG is established, the SGP has sent back an acknowledgement telling the ASP that it is actively handling traffic for destination X, the SGP has not indicated that destination X is inaccessible, and the SGP has not indicated MTP Restart 🌈 when an ASP is set up to use multiple SGPs for transferring traffic to the SS7 network, the ASP must maintain knowledge of the current capability of the SGPs to handle traffic to destinations of interest 👀 this info is crucial to the overall reliability of the service, for active/backup, loadsharing and broadcast models, when failures, recovery and maintenance happen 💜 the ASP M3UA may also use this info for congestion avoidance purposes 🧚 and the distribution of MTP3-user messages over the SGPs should, again, be done in a way that minimizes message missequencing, as required by the SS7 User Parts 💖
Editors' Addresses 💌
Greg Sidebottom
Signatus Technologies
Kanata, Ontario, Canada
EMail: greg@signatustechnologies.com
Ken Morneault
Cisco Systems Inc.
13615 Dulles Technology Drive
Herndon, VA, USA 20171
EMail: kmorneau@cisco.com
Javier Pastor-Balbas
Ericsson Espana S.A.
C/ Retama 1
28045 Madrid - Spain
EMail: j.javier.pastor@ericsson.comFull Copyright Statement ✨
okay bestie, the legal bit at the end is actually important 💅 Copyright (C) The Internet Society (2002). All Rights Reserved. 🎀
so the deal is: you can copy this document and share it with anyone, and you can make derivative works that comment on or explain it or help people implement it 🦋 you can publish and distribute those too, in whole or in part, with no real restrictions, as long as the copyright notice and this paragraph stay on every copy and every derivative work 💖
BUT the document itself can't be modified in any way 🙅♀️ you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. the exceptions are: (1) if you're developing Internet standards, then you follow the copyright procedures in the Internet Standards process, or (2) if you're translating it into languages other than English 🌍
those permissions are perpetual, meaning they will never be revoked by the Internet Society or its successors or assigns 🫶 ngl that's iconic
and the big disclaimer 😭 this document and the info in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀 it's giving "use at your own risk" energy, fr fr
Acknowledgement 🌸
funding for the RFC Editor function is currently provided by the Internet Society 💜 so that's who keeps the lights on for the RFC Editor, and that's the end of the RFC! 🎉🧚
📦 where this page comes from
- ietf: rfc3332 2002-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms