Kevin Smith, Chairman of NGP in 2017
The TCP/IP protocol suite has undoubtedly enabled the evolution of connected computing and many other developments since its invention during the 1970s. The Internet acts as a communications tool, an information storage and distribution tool, a marketing channel, and a sales and distribution platform, for consumers and for businesses large and small.
However, TCP/IP was designed for an age in which communication was between computers and terminals in fixed locations, and in which the user interface was text rather than dynamic media such as audio and video. Mobile operators have identified a number of problems with its use in core and access networks, and it is unsuitable for some of the new services that are proposed for 5G. Our Industry Specification Group (ISG) Next Generation Protocols (NGP) is investigating protocols that would better support the huge performance and capacity improvements planned for 5G radio.
In its first term, ISG NGP laid the foundations, identifying requirements, scenarios, and example next generation technologies. Its task is to widen industry awareness, standardize relevant specifications, validate the new protocols against near-future use cases, and compare against legacy protocols via a set of defined Key Performance Indicators.
Our Role & Activities
The Industry Specification Group on Next Generation Protocols has been set up to standardize a digital communications technology fit for the 21st century.
Our vision is a much more efficient system that is far more responsive to its users.
We have identified a number of technical issues with the current (TCP/IP-based) technology which prevent it delivering the required levels of service without excessive complexity or, in some cases, at all.
The new protocols will provide:
- virtual elimination of delays in forwarding real-world signals: not only audio and video but also tactile feedback and the position of vehicles or industrial robots, which are needed for new services proposed for 5G
- multicasting of live content (such as sports events) to an unlimited number of subscribers
- more efficient use of spectrum and of processing power
- better security, both privacy and resilience to denial-of-service
- better performance when accessing remote content such as web pages
- ways of guaranteeing network service sustainability
- extensibility: packet formats do not have to be the same throughout the system, and introducing new features such as a new kind of addressing only affects the control plane messages
What does this mean for the user?
Elimination of delays in packet forwarding equipment will make conversation more natural, especially in conference calls. A performer’s sound can be sent across the network to be mixed with other performers’ and returned to their headphones; this is not possible with IP-based systems such as the BBC’s Virtualisation of Local Radio (ViLoR) or today’s Internet. Applications such as remote surgery become possible.
More efficient processing extends battery life in handsets.
Privacy is improved: devices do not need to have IP addresses, and a server does not need to know a client’s address or location in order to reply to its request. Before any exchange of data takes place the server can require as much or as little authentication of the client’s identity as is appropriate to the application. It will be much easier to discover where your device is sending data to.
Downloads will be faster, and there will be less “buffering delay” when watching streamed content. New business models can be explored based on improved identification of content and quality auditing.
What does it mean for the operator?
The whole system becomes much simpler and therefore cheaper to build and to operate. Many middle-box functions, such as address translation, firewalls, header compression, and transport-layer optimisers, are eliminated or incorporated into the control plane procedures. Mobility is supported natively instead of needing tunnelling layers to be added.
The service for media streams provides multicasting and ultra-low latency (typically under 10µs per hop) as standard. As well as live broadcasting (such as of sporting events) it can be used to distribute recorded content to local caches and to distribute software updates.
Many of the protocols needed by current systems, such as DNS, ARP, SIP, SDP, and RSVP, are incorporated into the control plane procedures. This, along with a dramatic reduction in packet header sizes, reduces the amount of capacity on the air interface that is taken up by protocol overheads.
The forwarding plane can be implemented entirely in logic (hardware), and thus needs much less power than is needed for per-packet processing by software. Simplified protocols and elimination of the need for header compression reduce processing power requirements further.
How do we get there?
The proposed change will involve many parties aligning their agendas behind a common endeavour, so it will be vital to have political endorsement at the highest level. Ideally, there should be a critical mass of operators willing to invest on a common time scale.
The new technology can be carried over IP networks, and IP packets can be carried over the new technology. Thus, the new technology can be introduced incrementally, in the form of “islands” where internal traffic benefits from the new levels of service and there is seamless transition to the legacy technology at the edge. This can be done as part of the normal processes of expanding networks and of replacing end-of-life equipment.
An example would be where a new network is being built to support 5G: core, RAN, and MEC can be implemented with the new technology. When an application connects a socket to a service, the system can check whether that service is available at the edge and if so connect directly using the new technology. This check might need more information than would be provided in the DNS look-up used in legacy systems, e.g. to see whether a cached copy of a particular piece of content is available. Otherwise, the connection goes through the User Plane Function; much of the processing of legacy packet headers is transferred from the UE to the UPF, saving battery in the UE, and the amount of processing required in the UPF is similar to the NAT procedures common in today´s Internet access.
The target is for next-generation protocols to be supported in core and radio access networks in 3GPP Release 17.
Participation in the Next Generation Protocols Industry Specification Group is open to all ETSI members as well as organizations that are not members, subject to signing ISG Agreements. For information on how to participate please contact ISGsupport@etsi.org.
A full list of related standards in the public domain is accessible via the NGP committee page.
News from the NGP Industry Specification Group
The direct link to refer to this blog is https://www.etsi.org/newsroom/blogs/blog-ngp
IPv6 is finally beginning to be adopted, more than two decades after its specification was published in RFC 1883. Why did it take so long? And how will NGP avoid the same problems?
Internet Protocol (IP) is a "connectionless" technology, in which all the information necessary to deliver a packet to its destination must be in the packet header. This includes the destination address and the address to be used for sending a reply, as well as other information regarding the service the packet should experience. The format of this information has to be the same throughout the system, so that it can be understood by any switching equipment the packet might pass through. IPv4 and IPv6 use different formats, so if support for IPv6 is to be added to an IPv4 network, all equipment in the network must be updated so it can process IPv6 headers. Only when that has been done can IPv6 be used.
When IP was first specified, packet headers were processed at each switching point by software running in a general-purpose computer. Since then, transmission speeds have increased by more than processing speeds, so more of the processing of headers has to be done in hardware. Technologies such as Software Defined Networking (SDN) recognize that most packets are part of a "flow" such as an audio or video stream or an exchange of information between a browser and a web site; decisions about how each flow should be forwarded are made by software and loaded into a "routing table" at each of the switching points. The hardware in the switch reads the packet header and searches the routing table to find the entry that matches it.
Thus, adding support for IPv6 addresses doesn't just need a software upgrade, it needs new hardware that is able to read IPv6 headers in addition to the existing IPv4 hardware.
GS NGP 013 specifies a system (with the working title Flexilink) in which the packet header carries a "label", which is an index into the routing table, and all other information is carried in control plane messages and is thus sent once for each flow instead of in every packet: the ultimate in header compression. Routing table entries in each switch only need to show the action to be performed by that switch, typically the output port number and the label for the next hop. Supporting a new form of addressing (such as content-centric, or using a domain name directly as an address) only needs a software update to the control elements, and no change to the hardware. The packet format can be different for different kinds of link, for instance having a larger field for the label on links that can carry more flows, but this only affects equipment designed for that kind of link, which will in any case have hardware that is specific to that link type.
Any part of an IP network can be replaced by Flexilink without affecting the rest of the network. Depending on requirements, IP packets (either version) can be carried with their headers included, in the same way as over MPLS, or the headers can be stripped on entry and added back on exit. In the latter case the routing table has to hold the necessary information to construct the IP header, but if the IP network would be doing address translation a similar amount of information would need to be held in any case.
Thus with Flexilink a single hardware implementation is able to support multiple addressing schemes including both IPv4 and IPv6.
Almost every packet on a digital network is part of a "flow", a sequence of packets from the same source to the same destination. These flows are of two types:
- they either carry a continuous stream of data such as an audio or video signal
- or transfer information between processes running in computers, as in a TCP session
We can think of the former as "AV" flows and of the latter as "IT" flows. For many applications, AV flows are sensitive to "latency", which is the time between a packet being transmitted by the sender and received at its destination; in a phone call, for example, longer delays make it difficult to have a natural conversation. New applications proposed for 5G, such as those involving augmented or virtual reality, or tactile feedback, will have even more severe requirements. For IT flows, if latency is important at all it will be the average over time that matters, whereas for AV flows it is the delay for the slowest packet.
Current-generation networks were originally designed as IT networks, carrying IT flows, and have had various features added to assist AV flows, which increase complexity but still do not provide the best service for these flows.
One of the main drivers for the formation of ISG NGP was operators' need to make more efficient use of spectrum. While New Radio allows more bits to be carried, by some estimates half of those bits are unnecessary overhead. NGP is investigating how these overheads can be reduced, while at the same time providing the kind of performance (such as lower latency) that the new services proposed for 5G will need.