This post is the third in a three-part series about the financial side of things. In Part 1, talked about the systems we built for us to monitor network usage and for our users to buy and sell credit. In Part 2, we covered our operating expenses, and discussed some of the different considerations and models of how to bill users. In this part, I’m going to wrap things up by sharing some of the tricks and approaches that we can use to improve network performance and service for our users, and then providing some alternate funding models.
In our network, a huge difference exists (in terms of network performance and congestion as well as cost) between traffic that stays local and traffic that goes out over the satellite link to connect to the Internet. Though our backhaul connection from our tower to the Internet is only 1 Mbps, the fronthaul connection from phones to the tower is much higher – we’ve seen speeds of 75 Mpbs for an individual user, and LTE offers theoretical speeds of up to 150 Mbps. Local communication, like sending a file from one person to another, doesn’t actually use the satellite link at all, and works even if we get cut off from the Internet. This brings up the question of “should we offer a local-only option?”
If we do decide to provide the option of local-only service to users, we also have to figure out what it should cost. There’s one argument that says we should charge them only for power, because that’s the really the only cost service they’re using. On the other hand, there are very good reasons for us to charge them more, and put that money towards the cost of the backhaul connection. Not only does everyone in the community benefit from Internet connectivity (non-paying users often request paying users to perform services for them), but we could potentially offer “lower priority” Internet connectivity when available. Remember – because the backhaul cost is fixed per month, every second we’re not using the Internet is a second that we paid for and simply didn’t use. Moreover, putting more money towards the backhaul could result in cheaper Internet access per user, which in turn incentivizes more users to join the network and creates one of those positive cycles I talked about in Part 2.
At the same time, we’re also actively working to improve what services are “local” by hosting them within the community on our server. If Gmail struggles behind a slow satellite connection, that’s a great reason for us to host a local email server. The exact same thing could be said for higher-bandwidth services, like streaming video with our own media server, or caching web content. I’ll save this discussion for another post, but we packaged CoLTE with many such services, including OpenStreetMaps and a chat server. Going further, improving Internet/Web performance at the network edge is one of my primary research interests, and I hope to pursue this topic at a painful level of detail before too long.
In addition to a local services option, we’ve also considered a “limited services” package that provides Internet access only to a select set of websites/services at a reduced (or free) cost. This package would likely be focused around calling and texting services (e.g. WhatsApp and Skype), but could also include other select websites such as Wikipedia.
The “limited services” idea stems primarily from the observation that many of the most socially useful services are also very low-bandwidth. For example, a standard-quality VoIP call requires only 20 kbps of bandwidth, potentially less under certain conditions, and WhatsApp text messages barely any bandwidth at all (Though these conclusions are intuitive and based largely on observed experience, we’re hoping to formally quantify this traffic soon!) These characteristics stand in stark contrast to other Internet services that provide a relatively low social benefit at a much larger cost of bandwidth, such as video streaming or online gaming. This dichotomy naturally led us to discussions around the idea of “we’re not making any money off of WhatsApp anyways, so why not just give it away for free?” Going even further, I’m almost certain that we could strongly prioritize VoIP traffic such as Skype and WhatsApp, and dramatically improve the social utility of our network, without our general Internet users even noticing the difference.
Thanks For Reading!
A fascinating theme that’s emerged in this series of posts is the intersection of technical engineering, socio-economic engineering, and what’s best for the individual community. One of the major takeaways of this entire series should be that the options are literally endless – especially since when the community is it’s own ISP, their interests are perfectly aligned. As we deploy additional networks in different areas, we’re hoping to build and research literally all of these topics, with the end goal being something as close to a set of “best practices” as possible. As always, thanks for reading, and please comment or reach out if you’ve got any thoughts or questions.
This post is Part 2 in a series about money and billing. Part 1 talked about the technical system we built, and how users purchase data and transfer credit. In this post, I’m going to talk about the basic economics behind our network, including what our expenses look like, what kind of revenue we need to generate, and some different billing models and their tradeoffs.
What Are Our Operating Expenses?
Our network’s recurring costs are relatively straightforward, and consist of two main components: power and Internet backhaul – both of which are surprisingly flat in our case. With respect to power, this is somewhat obvious: the cost to keep the tower running 24/7 is fixed, and depends only on the wattage of the cell tower and the price per kWh in the community. When it comes to backhaul, I didn’t quite know what to expect, but we ended up finding a 1MB/sec (yep, you read that number right) satellite Internet connection for 300 USD/month (yep, you read that number right, too).
As we covered in Part 1, it’s super easy to figure out how many bytes a user has sent or received, and it’s easy for users to buy and sell packages… but that’s where the easy part stops. This brings us to the real question of “how do we want to charge our users?” Note that I said “how” and not “how much” because even before we talk about rates, there’s a bunch of different ways for us to do this. The two main ways we could do billing is either by the amount of data used, as I described previously, or a flat monthly membership model. However, we could also give users discounts on specific services, provide cheaper rates for larger packages, or bill local traffic differently. There’s a lot of different options here, and they’re super important because billing is our main (only) tool to incentivize and influence user behavior.
Incentivizing Network Behavior
If you’ve ever split the cost of the Internet between roommates, or shared a cell phone family plan, then you’ve faced the exact problem we’re up against. Should we just split the cost evenly, or do we make the heavier users pay more? What if someone wants faster speed than the rest of us – do we make them pay for it on their own, or do we split the additional cost because we all benefit? What if someone can’t afford the full price – do we kick them off the network entirely, or take the money that they can afford? Should we offer discount rates for using the Internet during slow times? What’s the actual cost of adding a user to the network, anyway?
The fact that our Internet cost per month is fixed makes these questions much trickier than they might be. If our backhaul was charged per-MB (as a lot of satellite connections do), we’d simply set our rates accordingly, pass the cost onto our users, and be done with it. However, since we’re paying the same monthly rate whether we use the link or not, every second the network isn’t being fully used can be considered a second of service lost. Under this line of thought, if we’re paying for it anyways, let’s use the network as much as possible – and this makes the case for subscription-based pricing that encourages full network utilization.
Unfortunately, the flip size of full utilization is congestion: if too many people want to use the network at any one given moment in time, network performance suffers and slows down for everyone. Inevitably, the best way to reduce usage is to (1) raise rates per MB and (2) bill based on data usage, rather than a flat subscription – even though both of these approaches contradict what I just wrote in the previous paragraph.
The Minimum Viable Network
First, some basic math: Assuming that we split the cost evenly between all users, a network size of ten users would mean each user pays 300 / 10 = 30 USD/month for the satellite connection. If three users decide that they can’t afford it anymore, the cost would rise to 300 / 7 = 42 USD/month, potentially driving other users off the network and raising prices further in what the insurance markets call a “death spiral.” Conversely, the opposite could also occur: if three new users decided that they could afford Internet (at an advertised price of 30 USD/month) the price would drop to 300 / 13 = 23 USD/month and potentially attract even more signups.
This idea can be reduced to what we call the “Minimum Viable Network,” defined as the minimum number of users we need to avoid that death spiral. As long as we’re above the MVN, life is good, and when more people signup we could choose to either give everyone a discount or build up our cash reserves – but once we drop below the MVN, we’ll start to see more drop-offs and a steep price increase that feeds back on itself. This, more than anything else, is the big problem of a fixed cost connection: in a pay-per-MB world, we’d see our costs naturally decrease as users leave the network, but as it stands we’re on the hook for 300 USD/month no matter how many customers we have.
Alternate Funding Models
So far, I’ve mentioned the pay-per-MB model and the monthy subscription model as our two major ways of creating revenue – but there are countless other approaches to keeping the lights on. More and more national level governments are funding/subsidising programs aimed towards connecting rural populations, such as the Universal Service Fund in the United States. Simultaneously, local governments are using taxes to build out telecom infrastructure, simply because it’s the easiest and best way to fund an infrastructural project that comes with a large range of social benefits, including-but-not-limited to education, medicine, commerce, and financial inclusion.
Wrapping Things Up
By now, hopefully I’ve made it clear that this is a challenging space that we’re working in, and provided a useful overview of the tradeoffs. There are no easy answers, and this is probably going to be a topic we explore and experiment with in-depth over our initial deployment. Stay tuned for Part 3, where I’m going to cover some other techniques and approaches that we can build to reduce congestion and cost by keeping things local when possible.
Okay, okay, let’s talk about money… everyone’s favorite topic, right? No, but seriously: In all my efforts to get CoLTE up and talking to phones, I didn’t really think about the (glaringly obvious) fact that for us to offer service to the community, we’ll have to pay for it somehow. That means building a billing platform of some sort – a task which has turned out to be both really easy and really hard.
There’s a lot of stuff to cover on this topic, so I’m breaking it up into a series of posts. This post will introduce the basic technical concepts of what we built, how we keep track of network usage, and how customers interact with our system.
Keeping Track of the Bits
One of the really neat things about LTE, as compared to other cell networks, is that in LTE, everything is just IP packets. This actually lets us dramatically simplify the technical part of our billing system: we note the IP address that we assign each use, use ntopng to keep track of how many bytes a specific IP address sends and receives… and that’s it! This takes care of data, obviously, but also does everything else. Text messages? They’re just IMS traffic from one IP address to another, and counted in the data. Phone calls? VoLTE runs over IP, done. What if a user wants to use WhatsApp or Skype instead? We really couldn’t care less – it’s all just data. Count the bytes, multiply it by the rate we choose (we’ll discuss rates in Part 2) and call it a day.
Credit Purchase and Resale
In addition to monitoring network usage, we had to create ways for users to “top up,” or put money on their account, and then purchase service with that money. In the States, accounts are typically post-paid (i.e. you get a bill after the fact) whereas in a lot of other places, including Bokondini, all accounts are only pre-paid (i.e. you pay someone for credit ahead of time, and the network cuts you off if/when you hit zero). In most pre-paid networks, users top up or transfer credit via a text message interface, or in person at a store. However, since our system is LTE, and doesn’t have to be backwards-compatible with 2G, we decided to forego the traditional interfaces in place of just running a locally-hosted website. We ended up building out this site to handle a wide range of tasks, so by going to “network.bokondini” users see a website that provides them with a wide range of information about their account (data consumed, balance remaining, connection status, etc.) and enables them to perform basic operations such as using their current balance to buy a data package.
Minutes as a “Fiat Currency”
To make matters even more interesting, pre-paid phone credit is often re-sold from one user to another, or traded for other goods and services. In Bokondini, there’s an entire retail economy of corner shop vendors that buy large amounts of cell phone credit at a bulk discount and then resell smaller portions to individual shoppers (e.g. “transfer ten dollars of credit, or 100 minutes, from my account to this phone number”) in exchange for cash.
The notion of credit resale actually makes our lives significantly easier, for two main reasons. First off, it creates a clear division between trading credit from one user to another, and “fiat”-ing new credit into the system to be traded. Obviously, the second action has to be very closely supervised, but we can get away with creating a bottleneck here (maybe we only allow one or two people to introduce new credit into the system) because the credit will then be traded and disperse through the community via these resellers.
Second off, the notion of “fiat” here makes us a lot safer and more resilient to many different scams and attacks. This is because with the one exception of creating credit, no real money ever changes hands or goes away. If one user cheats or steals from the account of another user, or hacks the system to add credit to their account, we can simply undo the transaction, or manually edit the balances ourselves: no value is ever actually lost for good.
All right – that’s enough money talk for today. Stay tuned for Part 2, coming out soon, in which I talk about the different possible billing models, what our expenses look like, and how we need to generate revenue.
One of the most interesting and hardest-to-describe things about local networks, as opposed to big-scale national ones, is exactly how they connect to the rest of the world. More than any other part of this project, the answer to these kinds of questions is “it depends!” In this post, I’m going to do my best to provide the long-form answer to this question and explain how things interconnect – in general, as well as our exact case in Bokondini.
The Internet was designed from the ground-up to be a decentralized “network of networks,” and this design makes it incredibly easy to add a network to the Internet: you pay an ISP for a connection, hook up a router to it, and you’re done! Though the scale’s a bit different, this process is pretty much identical, whether you’re hooking up a small home network or building a telecom company. This isn’t an exaggeration at all: small-scale regional ISPs literally just buy a super-fast Internet connection from a bigger ISP, the same way you do at home, and then divide and resell it to their local customer base.
In our case, the mountains around Bokondini are too rugged for traditional wired connections, so we’re using satellite Internet. Though it’ll cost us 300 USD/month for a 1Mbps connection (no joke!!!) and be pretty slow, it’s literally the only option we have.
Calls and Texts
So if hooking up to the Internet’s that easy, hooking up to the phone network’s probably similar, right? Wrong! It’s actually quite a process to register yourself as a phone network, and get assigned a block of phone numbers. This is the case for several overly-technical reasons, but the main one is that the Internet was designed to easily allow smaller networks to hook-in, whereas the telephone network (known as the PLMN, for Public-Land-Mobile-Network) grew up served by a much, much smaller number of operators. As a natural result, there’s no simple or easy system for a small network like ours to request a small set of numbers, mainly because that never happens. I’d love to learn more about this system and go through the process down the road, but for now, we currently do not have any plans to register our network in the PLMN.
Note that not having a PLMN hookup doesn’t actually affect our ability to support calling and texting, at least on a local scale. The nice thing about not being connected to the PLMN is that we can still assign our users whatever made up phone numbers they want, and we can still use these numbers for routing calls and texts within the network – we just can’t connect to the rest of the world.
Over-The-Top (OTT) Services
If hooking up to the Internet is easy, but hooking up to the phone network is hard… some of you might be thinking “why not just use the Internet for voice and text?” Great idea! In the cellular world, running voice and text over the data connection is known as “over the top” service provision, and it dramatically simplifies everything, for a number of reasons. Popular examples of over-the-top services include Skype, WhatsApp, Facebook Messenger, Google Voice, and many, many more.
There are tons of really good reasons to use OTT services: first off, they’re typically much cheaper than buying a phone plan. Second, all they need is Internet, so they work just fine over WiFi. Third, since the Internet was designed to be more decentralized than the PLMN, they don’t deal with issues like roaming.
Unfortunately, OTT services also have some drawbacks. First, whereas the telephone network is understood and supported worldwide, OTT services typically don’t interconnect with each other, which leads to complicated issues of fragmentation (i.e. you talk to John on WhatsApp, Matt on Skype, and Fred on Facebook) and a negative user experience. Second, in almost all OTT services, communication must be routed through the provider’s servers. This typically isn’t a huge problem in well-connected areas, but in our case, it means that a call from one user to another would go over that 1 Mbps satellite link twice for no good reason. Finally, and most importantly, since OTT services just do their own thing and don’t interconnect with the PLMN, they can’t support a lot of telephone-specific features such as emergency calls. This isn’t just unsafe, but actually has legal implications, and is why Skype has that big disclaimer saying “Skype is not a replacement for your phone and can’t be used for emergency calling.”
Bringing It All Together
Okay, so let’s recap: our network in Bokondini’s going to have a relatively slow and expensive satellite Internet connection. With this connection, our users can do anything they want: email, web surfing, etc. Additionally, our users can make phone calls and send texts to other users within the network, but can’t call anyone outside the network. Finally, our users can also use any Internet-based OTT services (WhatsApp, Skype, etc.) to call people outside the network.
One of the coolest and most interesting parts of building CoLTE was the process of designing and purchasing our own SIM cards (1,000 of them, to be precise). Even though the SIM cards are a relatively small part of the whole technical system, they make a great visual, especially with our own design on them. Most importantly, as physical, tangible objects, they really drive home and solidify the idea of “DIY Telecom” like nothing else can.
Where The Heck Do You Get SIM Cards?
On Alibaba.com, apparently! For those of you not in the know, Alibaba is a huge e-commerce site, based mainly in China and geared towards product manufacturers and other parts of the supply chain. It’s where you’d contract with a Chinese producer to buy (normally large) quantities of anything from custom-logo keychains to specialized electronics and machined parts. A quick search for “LTE SIMs” yielded dozens of results, which I eventually pared down to a supplier called GreenCard that appeared to be a small company based out of Shenzhen. GreenCard offered us everything we needed, all for 65 cents a SIM, minimum order size of 1,000 units.
I had never used Alibaba before, and was a little bit nervous about placing such a large order over such a far distance, getting something slightly wrong, and blowing a thousand bucks, but the process was remarkably straightforward and reassuring. The Alibaba website gives you plenty of support, and clearly spells out how to specify things correctly in your order to ensure order satisfaction and CYA in case of a dispute. The vendor I worked with was quite professional, helped me when needed, and delivered a bang-up job all the way through. All in all, the process went incredibly smoothly – the only hitch was communication took longer than I would have liked, but that’s just a time zone issue.
The Visual Design
Given that SIM cards are so tangible and user-facing (they’re literally the first and only object a user gets from their telco), we knew it was worth it to put a lot of thought and effort into the physical design, despite the risk of bikeshedding it. After a couple of brainstorming sessions oriented around themes like “empowerment,” “agency,” “local,” and more, I mocked up about ten different designs on Illustrator and passed them around. We ranked favorites, brainstorrmed some more, fine-tuned the designs, and finally settled on the final design below.
The front side is a picture that Kurtis took in Bokondini several years ago, when they set up the initial Village BaseStation network. We wanted to keep the back simple, with the W centered so that even when punched out, our cards would be instantly recognized as the “Purple SIM” or the “W SIM”. Personally, I’m really happy with how these turned out, and am already thinking about a similar design when we expand into future communities: finding a relatively local picture that highlights and emphasizes the community itself, and using that as the main front design, because when it comes down to it, that’s really what this whole project’s about.
Once we settled on a design, I thought I was almost done… right? Wrong! Turns out there were a ton of other details to take care of before we could place an order: everything from what our Public Land-Mobile Network (PLMN) ID should be to secret keys for security, PINs to lock and unlock the SIMs, even what phone numbers the SIMs should have. We were also able to set the “Network Name” that users see when they connect to our network: though it was tempting to take a page out of WiFi and come up with our best cellular-related puns, we eventually settled on a simple “Bokondini”.