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