Project

General

Profile

News post draft 2019-11-25 » History » Version 6

neels, 11/25/2019 01:31 AM

1 1 neels
h1. Distributed GSM / Multicast MS Lookup
2
3
When building communal mobile telephony networks in rural areas, traditional
4
core network infrastructure poses a fundamental challenge: it is built on a
5
centralised paradigm and requires highly available network links at all times.
6 4 neels
Osmocom is currently implementing Distributed GSM (D-GSM), a concept that is a
7
far better match for a decentralised cooperation of independent communal mobile
8
networks, who don't have the luxury of ultra-reliable networking infrastructure.
9 2 neels
10 1 neels
When several communities, who have each built their own independent mobile
11
network infrastructure, would like to join their services and allow calling,
12
messaging and Roaming across sites, the usual answer would be a centralised
13
gateway entity to locate subscribers, and, naturally, a central authority
14
governing all participating communities. That is a challenge, not only socially
15
and administratively, but is also quite impractical when the network links
16
between communities tend to be unstable or expensive.
17
18
For example, when a phone has just moved two a different coverage area, but
19 5 neels
weather conditions impair the hypothetical wireless link to a central subscriber
20 1 neels
database, the phone becomes unreachable, even for callers in the local vicinity
21 3 neels
where connecting a voice call would not have posed any problem.
22 1 neels
23 3 neels
A solution that comes to mind is a series of mirrors of that central database,
24
one for each site; however, that requires database synchronisation, which in
25
practice leads to a considerable delay. After a subscriber has moved to a
26
different coverage area, it can take something like half an hour until a site
27
notices that a given subscriber has lost reception to its network, and until it
28
has synchronised that fact with other sites. For that duration, callers are
29
unable to get the accurate current position of the person they are trying to
30
reach. Imagine a subscriber located just between two coverage areas, often
31
switching back and forth between them at random -- service would be disrupted
32
probably for most of the day.
33
34 5 neels
To solve these challenges, we are implementing D-GSM as part of the Osmocom CNI
35
stack. D-GSM is a close cooperation with/for Rhizomatica [1], an organization of
36
community owned operators providing mobile telephony service in numerous rural
37
communities in Oaxaca, Mexico. We are aiming to overcome common practical
38
problems that their current mobile networks are experiencing, improving
39
availability and stability. The results of this work are naturally contributed
40
to the Osmocom project and are freely available for anyone to use, under terms
41
of the GNU AGPL. The implementation of D-GSM is mostly funded by the Mozilla
42
MOSS grant [2], and carried out by sysmocom-employed [3] Osmocom contributors.
43
Thank you for making this possible!
44 1 neels
45
The solution we are implementing is inspired by the actual social and physical
46
structure that we aim to service: each village in Oaxaca has their own fully
47
independent core network stack, and each community is fully in charge of their
48
own infrastructure. There is no central authority governing across communities,
49 5 neels
by deliberate choice. Because the infrastructure is operated in remote rural
50
areas, often from a pole on a hill crest running on solar panels, and with
51
directional wifi over large distances, network links between villages can be
52
unstable.
53 1 neels
54 6 neels
D-GSM is a relatively simple, low impact addition to an Osmocom CNI, which is
55 1 neels
designed to match Rhizomatica's situation:
56
57
* it de-centrally resolves the current location of a subscriber (by MSISDN or
58
  IMSI),
59
* provides service addresses to directly reach the subscriber (so far SIP, SMPP
60
  and GSUP; freely extendable), and
