Contents
About roaming agreement GSM
A roaming agreement is a formal contract between two mobile network operatos that allows their subscribers to access mobile services (voice, SMS and data) while traveling outside their home network, using the partner’s network infrastructure.
Roaming agreements are essential for MVNOs before launching their business, since they don’t have their own radio network.
Roaming agreements are backed by network interconnections like:
- SS7 signaling – primarily used in 2G/3G networks
- Diameter signaling – used in 4G/LTE network
Interconnect
Interconnect is used in order to connect two networks (A, B), in order to facilitate the users from network A to send an SMS or a call to users from network B and vice-versa.
Interconnect for SMS is done by configuring YateSTP using MAP protocol, or by configuring SMPP connection direclty in YateSMSC.
Interconnect for calls is usually set up in an external SBC, most of the time using SIP. You will set up each YateUCN connection to the SBC.
Diameter & MAP roaming agreement
The roaming architecture supports both Diameter and MAP protocols by interconnecting the home network with external roaming partners.
The roaming agreement involving YateSTP operates at the MAP (SS7) protocol level. And the roaming agreement involving YateDRA operates at the Diameter protocol level.
Assuming your home network is based on Yate products, this is how it would look:
Wizard Roaming Partner
Adding Roaming Partner
In order to add a Roaming Partner, the first thing I do is to access Roaming Partners tab from My Network in MMI and I click add, then I add the details of my partner.
From My Network -> Roaming Partners -> Add button
Add roaming agreement
After pressing on “Add” the following window appears:
- Name – Roaming partner name.
- Shortname – Roaming partner shortname. This will be used in building ss7 router name.
- Type – If you are MNO (have radio network) and this partner’s subscribers are allowed to roam in your network, then set ‘MNVO’. Otherwise set ‘MNO’.
- MCCMNC list – Comma separated MCCMNC list of this partners’s IMSI. This needs to be configured in netinfo (initially it must be done manually)
- Realm – Diameter realm of roaming partner
- SS7 support – enable it in order to continue with the set-up
- Diameter support – enable it in order to continue with the set-up
SS7 step
- Connection type used in the roaming agreement:
- M2PA – both ends are M2PA
- M3UA ASP – YateSTP(s) is M3UA ASP while partner STP(s) is M3UA gw (will be added in the future)
- M3UA gw – YateSTP(s) is M3UA gw while partner STP(s) is M3UA ASP (will be added in the future)
- Dialect – SS7 Dialect(standard) used in the roaming agreement: ITU or ANSI.
- Netindicator (Network Indicator):
- national (2)
- international (0)
- reservednational (3)
- Act as server – If checked, YateSTP does not initiate a M2PA connection, the roaming partner has to initiate it. The checked value is mapped as endpoint false in the linkset between YateSTP and roaming partner STP.
- GT prefixes – Global title prefixes for the roaming agreement.
- MSISDN prefixes – MSISDN prefixes for the roaming partner. This is used for generating routing.
- PCs to route – Point codes for the roaming partner. This is used for generating routing.
Diameter step
In the DIAMETER step, there’s only a guide of how to configure the Diameter roaming agreement. Those guide steps you can also find lower on this page, check below YateDRA configuration section.
YateSTP configuration
Next step is to configure YateSTP connections. First I am going to Network settings in order to create the routing rules and then from Equipment, I edit my YateSTP in SS7 step in order to add Linksets to my roaming partner.
Regexroute rules
The routing rules can be configured for each YateSTP or globally for all YateSTP products. I recommend the global configurations, since it can be overwhelming to modify each YateSTP manually.
In order to set regexroute rules, go to:
My Network -> Routing step -> select YateSTP -> click Add -> write Regexroute rule
If the roaming partner is an MNO, the routing rule includes:
- GT prefix
- MSISDN prefix
[$init]
stp_roaming_pc=7968
[gtt-isdn]
;gt_prefix - taken from custom file
^355691=stp_roaming_pc;RemotePC=$(stp_roaming_pc);route=gt;sccp=sccp_valb_stp1;$(++$sent_to_pc_7968)
;msisdn_prefix - taken from custom file
^35569=stp_roaming_pc;RemotePC=$(stp_roaming_pc);route=msisdn;sccp=sccp_valb_stp1;$(++sent_to_pc_7968)
Routing rules explained:
- stp_roaming_pc – Roaming partner STP MTP Pointcode. This point code is configured when adding to YateSTP a Linkset
- Equipment ->edit YateSTP -> SS7 step -> add Roaming agreement linksets
- gt_prefix – this matches GT prefix/MSISDN prefix
- My Network -> Roaming Partner -> SS7 step
- sccp – this value is automatically constructed based on the Shortname of the Roaming Partner
- My Network -> Roaming Partners
Notes:
- In the future, the regexroute rules could become automatically generated
If the roaming partner is an MVNO, the routing rule includes:
- GT prefix
- MSISDN prefix
- IMSI
[$init]
stp_roaming_pc=7968
[gtt-isdn]
;gt_prefix - taken from custom file
^355691=stp_roaming_pc;RemotePC=$(stp_roaming_pc);route=gt;sccp=sccp_valb_stp1;$(++$sent_to_pc_7968)
;msisdn_prefix - taken from custom file
^35569=stp_roaming_pc;RemotePC=$(stp_roaming_pc);route=msisdn;sccp=sccp_valb_stp1;$(++sent_to_pc_7968)
;[gtt-land-mobile]
;begin rules for template=stp_roaming_routing
;=send all requests for below MNCMNC to Vodafone Albania stp
;${set_gt}=if .\+=;gt=\0;set_gt
;^27602=stp_roaming_pc;RemotePC=$(stp_roaming_pc);route=gt;sccp=sccp_valb_stp1;$(++$sent_to_pc_7968)
Linksets to roaming partners
A Linkset is the connection to your roaming partner.
Equipment -> YateSTP -> Edit button -> SS7 step -> Add button for Linkset to roaming
The connection can be set using M2PA
YateDRA configuration
Diameter Roaming Agreement
To set Diameter roaming agreement you need to set each YateDRA as below:
- Add DEA identity with role ‘relay’ for your MCC MNC (ex: epc.mnc001.mcc001.3gppnetwork.org/dea1.epc.mnc001.mcc001.3gppnetwork.org)
- Depending on YateDRA role there are 2 options to have Diameter connection:
- YateDRA acts a client and connects to partner’s Diameter server -> Setup a connection that has the DEA associated identity
- YateDRA acts as a server and receives Diameter connections from partners -> Add a new listener for DEA identity with ‘Accept rules’ to accept the MCC MNC from other network (ex: ‘Custom – regexp’ ^epc\.mnc002\.mcc002\.3gppnetwork\.org/)
- Manage Routing Table for DRA and DEA identities (JSON example is down, modify ‘vars‘ according to your network)
Identities
In order to add an identity I go to:
Equipment -> YateDRA -> Edit button ->DIAMETER step -> click Add in YateDRA identities section
Identity – Node identity is composed as it follows: realm(domain_name)/host(host_name).
Role – Which type of DIAMETER application is this identity used for.
Default priority – Priority to use this node if no other matches. A value of 0 (default) disables default use.
Default Realm priority – Priority to use this node if only the realm matches. A value of 0 (default) disables default use.
Notes:
After an identity change you need to restart equipment or run following commands from telnet:
- accounts reload
- accounts login ‘account_name’
Listeners & Accept rules
Adding Listeners is just underneath DRA Identities:
Equipment -> YateDRA -> Edit button ->DIAMETER step -> click Add in Listeners section
Name – Optional
Local IP – Local IP or IPs to bind to when the connection is made. Multiple IPs can be specified if transport is set as SCTP.
Local Port – Optional local port number, protocol default port will be used if missing.
IPv6 Only – Accept IPv6 only connections. Ignored if Local IP is IPv4.
On identity – I select one of the identities I set up earlier
Accept – defines Accept Rule for remote identities, and there are 3 options:
- Everyone -> Accept all remote identities
- Custom – regex -> complete with regexroute to match remote identity (the identity from the other network, for example: epc\.mnc002\.mnc276\.3gpnetwork\.org/)
- Custom – specific -> complete with comma separated remote identities
Default Route – Peer (connection) route priority to set for the incoming connection.
NOTE! For dual (outgoing and incoming connection) configuration for the same remote peer:
– this parameter should have the same value as configured for the outgoing connection;
– ‘Accept’ parameter should contain a single exact match for the remote peer.
Status – The status of the Listener. By disabling it, the Listener (and its associated DRA Connections in case disabled Listener is a DRA Listener) will not be included in the API configuration request.
Notes:
After an identity change on a DIAMETER connection you need to restart equipment or run following commands from telnet:
- accounts reload
- accounts login ‘account_name’
Routing Table
The last step is configuring a routing table, from the “Routing table” step in YateDRA equipment.
Equipment -> YateDRA -> Edit button ->Routing table step -> Add button
The Routing table can be asociated to a DRA or DEA identity, as I’ll present below.
Example of routing table associated to DRA identity:
[
{
"vars": {
"MY_REALM": "epc.mnc002.mcc276.3gppnetwork.org",
"MY_DRA_LOCAL_NODE": "${MY_REALM}/dra1.${MY_REALM}",
"MY_DEA_LOCAL_NODE": "${MY_REALM}/dea1.${MY_REALM}",
"MY_REALM_MATCH": "epc\.mnc002\.mcc276\.3gppnetwork\.org",
"HSS1": "${MY_REALM}/hss1.${MY_REALM}",
"UCN1": "${MY_REALM}/ucn1.${MY_REALM}",
"INTERCONNECT_REALM": "epc.mnc003.mcc232.3gppnetwork.org",
"INTERCONNECT_PEER": "${INTERCONNECT_REALM}/dea1.${INTERCONNECT_REALM}",
"INTERCONNECT_REALM_MATCH": "^epc\.mnc003\.mcc232\.3gppnetwork\.org$"
}
},
{
"realm": "^${MY_REALM_MATCH}$",
"description": "Message destination is our realm",
"routes": [
{
"host": "^$",
"cmdappid": "^(16777251|16777216)$",
"local_node": "${MY_DRA_LOCAL_NODE}",
"peer_list": {
"peers": [
"${HSS1}"
]
}
},
{
"host": "^$^",
"forward": true,
"local_node": "${MY_DRA_LOCAL_NODE}"
}
]
},
{
"realm": "${INTERCONNECT_REALM_MATCH}",
"description": "Message destination is for interconnect realm",
"routes": [
{
"description": "Peer sending the message is in our realm (internal network). Send to interconnect",
"recv_peer": "^${MY_REALM_MATCH}/",
"local_node": "${MY_DEA_LOCAL_NODE}",
"peer": "${INTERCONNECT_PEER}"
},
{
"description": "Peer sending the message is not in our network. Reject",
"error_message": "Check your routing!"
}
]
}
]
Example of routing table associated to DEA identity:
[
{
"vars": {
"MY_REALM": "epc.mnc002.mcc276.3gppnetwork.org",
"MY_DRA_LOCAL_NODE": "${MY_REALM}/dra1.${MY_REALM}"
}
},
{
"realm": "^.*",
"routes": [
{
"description": "Jump to DRA routing table",
"node": "${MY_DRA_LOCAL_NODE}"
}
]
}
]
Interconnect
4G Interconnect
Interconnect does not need a special configuration, other than checking IMS to be active on subscribers.
This is because subscribers PGW is in home network and that is where VoLTE is applied.
Subscriber Management -> Edit -> IMS calls over VolTE -> Active
SMS Interconnect
SMS Interconnect can be done over:
- MAP
- Set up as a roaming agreement where you configure linksets to another partner network.
- If you already have a roaming agreement set up with that network, then SMS would be transported over it without you needing to setup anything else (maybe just a routing rule)
- To setup the SMS Interconnect through MAP press on the left menu tab called “Roaming Partners” and follow the instructions.
- SMPP
- Set up in each YateSMSC
- You can set SMPP server / client depending on what the other end requires.
- Set the routing rules so the interconnect is used for specific MSISDN prefixes
Voice Interconnect (2G/3G)
To route to the SBC the following must be done:
- Check if there is already a SIP listener, if not we should add a SIP listener (usually it should be the gmsc listener).
- Add SIP connection to SBC for each UCN (done from Edit UCN -> Accounts):
- Name should be unique, it will be used in the script routing
- Type should be UDP
- Username and password should be the same ones configured for the SBC line.
- You should associate to the listener created before to receive calls.
- Role should be interconnect
- Add regexroute rule or JS routing script to route to SBC. We will create a JS routing script from from My Network -> Scripts
#require "lib_str_util.js"
//Contains the MSISDN(s) prefix for Home Network
//Modify this variable to set your MSISDN(s) prefix
msisdn_prefix = ["+35569"];
function callInterconnect(msg)
{
Engine.output("Entered callInterconnect");
var route_external = false;
var called = msg.called;
var i;
for (i = 0; i < msisdn_prefix.length; i++) {
var prefix = msisdn_prefix[i];
if (called.startsWith(prefix))
continue;
route_external = true;
}
if (route_external) {
//Name of the line configured n the "SIP connection" up
var res = "line/" + called;
msg.line = "sbc_conn";
msg.retValue(res);
return msg.trace(true,-1,"Call handled and routed to SBC.");
}
return msg.trace(false,-1,"Could not route.");
}
//Priority should be under 80 so the GMSC will not catch to handle call
Message.install(callInterconnect, "call.route", 75);
YateBTS online documentation
-
First time user guide for the YateMMI.
-
User Guide for equipment reconfigurationHow Yate MMI decides to reconfigure equipment
-
YateDRA documentation
-
YateSTP documentation