Money Matters (Part 2)

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).

Billing Models

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.

 

Money Matters (Part 1)

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.

all3.png

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.

 

Connecting To The Outside World

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.

Internet Access

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.

Ordering SIM Cards

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.

sim card 确认稿 20180228.jpg

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.

Technical Bits

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”.

 

Introducing CoLTE!

Hi everyone! My name’s Spencer, I’m a postdoc at the University of Washington, and I’m super excited to introduce the Community LTE Project (CoLTE, pronounced colt-ee). I’ll be writing about CoLTE a lot over the coming years, with two main goals. First, we want to keep everyone informed of the project development, major milestones, and community engagement efforts. Second, we’re going to be sharing the story of building and deploying a rural community-run LTE network in Bokondini, Indonesia.

The writing here should be pretty casual – our target audience is everyone, regardless of technical savvyness. We want everyone who’s interested in this project to understand and follow what’s going on: whether you’re a friend, web developer, network technician, VC, or community member, if you’re interested in CoLTE, we want you to know about it! In this first post, I’m going to tell you all about this project, what led to it, where it’s at now, and where we’re headed.

What is CoLTE?

The Community LTE Project is a new approach to high-speed, LTE cellular networking that is decentralized, democratic, and community-based. The goal of CoLTE is to empower anyone (and we mean anyone!) to start their own small-scale cellular network, for fun, profit, or both. Install CoLTE, hook it up to a radio, distribute SIM cards, turn the network on, and watch phones connect. Our goal is for the whole process to be as straightforward as hooking up a WiFi router: a little bit technical, but totally doable for a regular person, and hopefully easier than setting the clock on your VCR.

From a more-technical perspective, CoLTE is a set of many different software packages (all open source!) that we’ve integrated into a single platform that works nicely together. Everything from the “guts” of the network (LTE attach, security, mobility, etc.) to network management and billing are all taken care of, and each component can be turned on, turned off, or replaced without disrupting the other parts. We’ll have a more detailed technical breakdown of this very soon, so stay tuned.

What’s the point?

The core goal of the CoLTE project is to empower individuals and communities to connect themselves to each other and the global Internet. Right now, approximately four billion people (slightly over half the world’s population!) don’t have any Internet access at all. This population is primarily located in rural and remote areas, where infrastructure is more difficult and expensive to install and maintain. Combine these increased costs with decreased revenue due to lower population density, and it’s no surprise that large telecom companies and ISPs don’t want to invest.

To make headway on this problem, we have to ensure that these incentives are taken into account. Our stance is that if a community wants Internet access, the best way for them to get it is for them to literally form a local telecom company and connect themselves. This ensures that incentives are aligned, keeps value within the local community, and empowers local actors to develop a relationship with their network infrastructure. To this effect, the best thing that we can do to support this effort is to build tools that help, enable, and empower these communities as they connect themselves.

How are things going right now?

Right now, we’re hard at work on three main thrusts: the network core, the peripheral web services, and the production environment.We’ve still got plenty more work to do, but the main parts are all operational, and we finally got everything working last week. Additionally, we’ve been coordinating with some folks on the ground in Bokondini, and are making plans to stand up our network there in Summer 2018. Over the next couple of weeks, I’ll be writing in greater detail about each of these efforts, and chronicling our day-by-day process as we start bringing extra services online and getting everything ready for production.

How can I get involved?

Rural Communities: We’re currently looking to partner with rural communities that are underserved by traditional Internet providers. Does your community not have Internet access? Does it want Internet access? We want to hear from you! Use our contact page to get in touch.

Network Operators and Developers: Want to play around with our stack? Curious about our network architecture, or think it might be a good fit for you? Want to contribute to the project or get involved? Contact me, explore our site to learn more, and check out our Github here.

Friends: Drop us a line, spread the word, and stay tuned for more adventures. Thanks for reading, and until next time, here’s a couple of pictures of our day-to-day work.

IMG_20180515_163606074.jpg
Our basic testbed on my desk, much cleaner than usual
IMG_20180515_164310540.jpg
One of the commercial-grade base stations we’re taking to Bokondini
IMG_20180410_135202429_HDR.jpg
Our custom-made SIM cards!
IMG_20180523_142511916 (1).jpg
The mega creepy soundproof and RF-shielded chamber I run radio tests in