Showing posts with label IETF. Show all posts
Showing posts with label IETF. Show all posts

Friday, 10 July 2026

From 3GPP MPS to Wi-Fi 7 EPCS

Back in January 2011, I wrote about Enhanced Multimedia Priority Service, or eMPS, in 3GPP Release 10. At the time, the focus was on extending priority treatment beyond basic voice calls to packet data and multimedia sessions over LTE and EPC.

The basic requirement has not changed. During a major incident, commercial communication networks may become heavily congested at exactly the time when certain authorised users most need to communicate. These users may include government personnel, emergency management officials and others assigned National Security or Emergency Preparedness, NS/EP, responsibilities.

3GPP addresses this through Multimedia Priority Service, or MPS, specified in TS 22.153. MPS is not a separate radio system and it should not be confused with public emergency calling. It is a mechanism that gives authorised Service Users priority treatment on commercial networks, increasing the probability that their voice, video or data communications can be successfully established and maintained during congestion.

In my original post, I explained that this required more than simply prioritising user-plane packets. End-to-end priority could involve NAS and AS signalling establishment, session establishment, resource allocation in the radio and core networks and treatment of the media bearers themselves.

Fifteen years later, the interesting development is that this idea is expanding beyond the traditional cellular access network.

The challenge is easy to understand. An authorised priority user may have an MPS subscription with a mobile operator, but that user may be inside a building, transport hub, stadium, campus or other environment where connectivity is provided over Wi-Fi. Even where cellular coverage exists, the device may already be using Wi-Fi because of local coverage, capacity or policy.

The question is therefore no longer just how to prioritise an NS/EP user in LTE or 5G. It is how priority authorisation can follow the user across different access technologies.

There are actually two related but different technical developments taking place.

The first is within 3GPP itself. In Release 19, a change to TS 22.153 added explicit MPS requirements for situations where a UE is using a 3GPP radio access technology, such as NR or E-UTRA, and non-3GPP WLAN access connected to the same EPC or 5GC. The associated work item is MPS_WLAN, or MPS when access to EPC/5GC is WLAN.

This is important, but it is still primarily a 3GPP system view. The WLAN is acting as non-3GPP access towards the mobile core.

The second development goes further. Wi-Fi 7 introduces Emergency Preparedness Communications Service, or EPCS, functionality that can provide preferred or prioritised channel access to authorised users. This means that priority treatment can also be applied on the Wi-Fi access network itself.

This creates a different architectural problem.

Wi-Fi can define how the Access Point, AP, and Station, STA, support prioritised channel access, but the Wi-Fi network still needs to know whether the user is genuinely authorised to receive that treatment.

The network therefore needs to determine whether the user is authenticated, whether the user is authorised for Priority Services, what priority level has been assigned, whether that authorisation is valid in the relevant regulatory jurisdiction and whether the network and device support the required EPCS capabilities.

This is the gap that the current IETF work is attempting to address.

The latest version at the time of writing is draft-gundavelli-radepcs-02, titled RADIUS attributes for National Security and Emergency Preparedness Service. It is an active Internet-Draft and work in progress rather than an approved IETF standard. The draft describes RADIUS extensions for authorising EPCS users so that they can receive preferential access to Wi-Fi network resources during congestion.

The proposed architecture reuses mechanisms already widely deployed for managed and roaming Wi-Fi, including Passpoint, EAP and RADIUS.

A user is first authorised for Priority Services by an appropriate Authorising Entity. The service provider receives this authorisation and stores the relevant priority information against the subscriber profile. Where the service provider is also a cellular operator and Wi-Fi Identity Provider, the priority service subscription information can be mirrored into the Wi-Fi AAA system.

The overall architecture and signalling flow are shown below.

The first part of the process is network discovery. An EPCS-enabled Wi-Fi network advertises an EPCS Roaming Consortium, while the authorised user's device contains a corresponding Passpoint profile. The device can discover the relevant roaming information and select the network using normal Passpoint mechanisms.

After the device associates with the Wi-Fi network, EAP authentication is performed and the AP or Wireless LAN Controller forwards the authentication exchange towards the Identity Provider using RADIUS.

This is where the proposed new RADIUS attributes become important.

