M2UA is an internet protocol part of the SS7 SIGTRAN protocol stack and it was created to provide remote processing for SS7 layer 3 messages and MTP2 links termination in the IP network. It is designed in a gateway-client model and is able to control the Layer 2 links on the gateway side and to backhaul two SS7 nodes located in different networks types, PSTN and Internet. This gateway-client design does not allow a SS7 layer 3 present on the gateway side because the M2UA gateway itself acts as a SS7 layer 3 without the capability of directly controlling the supervised layers 2; They are controlled by the active clients connected to the gateway.
For a better understanding I will explain the purpose of gateway-client model separately.
As mentioned above the gateway has a list of SS7 layers 2 under his supervision; and it will change their state only if the active clients requested so. This behavior will let the following responsibility in the hands of the gateway:
- it has to listen for the new incoming client connections;
- it has to manage the connected clients;
- it has to take the received data from the supervised layers 2 and send it to the active clients and send the data received from the active clients to the layers 2.
Leaving the technical language behind let's say that we have three factories all in range of a few miles from an airfield. When a factory determines that it needs more raw material it books some airplanes from the airfield. Now the factory is in control of the airplanes and will use them to send it's products from the factory to a location A and from that location will receive row material. On the airfield the cargo received form location A will be loaded into trunks to be send to the factory, and the cargo received from the factory will be loaded in the airplanes to be send to location A.
In the unconventional example above the airfield represents the M2UA Gateway and the factories represents the M2UA clients, but let's focus on the airfield for the moment. Like M2UA gateway has some SS7 layers 2 under his supervision the airfield has some airplanes under his supervision. As M2UA client controls the state of the SS7 layers 2 under the gateway supervision the factory controls the state of the airplanes if are booked or not; and both performs as transport type switch.
As mentioned above the M2UA client has the control of the M2UA gateway's links. Besides that the client also has to:
- connect to the gateway and specify witch layers 2 desires to be under his control.
- ensure the traffic flow between SS7 nodes.
As mentioned in Protocol Description M2UA can be used for traffic switch from MTP1 to SCTP (classic SS7 to IP based).
The image below illustrates such a scenario.
As we can see in the image above we have two SS7 nodes (Node 1 and Node 2) and a M2UA gateway node. Node 1 is connected with the M2UA gateway node with a classic MTP 2 MTP1 link and Node 2 is connected to the M2UA gateway with a M2UA link. In this scenario the M2UA gateway will forward, all received MTP traffic from Node 1, over internet to Node 2 and the way back; mainly will switch the transport type from MTP1 to SCTP and from SCTP to MTP1. From the point of view of the MTP 3 layers present on Node 1 and Node 2, the traffic type switch is made transparently and they are unaware of it.
The traffic type switch can also be accomplished by using M2PA protocol. For a better understanding of the usages scenarios you should read this document.
Another possible usage can be to provide remote processing for a interconnected SS7 node.
In the image below such a scenario is illustrated.
In the image above we have a SS7 Node 3 witch is interconnected with Node 1 and Node 2, each of them with it's own Point Code. For some reasons, let's say security issues or network design, we do not want to process the traffic received from Node 1 on Node 3 so the presence of the M2UA Gateway on Node 3 is to provide remote processing for the traffic received from Node 1 on Node 4. In the scenario above Node 3 and Node 4 will share the same SS7 Point Code.
The M2UA protocol can operate in three traffic modes:
- Override. This is the only one supported by YATE at M2UA level.
This traffic mode implies that when a new client wishes to become active, the gateway should inactivate the active client and activate the new client.
- Loadshare. Is not currently supported in YATE.
This traffic mode implies that multiple clients can be active at the same time.
In this mode the gateway will try to share the received traffic between the active clients.
- Broadcast. Is not currently supported in YATE.
This traffic mode implies that gateway should send the received messages to all active clients.
- ASP_DOWN: The client is down.
- ASP_UP_REQ: The client has send ASP_UP message but it did not received ASP_UP_ACK message from the gateway.
- ASP_UP: The client received ASP_UP_ACK from the gateway.
- ASP_ACTIVE_REQ: The client send ASP_ACTIVE message but it did not received ASP_ACTIVE_ACK message from the gateway.
- ASP_ACTIVE: The client received ASP_ACTIVE_ACK message from the gateway and it has the control of at leas one IID.
- ASP_INACTIVE: The client does not have the control of any IID.
The image below exemplifies the state negotiation between a M2UA client and a M2UA gateway.
At startup a M2UA client is in ASP_DOWN state. When it wishes to become active, firsts it has to setup the connection with the gateway. After the connection has been made it starts the state negotiation, with the gateway, by sending ASP_UP with it's ASP ID to the gateway and changing it's state in ASP_UP_REQUEST. When the gateway receives an ASP_UP message from a connected client it checks if there is any connected client with the same ASP_ID, if a connected client exists with the same ASP_ID an bad client configuration algorithm will start to detect if there are two clients configured with the same ASP_ID or is just one client who lost the connection and now tries to reconnect itself; If a bad client configuration is detected the gateway will give the chance only to one of them to become active, and the other will be placed in a blacklist and an additional Management Blocking error message will be send. After the bad client configuration algorithm ends or if the gateway did not found other connected clients with the same ASP_ID it will send ASP_UP_ACK to the requesting client.
After the client has received ASP_UP_ACK message from the gateway it will update it's state in ASP_UP and will send to the gateway AS_ACTIVE message with a list of IID's that it wishes to control.
When the gateway receives ASP_ACTIVE message from a client it tries to activate all the managed layer 2 links that have their's IID present in ASP_ACTIVE message; if one or more IID's could be activated the gateway will send ASP_ACTIVE_ACK message back to the user containing the list of activated IID's.
When the client received ASP_ACTIVE_ACK message it will change it's state in ASP_ACTIVE.
After the client has enter in ASP_ACTIVE state, the SS7 layer 3 traffic can not start, because the remote SS7 layer 2 is not active.
In the image below is exemplified how the remote SS7 layer 2 is activated. Attach::m2ua_normal_alignment.png
When the gateway activates a layer 2, it does not inform the layer 2 to start the alignment procedure, instead it creates a connection between the active client and the activated layers 2. The alignment procedure is started after the client requested so by sending ESTABLISH_REQ message. The gateway will inform the client that the alignment procedure ended by sending ESTABISH_CONFIRM message back to the client.
After all this messages were exchanged the MTP3 traffic can start.
M2UA is designed to run over SCTP transport.
The SCTP stream management is not fixed like M2PA but is required to use at least two SCTP streams, one for management messages and one for data transport.
But also can be used a different stream to transport data for each active IID.
The registered port for M2UA protocol is 2904 and it uses value of 2 as SCTP Payload Protocol Identifier.
M2UA in YATE
Yate has implementation for both M2UA Client and M2UA Gateway.
The implementation is part of ysig library. The methods declaration are in libs/ysig/ysigchan.h file and the implementation in libs/ysig/sigtran.cpp file.
M2UA uses sigtransport module to obtain the transport layer and provides methods to interconnect with SS7 layer 3 protocols.
The YATE M2UA gateway implementation differs a little bit from the standard specifications.
The standard specifies that in Override traffic mode when a new client connects to the gateway, the gateway should inactivate the clients witch IID's are found in the newly received ASP_ACTIVE message, and redirect the traffic to the newly connected client. This behavior is not quite desired, because if we have one gateway and two clients operating in override mode, and the active client have a less stable internet connection than the other then the SS7 layer 3 traffic will be interrupted.
As a limitation the YATE M2UA Gateway implementation does not suppot the multiple clients to be active at the same time.
The M2UA Gateway has two links in control with IID's 0 and 1.
The client with the most stable internet connection (C1) connects to the gateway and activates the links.
After a period of time the client with the less stable internet connection(C2) connects to the gateway and activates the links.
Now the gateway will inactivate C1 and will drop the alignment of the links and will activate C2.
C2 will activate the links.
After a period of time C2 will loose the connection with the gateway.
Now the gateway will inactivate C2 and will activate C1.
After C2's internet connection is up again it will connect to the gateway and we enter in a infinite loop here.
So to avoid this behavior in YATE we do not inactivate the active client if a new client requested the traffic, instead we are inserting it in a waiting queue, and when the active client becomes inactive the first client from the waiting list will be activated.
type=ss7-m2ua-gateway sig=sctp-m2ua-gw The underlying transport of this gateway. asp_switch=5000 Time interval in milliseconds for this gateway to fire bad client configuration protection. asp_ignore=600000 Time interval in milliseconds used by this gateway. max_asp_switch=5 integer. The maximum counter when a client up request can be overridden. If this counter has been reached and asp_switch timer has not expired, the client override protection will be fired. expect_asp_id=true boolean: True if the gateway should accept asp up requests only with asp id. link=ss7-l2-1,1 link: string: Name of a SS7 Layer 2 link witch this gateway should control. This parameter can be repeated to add more links to the gateway. An explicit interface identifier can be provided after a comma. This option can be repeated
To find the status of a M2UA gateway you can run the command "status sig GW_NAME" from rmanager.
M2UA Control commands:
|Activate||control M2UA_GW_NAME activate aspid=x||Activate the client with aspid=x|
|Inactivate||control M2UA_GW_NAME inactivate aspid=x||Inactivate the client with aspid=x|
|Drop||control M2UA_GW_NAME drop aspid=x||Drop the connection from the client with aspid=x|
The M2UA client configuration is composed from two parts:
- This section represents the common ground for the M2UA links
[m2ua-client] type=ss7-m2ua-client ; The object type sig=sctp-m2ua-client ; The underlying transport for this client aspid=1 ; ASP Identifier
- The following sections represents the M2UA links
[link1] type=ss7-m2ua ; Object type client=m2ua-client ; M2UA client reference iid=0 ; Interface Identifier
[link2] type=ss7-m2ua client=mediant_g0 iid=1
To obtain the status of M2UA links you should run the command "status sig links" from rmanager
|Status||control M2UA_CLIENT_NAME status||Show the status of this client|
|TransporRestart||control M2UA_CLIENT_NAME transport_restart||Restart the underlying transport layer|
|Pause||control M2UA_NAME pause||Pause this link message delivery|
|Resume||control M2UA_NAME resume||Align this link if it is not already aligned and it can auto start|
|Align||control M2UA_NAME align||Force this to start Align algorithm|