Cellular Network Infrastructure » Distributed GSM

h1. Distributed GSM / Multicast MS Lookup

When building communal mobile telephony networks in rural areas, traditional

core network infrastructure poses a fundamental challenge: it is built on a

centralised paradigm and requires highly available network links at all times.

Osmocom is currently implementing Distributed GSM (D-GSM), a concept that is a

far better match for a decentralised cooperation of independent communal mobile

networks, who don't have the luxury of ultra-reliable networking infrastructure.

When several communities, who have each built their own independent mobile

network infrastructure, would like to join their services and allow calling,

messaging and Roaming across sites, the usual answer would be a centralised

gateway entity to locate subscribers, and, naturally, a central authority

governing all participating communities. That is a challenge, not only socially

and administratively, but is also quite impractical when the network links

between communities tend to be unstable or expensive.

For example, when a phone has just moved two a different coverage area, but

weather conditions impair the hypothetical wireless link to a central subscriber

database, the phone becomes unreachable, even for callers in the local vicinity

where connecting a voice call would not have posed any problem.

A solution that comes to mind is a series of mirrors of that central database,

one for each site; however, that requires database synchronisation, which in

practice leads to a considerable delay. After a subscriber has moved to a

different coverage area, it can take something like half an hour until a site

notices that a given subscriber has lost reception to its network, and until it

has synchronised that fact with other sites. For that duration, callers are

unable to get the accurate current position of the person they are trying to

reach. Imagine a subscriber located just between two coverage areas, often

switching back and forth between them at random -- service would be disrupted

probably for most of the day.

To solve these challenges, we are implementing D-GSM as part of the Osmocom CNI

