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 |