61
* it proxies HLR services to provide Roaming across villages.
62
63
The key technology that enables D-GSM in Osmocom is called mslookup, which is
64
built on multicast DNS -- quite similar to the concept of service discovery in
65
zeroconf networking [4]. Whenever calling or messaging a particular phone number
66
(MSISDN), a multicast request is dispatched to all connected sites. Each site
67
where that subscriber has recently been attached replies with the age of the
68
local record, and the youngest aged response wins. Furthermore, when a
69
subscriber visits another village and attaches to the local service, mslookup
70
can find the IMSI's home HLR location and provide Roaming service, proxying to
71
the remote site's HLR.
72
73
By nature of multicast lookups, D-GSM is highly resilient against single sites
74
or links becoming temporarily unavailable. Service between still reachable sites
75
simply continues; Service to a disconnected site resumes as soon as it becomes
76
reachable again. Even adding a new site to the communal network is basically
77
done by setting up a network link with multicast routing, and by choosing
78
distinct naming for the local GSUP services.
79
80
OsmoHLR is the workhorse for our D-GSM implementation:
81
82
* OsmoHLR answers all service endpoint requests for locally attached
83
  subscribers, as configured in osmo-hlr.cfg;
84
* For IMSIs it doesn't find in the local db (outgoing Roaming), OsmoHLR takes
85
  care of requesting the home HLR of the IMSI and of proxy-routing HLR
86
  operations there; and
87
* OsmoHLR answers requests for all IMSIs it finds in the local db (incoming
88
  Roaming).
89
90
In fact, no Osmo-Programs' code bases besides OsmoHLR itself need to be touched
91
for implementing D-GSM. A D-GSM enabled OsmoHLR will soon be available on the
92
osmo-hlr.git master branch -- the implementation is currently undergoing peer
93
review to be merged to the master branch.
94
95
The elements that request cross-site service for voice and SMS (currently) are:
96
97
* a custom dialplan implementation for a PBX connected to OsmoMSC via
98
  OsmoSIPConnector (we're using FreeSWITCH [5] in the lab), and
99
* a custom SMPP handler connected to OsmoMSC,
100
101
both of which are available as example implementations in osmo-hlr.git/contrib/
102
[6].
103
104
This list is likely to be enhanced with further example integrations, like more
105
FLOSS PBX integrations, or SMS-over-GSUP transport instead of SMPP. That's up to
106
the Osmocom community to implement and contribute. If you need more information,
107
take a look at OsmoHLR's user manual [7].
108
109
All of the above technology is fully functional in our lab setup right now: we
110
are routing Location Updating requests, calls, and SMS to the right site,
111
entirely without the need for centralised administrative infrastructure.
112
113
A further aim of D-GSM is providing Roaming service even though the link to the
114
respective home HLR is unstable or altogether down. The solution is adding a
115
persistent local cache to the HLR proxy, which we are going to implement next.
116
117
D-GSM is, technologically, a relatively trivial enhancement of the Osmocom CNI.
118
Yet it brings an entirely new paradigm to mobile core network infrastructure: It
119
allows independent mobile core network stacks to provide voice, SMS and Roaming
120
services cooperatively, without the need for centralised infrastructure or
121
administration authority, and is resilient against unstable network links
122
between sites. It elegantly provides ad-hoc service for subscribers, who are
123
free to move across all coverage areas, and it allows sites to dynamically join
124
or leave the cooperative network without the need for configuration changes nor
125
administrative decisions at other sites.
126
127
It also has been and is great fun to implement a versatile enhancement that, for
128
a change, completely surpasses 3GPP specifications, and has the potential to
129
change the fundamental shape of communal mobile coverage. We're looking forward
130
to see D-GSM in action in Oaxaca, soon.
131
132
[1] https://www.rhizomatica.org/
133
[2] https://www.mozilla.org/en-US/moss/
134
[3] https://www.sysmocom.de/
135
[4] https://en.wikipedia.org/wiki/Zeroconf#DNS-based_service_discovery
136
[5] https://freeswitch.org/
137
[6] Soon on the master branch at
138 2 neels
    https://git.osmocom.org/osmo-hlr/tree/contrib/dgsm ,
139
    at the time of writing only on the development branch at
140
    https://git.osmocom.org/osmo-hlr/tree/contrib/dgsm?h=neels/dgsm
141 1 neels
[7] Soon from the master branch at
142 2 neels
    https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf ,
143
    at the time of writing only on the development branch at
144
    https://git.osmocom.org/osmo-hlr/tree/doc/manuals/chapters/dgsm.adoc?h=neels/dgsm
Add picture from clipboard (Maximum size: 48.8 MB)