MAMS (Multi Access Management Services) at MEC integrating LTE and Wi-Fi networks

Came across Multi Access Management Services (MAMS) a few times recently so here is a quick short post on the topic. At present MAMS is under review in IETF and is being supported by Nokia, Intel, Broadcom, Huawei, AT&T, KT.

I heard about MAMS for the first time at a Small Cell Forum event in Mumbai, slides are here for this particular presentation from Nokia.

As you can see from the slide above, MAMS can optimise inter-working of different access domains, particularly at the Edge. A recent presentation from Nokia (here) on this topic provides much more detailed insight.

From the presentation:

•        MAMS (Multi Access Management Services) is a framework for

-            Integrating different access network domains based on user plane (e.g. IP layer) interworking,

-            with ability to select access and core network paths independently

-            and user plane treatment based on traffic types

-            that can dynamically adapt to changing network conditions

-            based on negotiation between client and network

•        The technical content is available as the following drafts*

-            Multi Access Management Services (MAMS) Framework – https://datatracker.ietf.org/doc/draft-kanugovi-intarea-mams-framework/

-            MAMS JSON definitions of Control Plane Messages: https://www.ietf.org/id/draft-agarwal-intarea-mams-protocol-json-00.txt

-            MAMS User Plane Specification: https://tools.ietf.org/html/draft-zhu-intarea-mams-user-protocol-02

*Currently under review, Co-authors: Nokia, Intel, Broadcom, Huawei, AT&T, KT,

The slides provide much more details, including the different use cases (pic below) for integrating LTE and Wi-Fi at the Edge.

Here are the references for anyone wishing to look at this in more detail:

• Multi Access Management Services (MAMS) Framework – https://datatracker.ietf.org/doc/draft-kanugovi-intarea-mams-framework/
• MAMS JSON definitions of Control Plane Messages: https://tools.ietf.org/html/draft-agarwal-intarea-mams-protocol-json-00
• MAMS User Plane Specification: https://tools.ietf.org/html/draft-zhu-intarea-mams-user-protocol-02

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

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