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