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