stack. D-GSM is a close cooperation with/for Rhizomatica [[#Links|1]], an organization of

community owned operators providing mobile telephony service in numerous rural

communities in Oaxaca, Mexico. We are aiming to overcome common practical

problems that their current mobile networks are experiencing, improving

availability and stability. The results of this work are naturally contributed

to the Osmocom project and are freely available for anyone to use, under terms

of the GNU AGPL. The implementation of D-GSM is mostly funded by the Mozilla

MOSS grant [2], and carried out by sysmocom-employed [3] Osmocom contributors.

Thank you for making this possible!

The solution we are implementing is inspired by the actual social and physical

structure that we aim to service: each village in Oaxaca has their own fully

independent core network stack, and each community is fully in charge of their

own infrastructure. There is no central authority governing across communities,

by deliberate choice. Because the infrastructure is operated in remote rural

areas, often from a pole on a hill crest running on solar panels, and with

directional wifi over large distances, network links between villages can be

unstable.

D-GSM is a relatively simple, low impact addition to an Osmocom CNI, which is

designed to match Rhizomatica's situation:

* it de-centrally resolves the current location of a subscriber (by MSISDN or

  IMSI),

* provides service addresses to directly reach the subscriber (so far SIP, SMPP

  and GSUP; freely extendable), and

* it proxies HLR services to provide Roaming across villages.

The key technology that enables D-GSM in Osmocom is called mslookup, which is

built on multicast DNS -- quite similar to the concept of service discovery in

zeroconf networking [4].

Whenever calling or messaging a particular phone number (MSISDN), a multicast

request is dispatched to all connected sites. Each site where that subscriber

has recently been attached replies with the age of the local record, and the

youngest aged response wins.

_Figure 1: mslookup for connecting subscribers: Alice is visiting village C;

a phone call gets routed directly to her current location independently from

her resident village infrastructure_

{{graphviz_link()

digraph G {

rankdir=LR

subgraph cluster_village_b {

	label="Village B"

	ms_bob [label="Bob\n(from village B)",shape=box]

	pbx_b [label="SIP B"]

}

subgraph cluster_village_c {

	label="Village C"

	ms_alice [label="Alice\n(from village A)",shape=box]

	msc_c [label="MSC C"]

	hlr_c [label="HLR C"]

	sip_c [label="SIP C"]

}

ms_alice -> msc_c [style=dashed,arrowhead=none]

msc_c -> hlr_c [label="attached",style=dashed,arrowhead=none]

ms_bob -> pbx_b [label="call Alice"]

pbx_b -> hlr_c [label="mslookup by MSISDN",style=dotted,dir=both]

pbx_b -> sip_c -> msc_c -> ms_alice [label="call"]

}

}}

Furthermore, when a subscriber visits a site where its IMSI is not known,

mslookup can find the IMSI's home HLR location and provide Roaming service,

transparently proxying to the remote site's HLR.

_Figure 2: mslookup for Roaming: Alice visits village B; she can attach to the

local mobile network, which proxies HLR administration to her home village._

{{graphviz_link()

digraph G {

rankdir=LR

subgraph cluster_village_b {

	label="Village B"

	ms_alice [label="Alice\n(from village A)",shape=box]

	msc_b [label="MSC B"]

	hlr_b [label="HLR B"]

}

subgraph cluster_village_a {

	label="Village A"

	hlr_alice [label="Alice's home HLR"]

}

ms_alice -> msc_b -> hlr_b [label="Location\nUpdating"]

hlr_b -> hlr_alice [label="mslookup by IMSI",style=dotted,dir=both]

hlr_b -> hlr_alice [label="GSUP proxy forwarding"]

}

}}

By nature of multicast lookups, D-GSM is highly resilient against single sites

or links becoming temporarily unavailable. Service between still reachable sites

simply continues; Service to a disconnected site resumes as soon as it becomes

reachable again. Even adding a new site to the communal network is basically

done by setting up a network link with multicast routing, and by choosing

distinct naming for the local GSUP services.

OsmoHLR is the workhorse for our D-GSM implementation. In fact, no other

Osmocom CNI program's code base besides OsmoHLR itself needs to be touched for

implementing D-GSM:

* OsmoHLR answers all service endpoint requests for locally attached

  subscribers, as configured in osmo-hlr.cfg;

* For IMSIs it doesn't find in the local db (outgoing Roaming), OsmoHLR takes

  care of requesting the home HLR of the IMSI and of proxy-routing HLR

  operations there; and

* OsmoHLR answers requests for all IMSIs it finds in the local db (incoming

  Roaming).

A D-GSM enabled OsmoHLR will soon be available on the osmo-hlr.git master

branch -- the implementation is currently undergoing peer review to be merged

to the master branch.

The elements that request cross-site service for voice and SMS (currently) are:

* a custom dialplan implementation for a PBX connected to OsmoMSC via

  OsmoSIPConnector (we're using FreeSWITCH [5] in the lab), and

* a custom SMPP handler connected to OsmoMSC,

both of which are available as example implementations in osmo-hlr.git/contrib/

[6].

This list is likely to be enhanced with further example integrations, like more

FLOSS PBX integrations, or SMS-over-GSUP transport instead of SMPP. That's up to

the Osmocom community to implement and contribute. If you need more information,

take a look at OsmoHLR's user manual [7].

All of the above technology is fully functional in our lab setup right now: we

are routing Location Updating requests, calls, and SMS to the right site,

entirely without the need for centralised administrative infrastructure.

A further aim of D-GSM is providing Roaming service even though the link to the

respective home HLR is unstable or altogether down. The solution is adding a

persistent local cache to the HLR proxy, which we are going to implement next.

D-GSM is, technologically, a relatively trivial enhancement of the Osmocom CNI.

Yet it brings an entirely new paradigm to mobile core network infrastructure: It

allows independent mobile core network stacks to provide voice, SMS and Roaming

services cooperatively, without the need for centralised infrastructure or

administration authority, and is resilient against unstable network links

between sites. It elegantly provides ad-hoc service for subscribers, who are

free to move across all coverage areas, and it allows sites to dynamically join

or leave the cooperative network without the need for configuration changes nor

administrative decisions at other sites.

It also has been and is great fun to implement a versatile enhancement that, for

a change, completely surpasses 3GPP specifications, and has the potential to

change the fundamental shape of communal mobile coverage. We're looking forward

to see D-GSM in action in Oaxaca, soon.

h2. Links

* [1] https://www.rhizomatica.org/

* [2] https://www.mozilla.org/en-US/moss/

* [3] https://www.sysmocom.de/

* [4] https://en.wikipedia.org/wiki/Zeroconf#DNS-based_service_discovery

* [5] https://freeswitch.org/

* [6] Soon on the master branch at

    https://git.osmocom.org/osmo-hlr/tree/contrib/dgsm ,

    at the time of writing only on the development branch at

    https://git.osmocom.org/osmo-hlr/tree/contrib/dgsm?h=neels/dgsm

* [7] Soon from the master branch at

    https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf ,

    at the time of writing only on the development branch at

    https://git.osmocom.org/osmo-hlr/tree/doc/manuals/chapters/dgsm.adoc?h=neels/dgsm