Implementing roaming for OpenBTS
1 Introduction
One of the main advantages of OpenBTSTM system architecture is absence of a legacy GSM core network. SIP is used for
registering, call control and messaging. Such an approach allows easily perform test calls in the lab and mostly eliminate the cost of the core network while deploying. Lack of E1 interfaces and various GSM nodes (BSC, MSC, HLR, SCF etc) is an advantage for greenfield cases, while it makes impossible to integrate OpenBTS system into existing GSM world.
ETSI specifies a list of GSM core network elements and their performance. A set of sophisticated signaling protocols called SS7 is used for interfacing. A subset of protocols varies depending on the network element.
GSM Mobile Application Part (MAP) is one of the application level protocols that is the must for roaming. In the case of roaming it determines transactions between HLR/AUC, MSC/VLR, SMSC and USSD servers. Another application protocol is CAMEL (Customized Application for Mobile Enhanced Logic) or CAP (CAMEL Application Part), that extends GSM core network performance and introduces IN (intelligent Network) philosophy.
When discussing GSM roaming technical implementation, we must separately discuss 2 cases: allowing OpenBTS subscribers to roam and serving foreign subscribers in OpenBTS network.
In the first case, at least GMSC and HLR/AuC elements must me implemented and corresponding MAP procedures supported. In the second case, our MSC/VLR must be reachable from outside world. If CAMEL is used, first case must be extended with SCP (Service Control Point), and the second one requires MSC to act as SSP (Service Switching Point). We should also mention that MAP is just the upper layer protocol that requires a complete SS7 stack to be supported, including SS7 MTP (2 layers: link and network), SCCP and TCAP.
Another architectural issue worth mentioning is SIP registrar, that currently unites functionality of both legacy HLR and VLR. Meanwhile their goals are different, and the related procedures are defined in GSM documents. Currently SQLite DB of the registrar is used by Asterisk/FreeSWITCH scripts for routing, to convert MSISDN to OpenBTS ip. This works fine while a system is isolated, but as soon as foreign subscribers will appear and home subscribers will start roam, such a mixture will be a bottle neck.
2 Assumptions
As the first step towards a legacy GSM world, few MAP scenarios are needed for both incoming and outgoing roaming. So, let us initially initially assume that:
• only voice calls and SMs are served • supplementary services are not supported
3 Changes to existing system
As mentioned earlier, it seems reasonable to keep all the advantages of the system in hand.
The only change we need is to move MSISDN-to-IMSI translation closer to SIP Registrar. This also allows to reduce custom scripts from Asterisk/FreeSWITCH. SIP PBX will route INVITE to the updated node, that will reply with
SIP 302 Moved Temporary, providing IMSI and redirecting a call to the particular OpenBTS instance (fig.1).
Fig.1 SIP-based MSISDN-to-IMSI translation Other changes are required to support roaming related procedures.
We are introducing two logical elements:
• Incoming Roaming Gateway (irgw) to allow foreign subscribers to use our network resources, • Outgoing Roaming Gateway (orgw) to let our subscribers to roam
An updated SIP Registrar must get the knowledge about own MCC and MNC, and route registration attempts of foreign IMSIs to IRGW.
4 Incoming Roaming Architecture
GSM MAP defines about 80 services, while the key to understand them is MT call. Let us follow both registration and MT call setup procedures for a (foreign) roamer.
4.1 Incoming Roaming. Registration.
Fig.2. Registering a roamer
4.2 Incoming Roaming. MT call
As mentioned earlier, MT call is one of the key GSM scenarios. In a legacy world, each VLR has a set of E.164 numbers, that are dynamically allocated during call setup.
Please find MT call scenario at fig.3. Asterisk/whatever-else knows E.164 numbering range that is allocated for VLR activities.
Fig.3 Incoming Roaming, MT call setup
So, IRGW is a VLR for roaming. Later on, when CAMEL SSF (service switching function) will be implemented, SIP 302
5 Outgoing Roaming
Outgoing roaming implementation is quite native for OpenBTS. ORGW is treated as an ordinary BTS. When a mobile is registered outside a home network, OpenBTS considers that a MS is located at ORGW (fig.4).
Fig.4 Outgoing Roaming, MT call setup
