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.
No comments:
Post a Comment