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.