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