Artificial Intelligence - Beyond SON for Autonomous Networks

What is the next step in evolution of SON? Artificial Intelligence obviously. The use of artificial intelligence (AI) techniques in the network supervisory system could help solve some of the problems of future network deployment and operation. ETSI has therefore set up a new 'Industry Specification Group' on 'Experiential Networked Intelligence' (ISG ENI) to develop standards for a Network Supervisory assistant system.

The ISG ENI focuses on improving the operator experience, adding closed-loop artificial intelligence mechanisms based on context-aware, metadata-driven policies to more quickly recognize and incorporate new and changed knowledge, and hence, make actionable decisions. ENI will specify a set of use cases, and the generic technology independent architecture, for a network supervisory assistant system based on the ‘observe-orient-decide-act’ control loop model. This model can assist decision-making systems, such as network control and management systems, to adjust services and resources offered based on changes in user needs, environmental conditions and business goals.

The introduction of technologies such as Software-Defined Networking (SDN), Network Functions Virtualisation (NFV) and network slicing means that networks are becoming more flexible and powerful. These technologies transfer much of the complexity in a network from hardware to software, from the network itself to its management and operation. ENI will make the deployment of SDN and NFV more intelligent and efficient and will assist the management and orchestration of the network.

We expect to complete the first phase of ENI work in 2019. It will include a description of use cases and requirements and terminology, including a definition of features, capabilities and policies, which we will publish in a series of informative best practice documents (Group Reports (GRs)).

This will of course require co-operation from many different industry bodies including GSMA, ITU-T, MEF, IETF, etc.

Will see how this goes.

Further reading:

• ETSI Presentation on ENI
• Network, All Intelligent. - ENI introduction, IETF

Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)

As a continuation of 'Control and User Plane Separation of EPC nodes (CUPS) in 3GPP Release-14', here is another tutorial on Service Base Architecture (SBA) for the 5G Core.

The slides (with video) is embedded below but there are quite a few tutorials on 5G available on 3G4G page here.

Advanced: 5G Service Based Architecture (SBA) from 3G4G

Further Reading:

• Control and User Plane Separation of EPC nodes (CUPS) in 3GPP Release-14
• 3GPP 5G Specifications
• 5G - 3G4G Webpage
• 2G, 3G, 4G & 5G Training and Tutorial Videos - 3G4G Webpage

QUIC - Possibly in 5G, 3GPP Release-16

Over the last year or so, I have heard quite a few discussions and read many articles around why QUIC is so good and why we will replace TCP with QUIC (Quick UDP Internet Connection). One such article talking about QUIC benefits says:

QUIC was initially developed by Google as an alternative transport protocol to shorten the time it takes to set up a connection. Google wanted to take benefits of the work done with SPDY, another protocol developed by Google that became the basis for the HTTP/2 standard, into a transport protocol with faster connection setup time and built-in security. HTTP/2 over TCP multiplexes and pipelines requests over one connection but a single packet loss and retransmission packet causes Head-of-Line Blocking (HOLB) for the resources that were being downloaded in parallel. QUIC overcomes the shortcomings of multiplexed streams by removing HOLB. QUIC was created with HTTP/2 as the primary application protocol and optimizes HTTP/2 semantics.

What makes QUIC interesting is that it is built on top of UDP rather than TCP. As such, the time to get a secure connection running is shorter using QUIC because packet loss in a particular stream does not affect the other streams on the connection. This results in successfully retrieving multiple objects in parallel, even when some packets are lost on a different stream. Since QUIC is implemented in the userspace compared to TCP, which is implemented in the kernel, QUIC allows developers the flexibility of improving congestion control over time, since it can be optimized and better replaced compared to kernel upgrades (for example, apps and browsers update more often than OS updates).

Georg Mayer mentioned about QUIC in a recent discussion with Telecom TV. His interview is embedded below. Jump to 5:25 for QUIC part only

Georg Mayer, 3GPP CT work on 5G from 3GPPlive on Vimeo.

Below are some good references about QUIC in case you want to study further.

• IETF QUIC Charter
• Youtube: QUIC Next generation multiplexed transport over UDP - Google
• Understanding QUIC wire protocol - Anuradha Niroshan
• HTTP/2 and QUICK protocols. Optimizing the Web stack for HTTP/2 era
• Measuring QUIC vs TCP on mobile and desktop