EPCS-Capable-Indication allows the Wi-Fi Network Access Server to tell the RADIUS server that it supports EPCS. The capability information can also indicate whether priority treatment is possible only when the user device itself supports EPCS, or whether some treatment, such as downlink prioritisation, may still be possible for a non-EPCS device.

EPCS-Regulatory-Info provides information about the regulatory regime under which priority service is being authorised. This may contain an ISO 3166-1 country code or ISO 3166-2 subdivision code. This matters because priority authorisation and priority levels may be specific to a particular country or jurisdiction.

EPCS-Subscription-Info indicates that the authenticated user is authorised to receive Priority Services and carries the priority level associated with the user's subscription. The priority levels themselves are administered according to the relevant regulatory regime.

The important point is that the Wi-Fi network does not independently decide that a user should receive priority.

The authorisation originates from an external authority and is linked to an authenticated identity or subscription.

Authentication and priority authorisation are therefore separate. Successfully authenticating to a Wi-Fi network does not automatically make someone an EPCS user.

Once the AAA system confirms that the user is authorised, the AP/WLC can enable EPCS Priority Access for the device. Where both the network and device support EPCS, uplink and downlink traffic can receive priority treatment. Depending on the capabilities of the network, downlink traffic may still be prioritised even when the device itself does not support EPCS. The exact mechanism used by the network to prioritise the traffic is vendor-specific and outside the scope of the current IETF draft.

There are several interesting aspects to this architecture.

First, the solution uses the existing Wi-Fi roaming framework rather than creating an entirely separate emergency network discovery and authentication mechanism. Passpoint supports automatic discovery and network selection, EAP handles authentication and RADIUS carries the EPCS authorisation information.

Second, location and regulatory information become part of the authorisation process. A user authorised for a particular level of priority in one jurisdiction may not necessarily be entitled to the same treatment everywhere.

Third, the network needs to separate a user's normal access credentials from their entitlement to Priority Services. An ordinary subscriber, an authenticated Wi-Fi user and an authorised EPCS user may all use the same access network but receive very different treatment during congestion.

Finally, this is not simply a matter of giving some packets a higher priority marking.

Real end-to-end priority may involve access to the Wi-Fi medium, AP queues, backhaul networks, interconnected networks and application traffic. The IETF draft identifies authentication, authorisation, traffic identification and prioritisation as separate requirements. Where networks interconnect, priority indicators may also need to be passed securely to downstream networks.

It is also worth stressing the difference between Priority Services and emergency calling.

An ordinary user attempting to call 999, 112 or 911 is not automatically an NS/EP Priority Service user. Emergency calling is about allowing the public to reach emergency services, potentially even when normal cellular coverage or credentials are unavailable.

MPS and EPCS are different. They are intended for authorised users or organisations that have been assigned priority privileges so their communications have a greater probability of success during congestion.

The Wireless Broadband Alliance has been working on both areas through its Mission Critical and Emergency Services programme. Its work covers emergency calling over Wi-Fi, cellular emergency calling over OpenRoaming and NS/EP priority communications. For the priority case, the focus is on using Wi-Fi, Passpoint and roaming mechanisms to extend capabilities traditionally associated with cellular networks.

For me, the interesting part is how the boundaries between cellular and Wi-Fi continue to blur.

3GPP MPS started from the assumption that priority treatment had to be provided across the cellular system, from access signalling through to core network resources and application sessions. 3GPP has now added explicit requirements for MPS when 3GPP and WLAN accesses connect to the same EPC or 5GC.

At the same time, Wi-Fi 7 provides EPCS mechanisms for prioritised channel access, while Passpoint and the proposed RADIUS extensions provide a possible way to discover the service, authenticate the user and transfer priority authorisation into the Wi-Fi network.

The result is not a replacement for cellular MPS, and it is not simply Wi-Fi QoS.

It is the beginning of a more access-independent model in which an authorised user's priority status could potentially follow them across cellular and Wi-Fi networks, with each access technology applying the appropriate mechanisms within its own domain.

That is a much more interesting evolution than simply adding another priority bit to the network.

Tuesday, 1 May 2018

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*



-            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:

Tuesday, 13 February 2018

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:



Tuesday, 6 February 2018

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.