While at times the 5G stories take on an almost myth-like nature, the basics underneath 5G are concrete changes in the technology and our increasing needs for communication. The traffic growth for both our smartphones and homes continues to be exponential. And as organisations and societies increasingly connect their systems, there are also many new needs.
5G responds to these needs with new radio technology and a core network that employs state-of-the-art network technologies such as an increased use of cloud, virtualisation, and open source components and processes. From a standards perspective, the timelines for the first systems are very near. The 5G work happens to a large extent in 3GPP, as did previous generations. The work on 5G is planned to take place in two releases, of which the first one is Release 15, scheduled to be stable and all protocols completed latest by September 2018, just 14 months away. Additional work will be done in Release 16, which will complete by March 2020.
What is 5G?
But what exactly is 5G then? First, it is a new, very capable radio. With beamforming, MIMO antenna technology, and frequency bands reaching to millimeter waves, it provides both higher transmission speeds and serves more users at the same time. The new radio is also needed to serve mass deployment of networked sensors, and to enable various mission-critical services that may require better latency or reliability characteristics. 5G radio can provide speeds in the Gigabit range, up to 10 Gbps or even beyond, although for large numbers of users the speeds are lower, but still target at least tens of megabits per user, for tens of thousands of users.
Second, 5G targets a set of use cases, such as the familiar mobile broadband use case. But 5G is also intended to open the use of communication and cellular networks for many new industries. The goal is to be able to tailor communication platform for a wide range of different services, ranging from low power IoT devices to self-driving cars, from mission critical public safety communication to providing services to energy providers. any of these use cases were hard to provide with previous generation technologies. For instance, one use case is about controlling remote machinery — an example of a service that benefits from lower latencies that 5G provides. There is also a higher demand on flexibility and configurability/orchestration.
From an IP networking perspective, as noted, 5G follows the same evolution as the rest of the networking industry. From a practical perspective, this is a big change, however, and requires effort. The work on details is ongoing for Release 15, but architecturally, the key directions are clear.
To give a few practical examples, interfaces to the devices are relatively similar to those in 4G. One difference is an ability to place different devices in different virtual networks or “slices”, which can be tuned and evolve independently from each other, both in resources and networking technology behind. Another difference to 4G is that the 3GPP security group plans to enable a more flexible authentication framework for the devices. And some of the control protocols inside the network may be changed from DIAMETER-based ones to REST-based APIs. From what we understand, the tunneling-based architecture for mobility is not changing, but of course with most services being provided in virtualised environments, the tunnel endpoints may physically reside in different places.
It should also be said that 5G is not a replacement for Internet-based services or Internet technology: majority of the traffic that 5G will carry is for the usual Internet services, like videos from content providers. 5G is also not immune to impacts from Internet evolution. For instance, we’ve seen big changes in use of encryption in the Internet, transport protocols are evolving, the use of CDN systems is growing, and all networks are becoming virtualised, software-defined, and cloud-resident systems. 5G networks need to serve the Internet that continues to evolve in this manner.
Is there an IETF connection?
It is useful to understand how 5G affects Internet technology. IETF work has been and will be affected by 5G. To begin with, the IETF works on many of the general facilities that modern networked systems such as 5G are based on.
Conceptually, one can think of the interactions as falling in the following categories:
- New dependencies on existing IETF technology. For instance, the flexible authentication framework mentioned above is EAP (RFC 3748, RFC 5448). This is likely to be merely a reference to existing RFCs, or if additions are needed, they are small.
- Dependencies to ongoing work at the IETF. This includes various general facilities as noted above, but also other things. For instance, the IETF DETNET working group defines mechanisms to guarantee deterministic delays for some flows across a network. As one of the 5G use cases is time-critical communication and low-latency applications, this is a component technology that is being looked at. Similarly, IETF routing-related work such as traffic engineering, service chaining and source routing are likely tools in managing traffic flows in 5G networks.
- Topics where there is clear demand for a feature, but it is unclear whether changes to Internet technology are needed, or the details remain to be determined. For instance, in the upcoming IETF meeting in Prague, we will be discussing whether some additional support is needed for what is in 5G called Network Slicing. There are many IETF tools, however, for dealing with virtualisation and separation of networks, so first order of business is probably mapping what can be done with those tools.
- Larger, architectural changes, e.g., “future Internet” type solutions such as ICN (Information Centric Networking) are sometimes suggested also in the context of 5G. While these are perhaps unlikely in the first release of 5G, it is of course certain that the evolution of the Internet continues (and there will be future releases of 5G standards as well).
We asked Gonzalo Camarillo and Georg Mayer (liaisons between 3GPP and IETF) about collaboration between IETF and 3GPP. They said that our best approach is to ensure that the 3GPP engineers are involved in the IETF work they are interested in. And that 3GPP states clearly what their requirements (rather than solutions) are. They also noted that the work in 3GPP is ongoing. Hence completing protocol requirements for 5G will still take some time. Gonzalo and Georg will be contacting the relevant parties on both sides to keep us in sync.
Exchange of information would also benefit from informal collaboration, for instance through Internet technology experts working with the 3GPP community. This enables common topics to be easily discussed and brought forward.
We should also note that there are clear boundaries between the two organisations. The IETF works on Internet technologies which may or may not get used in different networks. 3GPP puts together systems, architectures, and designs protocols specific to their networks and layers. The IETF is not in charge of making system level or requirement decisions for the 3GPP. Similarly, 3GPP leaves the evolution of Internet protocols to the IETF.
Also, recently Alissa Cooper, Chair of the IETF, visited a 3GPP meeting. Her report is here.
Finally, it should be noted that many of the existing tussles in the Internet continue to exist with 5G. For instance, the ability to provide a highly dynamic and programmable radio environment continues to present opportunities for collaboration between networks and applications. Such collaboration is not something that has historically been easy in the Internet, however. When we discussed this as a part of the growing use of encryption, the necessary changes to network management practices due to the encryption changes caused pain for operators. Perhaps as some time has passed, and networks continue to evolve, we could consider network – application collaboration as an opportunity and ask what useful things networks can do for applications?