1 Introduction. 2 Assumptions. Implementing roaming for OpenBTS

Transcription

1 Implementing roaming for OpenBTS 1 Introduction One of the main advantages of OpenBTS TM 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 CAMEL is not used. In fact, this mostly eliminates the value. Meanwhile this functionality will be added later on, and it is reflected in scenarios below: one can use MAP without CAP, while CAP is useless if MAP is not supported. So, CAMEL implementation is just the next phase. ISUP can be replaced with SIP for call control purposes. This is not an issue, cause SIP-to-ISUP conversion is a common practice at PSTN GSM authentication is skipped (IMSIs are trusted) and no encryption is used. The only reason is to focus at GSM core signaling and to reduce the initial amount of code, while there are no obstacles to use both OpenBTS features. MAP version negotiation is skipped, MAP v3 is everywhere 1/5

2 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. SIP registrar will supply multiple triplets per a request. 2/5

3 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 As shown at fig.2, SIP Registrar detects a roamer and allows IRGW to perform the sequence. After the procedure performed, IRGW will have both a set of triplets and the knowledge about location. 3/5

4 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 Moved Temporary at the 7-th step will be replaced with INVITE, so IRGW will be able to control each phase of a call. 4/5

5 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 I'll appreciate any comments. Hope to start implementing Roaming when there will be enough time for it Open source version of handover is supposed to be finished. Dmitri Soloviev, Ph. D /5