A Quick Primer on 5G

The basics:

There is an increasing need for mobile data (the amount of mobile data used in the US is up 4x since 2014 and 40x since 2010) but the existing spectrum doesn’t have enough bandwidth to support a lot of additional traffic. 5G will be on a new, uncongested spectrum at a higher frequency (higher frequency = the wavelength is shorter so signal travels faster).  

Existing mobile communication is commonly at 2.X GHz and mostly below 6 GHz, where wavelength is ~10 cm. 5G will be somewhere between 30-300 GHz where wavelength will be between 1-10 mm (called millimeter wave, written mmWave). The FCC’s current plan is to make available 2.75 GHz of spectrum in the 26 GHz (11 mm wavelength) and 42 GHz (7 mm wavelength) bands.

On a sunny day in rural Virgina, a mmWave at 73 GHz can travel more than 10 kilometers.  mmWave is very affected by obstacles such as buildings or rain (because the wavelength is shorter than traditional spectrum). In rain, the signal strength of a mmWave at 28 GHz halves every kilometer and at 73 GHz decreases 100x at every kilometer.

The answer to this is to have more cell stations that can transmit signal. There are currently ~320K cell sites in the US. This should increase for 5G to an estimated 1.2M. Small cells are roughly the size of a wi-fi router and may be installed both outdoors and indoors.

A 4G base station typically has 12 antenna: 4 receivers and 8 transmitters. Each antenna is about a meter long. 5G small cells will have ~100 antenna, each can be about 20 cm tall.

Today’s antennas broadcast transmissions in multiple directions, but with more antennas, this will become too much interference, so part of 5G is beamforming algorithms that determine the direction an antenna should send a signal towards. The dream scenario here is that engineers will be able to design signal processing algorithms that know exactly what direction to send a signal so that it bounces off walls and exactly ends up at the end user device.

The last part of 5G is Full Duplex which means that an end user device can transmit and receive signal on the same frequency at the same time. (The current system where a device can only do one at a time is called Half Duplex). To do this you need to design a circuit that both routes incoming and outgoing frequency around each other and cancels out the echo from incoming frequency. There’s been research about how to do this since the 1960’s and was finally done on a chip small enough to fit in a phone in 2016 at Columbia University. (That team started a company called MixComm to bring their circuit design to market).

What 5G does not address is the networking layer. One of the big questions last week at the RCN Wireless workshop was whether TCP was going to be a bottleneck in 5G mobile speeds. TCP was designed in the 1980’s for fixed wired machines and there are two challenges for mobile (John Graham-Cumming wrote a great blog post describing these in detail).

The first is that a TCP connection starts slowly and gradually transmits at higher rates until it finds the maximum speed it can transmit at (this process is called TCP slow start). The way TCP congestion control algorithms decide the max rate is by checking for packet loss. In a fixed, wired connection, packet loss is a good indicator of max speeds because is shows that a machine on the network had to drop packets to keep up with the inbound rate. In mobile, there are other reasons why packets would get lost that have nothing to do with speed, for example - driving through a tunnel. As one possible solution, Google has developed a new congestion control algorithm called BBR that uses RTT rather than packet loss as a measurement of latency.

The other problem for TCP on mobile is in packet reordering. A mobile phone moves around, so half of the packets of a TCP connection could be sent to one cell site and the other half to another. Then when the packets reach the end server they can be really out of order. TCP can deal with this, but wasn't designed for packet reordering at this magnitude and it adds some latency.

ERC-948

Most of the apps we interact with in web2 are subscription based (Gartner thinks 80% of apps will be subscription services by 2020), but subscriptions still aren’t possible in web3. Broadly there are two limitations:

  1. Volatility: A user cannot agree to pay x tokens per month because the value of x tokens could vary wildly month to month.
  2. User action: With ERC-20, a user would have to actively sign transactions every month in order to be charged for the monthly subscription.

What this means is that a decentralized Dropbox today wouldn’t be able to bill its users on a monthly fee. There is a hacky way to do it: a decentralized Dropbox could ask the user to put up a year’s worth of tokens into escrow and each month take some of the tokens out from escrow, but that’s not a great user experience. 

There are two projects working together towards a solution (ERC-948): Groundhog and 8x. Their solution (still in development) would theoretically create a new standard for smart contracts so that users could allow X tokens to be withdrawn from their wallet every Y time period by Z business and that would allow the user to cancel at any time. The goal is for this solution to be compatible with ETH and any ERC20 token. To solve for volatility, businesses could charge for their subscription using a stablecoin.

Once wallets and dapps have added support for one recurring payment standard, it will be extremely difficult to get them to add support for another one, so I consider this a Very Important Project in that it's important to get the standard right the first time. 

To contribute, join the conversation here https://github.com/ethereum/EIPs/issues/948 or make a PR here https://github.com/8xprotocol/standard/blob/8x-suggestions/standards/8x.md.
 

Request For Project: Standardized Wallet Protocol

The current state of the web3 world is such that:

Your browser has a wallet (Metamask).
Your mobile browser has a wallet (Toshi).
Your finance apps all have wallets (Coinbase, Robinhood, Square Cash).
And all of these wallets need to be separately topped up,
Which is kind of like having a different metro card for every line of the NYC subway.

And so my Request for Project is for a unifying wallet protocol.
That encompasses tokens and collectibles, as well as identity and account recovery.

So that if you buy a cryptokitty on your laptop, you can use it right away to play games on your phone.
And if you buy some ETH on Coinbase and then login to Square Cash, your ETH would be there.

Quite eager for this to exist.