The main intent of the mobile industry's fourth generation (4G or LTE) was access to the Internet, so it was based on TCP/IP, the packet routing technology that is used in the Internet. However, this has caused a number of problems for network operators, and is not fully able to support some of the new services proposed for the next generation, 5G.
One problem is the size of packet headers; the overheads are typically 100% on average (more for small packets such as voice samples). The first phase of 5G has concentrated on "new radio", getting more bits over the air interface, but there is also a recognition that those bits will need to be used more efficiently. "Header compression" can be used to reduce the size of headers in some circumstances, but it increases power consumption (and hence decreases battery life) in mobile devices.
Another problem is that an IP address doesn't identify a piece of equipment (such as a phone) but its point of attachment to the network, which changes when it moves to a different cell. To get around that, IP-in-IP tunnels are used, adding further headers to each packet and adding complexity to the routing system. Other proposed solutions, such as location/identifier separation, also require additional headers.
5G networks are intended to support applications that need to be able to send live media such as audio, video, and new forms such as tactile feedback, with a latency (the time each packet takes to get from sender to recipient) of around 1 ms. This requires elimination of queuing delays in packet routing equipment; for the lowest latency, transmission opportunities must be scheduled, and network equipment synchronised, so that each packet can be forwarded with minimum delay. Retrofitting this capability to IP networks would add more complexity.
With the introduction of Multi-access Edge Computing (MEC, previously Mobile Edge Computing), less of the traffic on 5G networks will go via the Internet, so there is less rationale to use TCP/IP.
The network's job is to get packets from the sender to their destination. Where the packets carry a signal such as digital audio, they will form a stream with packets being sent at regular intervals; an appropriate service would allow resources to be reserved along the route, so that the packets are not delayed by other traffic sharing the same link. If this reservation is in the form of a schedule, the packets do not need to include any addressing information as they can be identified by their time of arrival, and the routing table simply lists, for each outgoing slot, from which incoming slot to copy the packet. This makes the forwarding process very simple.
Other kinds of data will need to be sent at unpredictable intervals, so it is not possible to reserve resources for it. However, most packets are still part of a "flow", such as a TCP session. Even in the case of UDP, where there is no "session" as such, an application will typically create a "socket" and associate it with a remote application with which it will then exchange several packets. It sends each packet by handing over to the operating system the data to be sent and a local "handle" which identifies the socket. The operating system adds the UDP, IP, and Ethernet headers, and sends the packet to a switch which then typically collects information from several places in the headers to identify the flow and guess what kind of service it needs, and find a suitable route towards its destination. It would more efficient, and more secure, to establish the route when the application creates the socket (rather than when the first packet is sent), and for the packet header to simply contain a handle (or "label") which identifies the flow. At each switching point, the label can be used directly as the address for a memory that contains the routing table, again making packet forwarding a very simple process.
Thus the network needs to carry two very different services: a synchronised service with packets being identified by their time of arrival, and a best-effort service with packets being identified by a label. This can be achieved by formatting each link with "slots" that can be allocated to synchronous flows, and using all the bytes on the link that are not used by the synchronous service (including those within an occupied slot that are beyond the end of the packet) to carry best-effort packets. It is very simple with today's hardware to multiplex these two services together on the line card for transmission, and similarly demultiplex them on reception.
Flexilink is an implementation of a system as described above. It interworks with IP, so for example IP packets can be tunnelled between applications on user equipment and a gateway to the Internet, and Flexilink packets can be carried over an IP network (though with a degraded performance in the case of the synchronous service). It is also suitable for use with SDN. Networking equipment is significantly simpler than IP routers with equivalent performance.
It is being standardised by ETSI ISG NIN (see documents GR NGP 003 and GS NGP 013 and GR NIN 003) including as a network layer for DECT-2020 (GS NIN 004 under development).
------------- ooo OOO ooo -------------
Copyright ©2017-2022 Nine Tiles