Sometimes the future is clear. It may take a while to arrive. And it may come buried in a sea of diagrams and acronyms, but it is so clear that all of the technical details make sense and the acronyms almost decode themselves. Case in point – this 3,400 word blog from AWS (with a clear write-up from Mike Dano at Heavy Reading).

Here, the AWS team is detailing their solution for one customer – DISH Network and their 5G cellular network. It is fairly rare for AWS to provide this level of detail on the solution for a single, named customer. That, combined with the amount of effort it took to write (the post lists five fairly senior authors), is a clue to how important this is for AWS. They want to see how ‘straightforward’ this implementation is.

Put simply, DISH is building almost their entire core network on Amazon servers. We have detailed in several past notes (and here and here), the way in which wireless operators are taking themselves apart at the seams and moving much of their network to the public cloud providers. We have also repeatedly mentioned (and here) the extent to which Amazon, Microsoft and Google have all been boosting their telecom cloud capabilities. Now we have a clear example of what this looks like, in fairly crisp detail.

We have read the AWS blog several times, and have gotten our arms around it. Sort of. At least to the extent that we have walked into a vast, dark cavern and flashed a light around it enough to know how large that cave is. We have also read several analysis online about this. To mix metaphors, like blind men groping an elephant, we now have a sense of what several good analysts view as the highlights.

A few things stood out to us. First and foremost, the way that DISH and AWS have shaped their installation to resemble the structure of a typical telco network, at least on paper. Traditional operator networks have three layers – the base stations and their controllers (aka the RAN); a regional switch, and then a central switch or router. DISH has mapped that to AWS’s Availability Zones (AZ), Regions and a National region, respectively. This is not really how software applications are usually deployed on AWS, but makes sense given telcos’ need to be available across wide geographical regions. It is also important to point out that at the most local level (i.e. the 5G “base station”) the relevant software is run inside DISH’s premises, presumably at the tower. All this does open the question as to how applicable this solution will be in smaller countries with few or no Amazon AZ and regions.

Second is the degree of redundancy. The authors, repeatedly go out of their way to point out fail-over features of their architecture. With the solution running on multiple AZs in one region, for instance. We suspect that this is a bit of over-engineering. Telcos like to talk about their “six nines” level of reliability. Like all cloud service providers, AWS has its occasional outage, but when this happens to regulated telcos, they end up having to testify before Congress. So the need for redundancy is real, but it will be interesting to see what happens to DISH’s operations the next time AWS suffers an outage.

Third, it is not lost on us that DISH already operates a national network for its satellite TV service. That does not have the same nationwide localized footprint, but presumably they already have a fairly robust core network. Given that DISH is providing the local footprint for its wireless network anyway, theoretically DISH could have built all of this themselves. The fact that they chose to build on AWS instead speaks volumes about the economics of this approach.

Finally, the authors of the post speak to the overall design goals for their solution, but do not really address the underlying reason for building it. As with our question above about the economics, we would have liked to hear more about what is this all for? The Heavy Reading post we linked to above, points to the flexibility of bringing new services to the network. This jibes with our intuition behind all this. If you read between the lines of the AWS post and use a telecom decoder ring, you can find many, many hints about this – flexibility, cloud deployment, latency.

In our next piece, we will dig into this subject further.

Photo by C Dustin on Unsplash