Internet DRAFT - draft-mertus-scone-mowie-for-network-aware-app
draft-mertus-scone-mowie-for-network-aware-app
SCONE D.M. Mertus
Internet-Draft Yale University
Intended status: Standards Track Y. Jia
Expires: 2 September 2024 Y. Zhang
Tencent
Y. R. Yang
Yale University
G. Li
CMRI
Y. Lei
Y. Han
Tencent
Sabine. Randriamasy
Nokia
1 March 2024
MoWIE for Network Aware Application
draft-mertus-scone-mowie-for-network-aware-app-00
Abstract
With the deployment of 5G networks, cloud-based interactive services
such as cloud gaming have gained substantial attention. To ensure
users' quality of experience (QoE), a cloud interactive service may
require not only high bandwidth (e.g., high-resolution media
transmission) but also low delay (e.g., low latency and low lagging).
However, the quality perceived by a user of a mobile and wireless
device may vary widely as a function of many factors, and unhandled
changes can substantially compromise the user's QoE. In this
document, we investigate network-aware applications (NAA), which
realize cloud-based interactive services with improved QoE, by
efficient utilization of a solution named Mobile and Wireless
Information Exposure (MoWIE). In particular, this document
demonstrates, through realistic evaluations, that mobile network
information such as MCS (Modulation and Coding Scheme) can
effectively expose the dynamics of the underlying network and can be
made available to applications through MoWIE; using such an
information, the applications can then adapt key control knobs such
as media codec schemes, encapsulation, and application layer
processing to minimize QoE distortion. Following evaluations we give
a cursory overview of the design space for implementing MoWIE
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Mertus, et al. Expires 2 September 2024 [Page 1]
Internet-Draft MoWIE for Network Aware Application March 2024
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Current Status of Network-Aware Applications . . . . . . . . 3
2. MoWIE Introduction and Use Cases . . . . . . . . . . . . . . 6
2.1. Basic Idea of MoWIE . . . . . . . . . . . . . . . . . . . 6
2.2. Standard NAA Use Cases for MoWIE . . . . . . . . . . . . 8
2.3. Preliminary Evaluations and Benefits . . . . . . . . . . 8
2.3.1. RAN-assisted TCP optimization . . . . . . . . . . . . 8
2.3.2. ROI Detection . . . . . . . . . . . . . . . . . . . . 9
2.3.3. Adaptive Bitrate . . . . . . . . . . . . . . . . . . 9
3. Signaling for MoWIE Information . . . . . . . . . . . . . . . 10
4. On-path Signaling . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Key Components . . . . . . . . . . . . . . . . . . . . . 11
4.2. Security Considerations . . . . . . . . . . . . . . . . . 13
4.3. Benefits and Challenges . . . . . . . . . . . . . . . . . 13
5. Off-path Signaling . . . . . . . . . . . . . . . . . . . . . 14
5.1. Key Components . . . . . . . . . . . . . . . . . . . . . 14
5.2. Security Considerations . . . . . . . . . . . . . . . . . 17
5.3. Benefits and Challenges . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
Mertus, et al. Expires 2 September 2024 [Page 2]
Internet-Draft MoWIE for Network Aware Application March 2024
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Current Status of Network-Aware Applications
With the deployment of 5G networks
[draft-ietf-dmm-5g-uplane-analysis] , an increasing number of remote
cloud-based applications are being deployed (e.g., cloud AR/VR/MR).
Many conventional interactive, daily business applications are also
becoming widely used as cloud applications, with the help of mobile
networks and cloud, e.g., cloud video conference. This shift was
further accelerated by the COVID-19 pandemic in 2020, when many
people had to stay at home and work/study remotely
Mertus, et al. Expires 2 September 2024 [Page 3]
Internet-Draft MoWIE for Network Aware Application March 2024
To optimize QoE for end users using mobile networks (a.k.a., cellular
networks), many cloud applications utilize information about the
mobile network status, e.g., delay, bandwidth, and jitter, to
dynamically balance the generated media traffic and the rendering/
mixing in the cloud. Currently, such an application assumes the
network as a link and continuously uses client or server measurements
to detect network characteristics, and then adaptively changes its
network-related configuration parameters, possibly impacting QoS
handling and logical functions supporting the upper layer
application. However, when only application information is utilized,
the QoE that an application achieves is limited for several reasons.
First, information from the application side (i.e., the 3rd party
application server) may have a relatively long delay. When a user
enters a location with a bad network connectivity, such as an
elevator or an underground garage, the application will not receive
such an information immediately. As a result, the buffer of a video
application may run out, resulting in a frozen screen and harming
users' QoE. The application also does not have information about
other users in the cell. Thus, it cannot know how many resources it
can get and when this will change. If other users enter the cell and
compete for resources, the application layer may misjudge the
resources available and request a high bitrate. Then, the delay will
increase and QoE will again drop. Information from the network layer
such as physical resource block (PRB) information and utilization
rate can help applications decide how many resources a user can
access in order to inform network quality predictions and further
optimize video streaming. The application, however, cannot get this
kind of information yet. Because 5G networks deployed by a mobile
network operation are normally in a different domain than 3rd-party
internet-based applications, the application server can not directly
get the network internal status without network exposure. For this
reason, there have been continuous efforts in 3GPP to increase
network exposure.
3GPP mobile networks adhere to standard solutions to get dynamic
network indicators for use by applications. In 3GPP, many IP-based
QoS mechanisms are used. For example, ECN [RFC3168] has been
supported by the 4G radio station (eNB) to provide CE(Congestion
Encountered) information to the IMS application to perform Adaptive
Bitrate (ABR) [TS26.114] . The application can downgrade the bit rate
after receiving the CE indication, but does not know the exact bit
rate to be selected. DSCP [RFC2474] is used to identify the QoS
class and paging strategy [TS23.501] , but typically the application
cannot dynamically change the DSCP to improve bit rate based on
network status. Mapping DSCP with 4G QCI or 5G 5QI standards could
be a good approach to better realize end-to-end QoS. DASH [MPEGDASH]
is an MPEG standard widely used by applications to predict the
throughput of the network based on the current throughput and
Mertus, et al. Expires 2 September 2024 [Page 4]
Internet-Draft MoWIE for Network Aware Application March 2024
buffering state in order to dynamically select a suitable bitrate for
the next segment of video streaming which avoids re-buffering. SAND-
DASH [TS26.247] defines the mechanism through which the network/
server can provide available throughput to applications; in this
case, the better bitrate can be selected by DASH application.
There is also some early work on network status exposure to TCP
servers which may also indirectly impact application layer
optimization but it does not consider 5G networks [Sprecher_mobile] ,
[flinck_mobile] In 5G cellular networks, network capability exposure
has been specified to allow the 5G system (5GS) to expose user device
location and network status to 3rd party application servers, modeled
as AF (Application Function) [TS23.501] . In such a case, the AF can
request the 5GS to establish a dedicated QoS Flow to transport an IP
flow with the AF-provided QoS requirements. Via certain
measurements, network internal status, including congestion, can be
exposed and optimization can be carried out for the cellular network
[PBECC] .
5G also can provide QNC (QoS Notification Control) to an AF if the
GBR(Guaranteed Bitrate) of the established GBR QoS Flow cannot be
fulfilled. After receiving the QNC notification the AF can change
the bitrate, but the AF has no information on which bitrate to
select. So, 5G enhances the QNC by providing a list of AQPs
(alternative QoS profiles). With AQP, a 5G network provides a subset
of supported AQPs with the QNC, and then the AF selects a bit rate
from 5G network supported AQPs. In such a case, the GBR can be
fulfilled again if the radio state of the UE is changed. QoS
prediction is realized by a network function inside 5GS which
collects and analyzes the status and qualities of 5G network
entities, and deliver the analytics results to an entity such as
application server.
However, both network capability exposure and QoS prediction
solutions are only designed for 5G access and core networks, which
cannot cover the whole end-to-end network. Enabling applications to
detect and understand the various lower layers within 5G networks,
particularly the internal DN (data network), is an important area for
both industrial and academic researchers. This challenge is
addressed by MoWIE.
MoWIE is a solution that aims to realize real-time provisioning of
cellular radio network information by networks to applications, thus
helping service providers achieve better policy control and improve
user experience. The benefits of the MoWIE concept/solution have
been experimentally evaluated in several use cases, detailed in the
following section.
Mertus, et al. Expires 2 September 2024 [Page 5]
Internet-Draft MoWIE for Network Aware Application March 2024
2. MoWIE Introduction and Use Cases
2.1. Basic Idea of MoWIE
The fundamental idea of MoWIE is to provide on-demand and periodic
network information from the network to applications, enhancing
policy control and user experience. This basic conceptualization
includes the following key components: the Client Application, the
Mobile Network, and the Application Server. Raw data collected from
the Mobile Network is processed and exposed to the Application
Server. This server can then request network information and use
this information to optimize application functions in the Client
Application like bit rate, latency, and jitter. Network information
provided by MoWIE includes the following:
Cell level Information:
* Number of Downlink PRBs (Physical Resource Blocks) occupied during
sampling period
* Cell load
* Downlink (DL) MAC data rate per cell
* DL data rate
* Channel status (e.g. RSRP (Reference Signal Received Power) and
CQI (Channel Quality Indicator))
* PDCP (Packet Data Convergence Protocol) buffer status
UE level information (omitting privacy information):
* DL Signal to Inference plus Noise Ratio (SINR)
* Modulation and Coding Scheme (MCS)
* Number of packets occupied in PDCP buffer
* Number of DL PDCP Service Data Unit (SDU) packets
* Number of lost PDCP SDU packets
* Per-UE DL MAC data rate
* Per-UE DL data rate
* Per-UE channel status
Mertus, et al. Expires 2 September 2024 [Page 6]
Internet-Draft MoWIE for Network Aware Application March 2024
* Per-UE PDCP (Packet Data Convergence Protocol) buffer status
The network information listed here can also be found in 3GPP (PRB
[TS38.211] , cell load [TS38.300] PDCP for 5G [TS38.323] RSRP, RSRQ,
RSSI [TS38.331] , MCS, CQI [TS38.214] , The number of packets
occupied in PDCP buffer, the number of DL PDCP SDU packets, the
number of PDCP SDU packets lost, the per-UE PDCP buffer status
[TS38.323] ), demonstrate the potential benefits of MoWIE for
network-application integration over cellular network. Figure 3-1
and Figure 3-2 list the data types corresponding to the cell-level
information and UE-level information respectively.
+----------------------+--------------------------+
|Cell-level Information| Data type/Range |
+----------------------+--------------------------+
| PRB | Uint16 |
+----------------------+--------------------------+
| CQI | Uint8 |
+----------------------+--------------------------+
| RSRP | Uint8 |
+----------------------+--------------------------+
| RSRQ | Uint8 |
+----------------------+--------------------------+
| Cell load | [0,1] |
+----------------------+--------------------------+
Figure 4-1: Cell level data type
+------------------------------------+---------------+
| UE-level Information |Data type/Range|
+------------------------------------+---------------+
| Downlink SINR | Uint16 |
+------------------------------------+---------------+
| MCS | Uint8 |
+------------------------------------+---------------+
| Downlink PDCP SDU packets | Uint8 |
+------------------------------------+---------------+
| PDCP SDU packets lost | Uint8 |
+------------------------------------+---------------+
| Packets occupied in PDCP buffer | [0,1] |
+------------------------------------+---------------+
| CQI | Uint8 |
+------------------------------------+---------------+
| RSRP | Uint8 |
+------------------------------------+---------------+
| RSRQ | Uint8 |
+------------------------------------+---------------+
Figure 4-2: UE level data type
Mertus, et al. Expires 2 September 2024 [Page 7]
Internet-Draft MoWIE for Network Aware Application March 2024
2.2. Standard NAA Use Cases for MoWIE
Cloud gaming, low-delay live shows, and cloud VR are commons NAAs
whose QoE can be largely enhanced using MoWIE. These applications
require low latency and reliable transmission, interactive features,
and high data rates. For instance, cloud gaming demands fast,
reliable connections between user devices and cloud servers for
motion tracking and visual content delivery, significantly
contributing to network traffic. Similarly, low-delay live shows
require interactive capabilities with sub-100 ms delays for audience
engagement, while cloud VR demands extensive bandwidth and latency as
low as 20 ms due to its high data volumes and rendering requirements.
Performance requirements across these applications may be
characterized by a parameter range. Here we consider 1080p~4K as the
resolution range, 60-120 FPS (Frames per second) as the frame rate
and H.265 as an example compression algorithm. Given these settings,
cloud gaming requires a bandwidth of 20-60 Mbps and latency under 200
ms. For low-delay live shows, 20-50 Mbps bandwidth and latency under
100 ms are needed, while cloud VR demands 100-500 Mbps bandwidth and
latency under 50 ms. These values are dependent on the parameter
settings and are provided to illustrate the order of magnitude of
these parameters for the aforementioned use cases.
MoWIE's network information can be used to enhance these
applications, particularly in mobile and wireless contexts where
existing methods struggle due to indirect or delayed network status
measurements. By providing direct, real-time data, MoWIE enables
more responsive and effective application adjustments, leading to
substantial performance gains and enhanced QoE.
2.3. Preliminary Evaluations and Benefits
Preliminary tests demonstrate significant QoE improvements for NAAs
using MoWIE. By integrating real-time network information,
applications can optimize performance, leading to enhanced QoE and
resource savings.
2.3.1. RAN-assisted TCP optimization
In trials on real mobile networks, RAN information was used to inform
TCP sending window adjustment by predicting bandwidth and buffer
status per-UE at RTT granularity (100 ms) and piggybacking such
information in TCP ACK. This approach has shown throughput boosts of
up to 100%.
Mertus, et al. Expires 2 September 2024 [Page 8]
Internet-Draft MoWIE for Network Aware Application March 2024
2.3.2. ROI Detection
ROI (Region of Interest) detection has been widely studied in
recently years as a mechanism to reduce video size and bandwidth
consumption by dynamically re-allocating coding schemes for
interested and non-interested regions. Current methods utilize
application information like application rate and application buffer
size as the indicators to roughly adjust the algorithm in interactive
video services. However, this information is hard to reflect the
real-time network status precisely, making it difficult to balance
QoE and bandwidth savings in real-time scenarios, including the
standard NAAs outlined above. MoWIE's network information can
provide direct, real-time data to improve the performance of ROI
methods.
Experiments evaluated the following four methods of ROI detection: 1)
no ROI detection, 2) rough ROI detection at 10ms delay, 3) accurate
ROI detection at 40-70ms delay, and 4) dynamic ROI detection in which
bandwidth traces are used to compute transmission delay and inform
ROI algorithm adjustments. Network conditions varied from poor
(Network 1) to good (Network 2) and fluctuating (Network 3). Our
findings show that method 4 provides the best balance between QoE and
bandwidth savings, especially in adverse network scenarios.
+---+-----------------+-----------------+-----------------+
| | Network 1 | Network 2 | Network 3 |
+---+---+-------------+---+-------------+---+-------------+
| |QoE| BW Saving |QoE| BW Saving |QoE| BW Saving |
+---+---+-------------+---+-------------+---+-------------+
| 1 |3.8| 0% |4.8| 0% |4.3| 0% |
+---+---+-------------+---+-------------+---+-------------+
| 2 |3.8| 5% |4.8| 9% |4.3| 7% |
+---+---+-------------+---+-------------+---+-------------+
| 3 |2.2| 2.1% |4.6| 38% |3.1| 34% |
+---+---+-------------+---+-------------+---+-------------+
| 4 |3.6| 9% |4.7| 33% |4.3| 25% |
+---+---+-------------+---+-------------+---+-------------+
Figure 4-3: QoE and Bandwidth Saving
2.3.3. Adaptive Bitrate
Many applications such as video live streaming and cloud gaming
employ adaptive bitrate (ABR) algorithms to optimize user QoE [MPC]
[CS2P]. However, traditional ABR algorithms use fixed control rules
based on simplified or inaccurate models of the deployment
environment, leading to suboptimal performance across a broad set of
network conditions and QoE objectives. More recent ABR algorithms,
such as Pensieve [Hongzi], use reinforcement learning to optimize
Mertus, et al. Expires 2 September 2024 [Page 9]
Internet-Draft MoWIE for Network Aware Application March 2024
QoE, but still suffer from limitations due to indirect or delayed
network status measurements and an incomplete set of network
information. MoWIE's network information can be used to enhance ABR
algorithms, particularly in challenging network conditions.
This experiment applied AI-based rate adaptation utilizing MCS
network information from gNBs [TS38.214] in cloud-gaming over
Tencent's China Mobile LTE network. MCS information was provided
directly to the application. Data was collected over several network
conditions: 1) low bandwidth, 2) high user load, 3-5) random user
distributions. Lagging rate is defined as the ratio between the
number of frames with transmission delay greater than 200ms and the
total number of frames.
+-------------+--------------------------+
|Test Scenario| Reduction of Lagging Rate|
+-------------+--------------------------+
| 1 | 46% |
+-------------+--------------------------+
| 2 | 21% |
+-------------+--------------------------+
| 3 | 37% |
+-------------+--------------------------+
| 4 | 56% |
+-------------+--------------------------+
| 5 | 32% |
+-------------+--------------------------+
Figure 4-4: Reduction of Lagging Rate
We clearly observe a significant reduction in lagging rates across
all scenarios.
3. Signaling for MoWIE Information
Thus far we have outlined the information that MoWIE provides. Now
we will consider how this information can be exposed to the
application. We identify two distinct approaches:
* On-path signaling: this refers to the process of exposing network
information to the application through the same path as the
application's data; this is also known as inband communication or
simply, path signaling [RFC9419].
* Off-path signaling: this refers to the process of exposing network
information to the application through a separate path.
Mertus, et al. Expires 2 September 2024 [Page 10]
Internet-Draft MoWIE for Network Aware Application March 2024
For each of these approach we establish key high-level components and
introduce a discussion of the design space. We also list possible
security considerations as well as the benefits and drawbacks of each
approach.
4. On-path Signaling
In our discussion of on-path signaling we maintain the following
entities from our initial discussion on MoWIE: the Application
Server, the Mobile Network, and the Client Application. From the
Mobile Network we derive the the gNB which will serve as the on-path
entity which exposes network information to the application.
The initial structure is as follows:
Client Application gNB Application Server
+---+ +--------------+ +----------------+
| |-------------| |---------| |
| | | | | |
| | | | | |
+---+ +--------------+ +----------------+
------------
application connection
4.1. Key Components
We identify the following key components for achieving MoWIE via on-
path signaling
* Collecting and processing network information: the gNB can
regularly collect and process the network information included in
the MoWIE framework. gNBs are well positioned to collect this
information given their central role in the 5G network. They may
leverage various aspects of the 5G architecture to collect this
information, such as the RAN, the core network, and the UE.
* Discovering the on-path gNB by the Application Server: this may be
done by the gNB advertising itself to the Application Server in
several manners. One method is to encapsulate the original
payload within a new layer. Another option is to inject
additional packets on an UDP option or IP header. These methods
are discussed in [SADCDN]. Additional methods of interleaving
with the original payload may also be considered.
* Discovering the on-path gNB by the Application Client: if the gNB
is able to associate packets outgoing to the Application Server
with incoming packets to the Application Client, similar methods
Mertus, et al. Expires 2 September 2024 [Page 11]
Internet-Draft MoWIE for Network Aware Application March 2024
to to those used previously may be applied. Else, this challenge
may be addressed through direct communication between the
Application Server and the gNB. Complications arise due to the
dynamic nature of mobile IPs and the potential for NATs to be
present in the path.
* Communication between the application and the gNB: after
discovery, the Application Server or Client can establish a
separate QUIC connection with the gNB and request network
information, both individually and at regular specified intervals.
The gNB will then respond with the requested information, which
the Application Server can use to optimize the application's
behavior. Alternatively, the gNB may be able able to piggyback
network information on packets running through the existing QUIC
connection.
* Performance Isolation: to preserve the integrity of the
application function, the original QUIC connection should not be
affected by the additional signaling. This may have implications
for the gNB's ability to parse and alter hte original payload
given the performance impact.
* Security and privacy: all signaling must utilize as little
information as possible to achieve the desired result and all
information exposure should be transparent to both the users to
adhere to the principles of minimal information exposure and user
consent outlined in [RFC9419]. The process should also allow for
negotiation of signaling parameters to ensure trust between the
Application Server and gNB. The application may leverage QUIC's
secure and authenticated transport layer to ensure the integrity
and security of the communication.
* Scalability: the process should be lightweight to assist in
scalability. Scalability will ultimately depend on the
performance capabilities of gNBs. These additional QUIC
connections may strain gNB when under heavy user load.
* Application control: the process should be under the application's
control in accordance with [RFC9419] and align with their
networking requirements. We prefer starting with a pull model to
ensure information exposure is entirely optional and under the
application's control. The application can choose to request only
the network information desired, only when it is desired.
Mertus, et al. Expires 2 September 2024 [Page 12]
Internet-Draft MoWIE for Network Aware Application March 2024
* Robustness: the process should be robust to network changes and
failures. The process should also be able to handle the dynamic
nature of mobile networks, where clients frequently move and
switch gNBs. If the existing direct data path changes, the
signaling path should be able to adapt to the new path.
Once connection has been established we can visualize the structure
as follows:
Client Application gNB Application Server
+---+ +--------------+ +----------------+
| |-------------| |---------| |
| |+++++++++++++| |+++++++++| |
| | | | | |
+---+ +--------------+ +----------------+
------------ +++++++++
application connection MoWIE connection
4.2. Security Considerations
Of key importance in this implementation is the security of the
exchanged data. Once authentication between the Application Server
and gNB has taken place, any exchanged data must be protected from
becoming a vector for possible malicious action. Standard
cryptographic techniques should be employed to ensure the
confidentiality, integrity, and authenticity of the signaling data.
Misuse of this signaling mechanism should be minimized through common
security practices such as rate limiting.
The initial exposure of the gNB to the Application Server must take
place prior to authentication between these two entities. This must
be carefully managed to ensure that the gNB is not exposed to any
malicious actors.
4.3. Benefits and Challenges
On-path signaling is a powerful tool for enabling real-time network
information exchange to enable dynamic NAAs. The primary benefit of
an implementation with on-path signaling is that it greatly
simplifies the challenge of associating a particular Application
Server/Client Application pair with the relevant gNB and as a result,
the relevant set of network information.
However, on-path signaling also presents several challenges. Any
mechanism of initial connection relying on the gNB piggybacking off
the existing QUIC connections fights the encryption and integration
protection of the original QUIC connection. The gNB would need to be
Mertus, et al. Expires 2 September 2024 [Page 13]
Internet-Draft MoWIE for Network Aware Application March 2024
able to parse the original, encrypted payload, and may affect, for
example, performance of the original core functionality. The
alternative of appending additional packets on an UDP option or IP
header would require support from both the Application Server and
Client Application which may be difficult to ensure.
Another challenge is the increased overhead associated with
maintaining additional QUIC channels. As indicated earlier, in high-
traffic scenarios this load may strain gNBs and due to the nature of
on-path signaling, the gNB is the only entity that can provide the
network information. This may create bottlenecks and limit the
scalability of the solution.
5. Off-path Signaling
In this discussion on off-path signaling, we continue with the
entities previously established: the Application Server, the Mobile
Network, and the Client Application. Contrary to the on-path
scenario, here we introduce a third-party node, called the
Information Server, which stands outside the direct data flow and is
tasked with providing network information to the application.
The initial structure is as follows:
Information Server
+--------------+
| |
| |
| |
+--------------+
Client Application gNB Application Server
+---+ +--------------+ +----------------+
| |-------------| |---------| |
| | | | | |
| | | | | |
+---+ +--------------+ +----------------+
------------
application connection
5.1. Key Components
We identify the following key components for achieving MoWIE via off-
path signaling:
Mertus, et al. Expires 2 September 2024 [Page 14]
Internet-Draft MoWIE for Network Aware Application March 2024
* Collecting and processing network information: the Information
Server is tasked with aggregating and processing network
information pertinent to the MoWIE framework. This entity may
collate data from various sources within the 5G network,
leveraging information from the RAN, core network elements, and
potentially direct reports from UEs or gNBs.
* Discovering the relevant Information Server by the Application
Server or Client: on both server and client side the application
faces the challenge of locating the relevant Information Service
for acquiring network information that impacts the application's
performance. Application of service discovery protocols or
reverse DNS lookups may fail to solve this issue due to the
dynamic nature of mobile networks and the potential for NATs to be
present in the path.
* Discovering the network path and relevant cellular nodes for the
application: the Information Server must ascertain the network
path from the Application Server to the Client, identifying key
network nodes like gNBs. This might involve leveraging 5G
network's Service Based Architecture to query information from
core network functions such as the AMF.
* Communication between the application and the Information Server:
following discovery, a new connection may be established between
Information Server and the Application Server of Client for the
exchange of network information. QUIC may be used to secure and
authenticate this communication. This setup allows for the
periodical or on-demand request and retrieval of network data
relevant to optimizing application behavior.
* Security and privacy: just as in the on-path model, all signaling
must utilize as little information as possible to achieve the
desired result and all information exposure should be transparent
to both the users to adhere to the principles of minimal
information exposure and user consent. The process should also
allow for negotiation of signaling parameters to ensure trust
between the application and Information Server. Encryption and
authentication should be applied for all communications. In order
to facilitate widespread adoption, Information Server must be
secure.
Mertus, et al. Expires 2 September 2024 [Page 15]
Internet-Draft MoWIE for Network Aware Application March 2024
* Scalability: again, the design must ensure that the off-path
signaling mechanism does not adversely impact the primary
application's functionality. A dynamic association between
Information Servers and network regions may be necessary to ensure
that the system scales efficiently with the number of users and
fluctuating network conditions without overburdening the
Information Server.
* Application control and user consent: similar to the on-path
model, off-path signaling should be initiated under the
application's control. We again prefer starting with a pull model
to ensure information exposure is entirely optional and under the
application's control. The application can choose to request only
the network information desired, only when it is desired.
* Robustness: given the dynamic nature of mobile networks, the off-
path signaling process must be capable of adapting to changes such
as network reconfigurations, user mobility, and varying network
conditions. The function of discovering the relevant Information
Server and network path must be repeated periodically to ensure
the application server is always communicating with the relevant
Information Server and receiving the most up-to-date network
information.
When in use, the off-path model can be visualized as follows:
Information Server
+--------------+
- - - | | - - -
/ | | \
/ | | \
/ +--------------+ \
/ \
Client Application gNB Application Server
+---+ +--------------+ +----------------+
| |-------------| |---------| |
| | | | | |
| | | | | |
+---+ +--------------+ +----------------+
------------ - - - - - - - -
application connection MoWIE connection
Mertus, et al. Expires 2 September 2024 [Page 16]
Internet-Draft MoWIE for Network Aware Application March 2024
5.2. Security Considerations
The introduction of the Information Server brings several security
challenges. Even when applying a principle of minimal information
exposure, the Information Server must have access to detailed network
path information, which implies certain user privacy concerns. It is
essential to implement strict retention policies to ensure sensitive
data is discarded as soon as it is no longer needed. This concern
provides additional emphasis to the need for robust authentication
and encryption between the Application Server and the Information
Server.
5.3. Benefits and Challenges
Off-path signaling provides several benefits. First, by decoupling
the network information delivery from the direct data path, we reduce
the potential for bottlenecks and scalability issues associated with
on-path signaling. Also, regarding extensibility, off-path signaling
allows for the integration of broader network information not
available to on-path entities.
Although off-path signaling exposes sensitive information to a new,
non-essential entity, this security risk is offset by removing the
necessity to mess with an existing QUIC connection, which itself
introduced a risk to the original data path. We also observe that
applying an off-path approach may reduce the possibility that this
signaling mechanism will affect the core functionality of the
application.
Just as gNBs in the on-path approach, the Information Server is a
potential bottleneck and point of failure. Robust error handling and
failover mechanisms, similar to those required for gNBs, must be
designed to ensure resilience. These strategies may be applied if
the off-path node becomes unavailable for any reason. Since the off-
path node is not responsible for the original data path, the
potential for bottlenecks is reduced.
One final drawback of this approach is that it explicitly requires
the periodic rediscovery of Information Server to accommodate client
mobility. In the on-path approach this may be handled implicitly by
the gNB. This adds additional overhead and may impact scalability.
6. IANA Considerations
This document has no actions for IANA.
Mertus, et al. Expires 2 September 2024 [Page 17]
Internet-Draft MoWIE for Network Aware Application March 2024
7. Security Considerations
The collection, distribution of MoWIE information should consider the
security requirements on information privacy and information
integration protection and authentication in both sides. Since the
network status is not directly related to any special user, there is
currently no any privacy issue. But the information transmitted to
the application can pass through a lot of middle box and can be
changed by the man in the middle. To protect the network
information, an end to end encryption and integration is needed.
Also, the network needs to authenticate the information exposure
provided to right applications. These security requirements can be
implemented by the TLS and other security mechanisms.
8. Acknowledgments
The authors would like to thank Huang Wei and Mohamed Boucadair for
their contribution and technical review comments to the previous
versions of this draft.
9. References
9.1. Normative References
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.
9.2. Informative References
[ALTO_METRICS]
"Internet-Draft, draft-ietf-alto-performance-metrics-09",
" ALTO Performance Cost Metrics", 2020,
<https://tools.ietf.org/html/draft-ietf-alto-performance-
metrics-09>.
Mertus, et al. Expires 2 September 2024 [Page 18]
Internet-Draft MoWIE for Network Aware Application March 2024
[ALTO_USE_CASES]
"Internet-Draft, draft-li-alto-cellular-use-cases-00",
" Requirements and reference architecture for Mobile
Throughput Guidance Exposure", 2021,
<https://datatracker.ietf.org/doc/html/draft-li-alto-
cellular-use-cases>.
[CS2P] Sun, Yi., Yin, Xiaoqi., Jiang, Junchen., Sekar, Vyas.,
Lin, Fuyuan., Wang, Nanshu., Liu, Tao., and Bruno.
Sinopoli, "CS2P: Improving Video Bitrate Selection and
Adaptation with Data-Driven Throughput Prediction",
DOI 10.1145/2934872.2934898, 2016,
<https://doi.org/10.1145/2934872.2934898>.
[draft-ietf-dmm-5g-uplane-analysis]
"Internet-Draft, draft-ietf-dmm-5g-uplane-analysis-04",
" ALTO Uses Cases for Cellular Networks", 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-dmm-5g-
uplane-analysis-04#section-4.1>.
[ETSI_MEC] "ETSI GS MEC 012", "Multi-access Edge Computing
(MEC); Radio Network Information API", 2019,
<https://www.etsi.org/deliver/etsi_gs/MEC/>.
[Fahad] Fazal Elahi Guraya, Fahad., Alaya Cheikh, Faouzi., and
Victor. Medina, "A Novel Visual Saliency Model for
Surveillance Video Compression",
DOI 10.1109/SITIS.2011.84, 2011,
<https://doi.org/10.1109/SITIS.2011.84>.
[flinck_mobile]
"Internet-Draft, draft-flinck-mobile-throughput-guidance-
04", " User Plane Protocol and Architectural Analysis on
3GPP 5G System", 2017,
<https://datatracker.ietf.org/doc/html/draft-flinck-
mobile-throughput-guidance-04>.
[Hongzi] Mao, Hongzi., Netravali, Ravi., and Mohammad. Alizadeh,
"Neural Adaptive Video Streaming with Pensieve",
DOI 10.1145/3098822.3098843, 2017,
<https://doi.org/10.1145/3098822.3098843>.
[MengZ] Meng, Z., Guo, Y., Sun, C., Wang, B., Sherry, J., Liu, H.
H., Xu, M. (2022), "Achieving Consistent Low Latency for
Wireless Real-Time Communications with the Shortest
Control Loop", DOI 10.1145/3544216.3544225, 2022,
<https://zilimeng.com/papers/zhuge-sigcomm22.pdf>.
Mertus, et al. Expires 2 September 2024 [Page 19]
Internet-Draft MoWIE for Network Aware Application March 2024
[MPC] Yin, Xiaoqi., Jindal, Abhishek., Sekar, Vyas., and Bruno.
Sigopoli, "A Control-Theoretic Approach for Dynamic
Adaptive Video Streaming over HTTP",
DOI 10.1145/2785956.2787486, 2015,
<https://doi.org/10.1145/2785956.2787486>.
[MPEGDASH] ISO/IEC, "ISO/IEC 23009, Dynamic Adaptive Streaming over
HTTP", 2020,
<https://mpeg.chiariglione.org/standards/mpeg-dash>.
[PBECC] Xie, Yaxiong, Fan Yi, and Kyle Jamieson, "PBE-CC:
Congestion control via endpoint-centric, physical-layer
bandwidth measurements", DOI 10.1145/3387514.3405880,
2020,
<https://dl.acm.org/doi/pdf/10.1145/3387514.3405880>.
[PQoS_white_paper]
"Making 5G Proactive and Predictive for the Automotive
Industry", " 5GAA Automotive Association, Tech. Rep.",
2020, <https://5gaa.org/wp-content/
uploads/2020/01/5GAA_White-Paper_Proactive-and-
Predictive_v04_8-Jan.-2020-003.pdf>.
[RFC9419] T. Hardie, J. Arkko, T. Pauly, M. Kühlewind,
"Considerations on Application - Network Collaboration
Using Path Signals", July 2023,
<https://datatracker.ietf.org/doc/rfc9419/>.
[Saccadic] Matin, E., "Saccadic suppression: A review and an
analysis", DOI 10.1037/h0037368, 1974,
<https://doi.org/10.1037/h0037368>.
[SADCDN] Joras, M., "Secure Ancillary Data Communication for CDN
Interactions", July 2023,
<https://datatracker.ietf.org/doc/html/draft-joras-sadcdn-
01>.
[Saliency] Guo, C. and L. Zhang, "A Novel Multiresolution
Spatiotemporal Saliency Detection Model and Its
Applications in Image and Video Compression",
DOI 10.1109/TIP.2009.2030969", 2017,
<https://doi.org/10.1109/TIP.2009.2030969>.
[SCONEPRO] Joras, M., "Securing Ancillary Data for Communicating with
Devices in the Network", February 2024,
<https://datatracker.ietf.org/doc/bofreq-joras-scone-
protocl-the-topic-formerly-known-as-sadcdn/>.
Mertus, et al. Expires 2 September 2024 [Page 20]
Internet-Draft MoWIE for Network Aware Application March 2024
[Sprecher_mobile]
"Internet-Draft, draft-sprecher-mobile-tg-exposure-req-
arch-03", " Mobile Throughput Guidance Inband Signaling
Protocol", 2017, <https://datatracker.ietf.org/doc/html/
draft-sprecher-mobile-tg-exposure-req-arch-03>.
[TS23.501] "3rd Generation Partnership Project (3GPP)",
"System architecture for the 5G System (5GS)", 2021,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
[TS26.114] "3rd Generation Partnership Project (3GPP)",
"IP Multimedia Subsystem (IMS); Multimedia telephony;
Media handling and interaction", 2021,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=1404>.
[TS26.247] "3rd Generation Partnership Project (3GPP)",
"Progressive Download and Dynamic Adaptive Streaming over
HTTP(3GP-DASH)", 2020,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=1444>.
[TS38.211] "3rd Generation Partnership Project (3GPP)", "NR; Physical
channels and modulation", 2017,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3213>.
[TS38.214] "3rd Generation Partnership Project (3GPP)", "NR; Physical
layer procedures for data", 2021,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3216>.
[TS38.300] "3rd Generation Partnership Project (3GPP)", "NR; NR and
NG-RAN Overall description; Stage-2", 2017,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3191>.
[TS38.323] "3rd Generation Partnership Project (3GPP)", "NR; Packet
Data Convergence Protocol (PDCP) specification", 2017,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3196>.
[TS38.331] "3rd Generation Partnership Project (3GPP)", "NR; Protocol
specification", 2017,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3197>.
Mertus, et al. Expires 2 September 2024 [Page 21]
Internet-Draft MoWIE for Network Aware Application March 2024
Authors' Addresses
Daniel Mertus
Yale University
Unit 404, 367 Elm Street
New Haven, CT 06511
United States of America
Email: daniel.mertus@yale.edu
Yuhang Jia
Tencent
Flat 9, No. 10 West Building, Xi Bei Wang East Road
Beijing
100090
China
Email: tonyjia@tencent.com
Yunfei Zhang
Tencent
Flat 9, No. 10 West Building,Xi Bei Wang East Road
Beijing
100090
China
Email: yanniszhang@tencent.com
Y. Richard Yang
Yale University
Watson 208A, 51 Prospect Street
New Haven, CT 06511
United States of America
Email: yang.r.yang@yale.edu
Gang Li
China Mobile Research Institute
No.32, Xuanwumenxi Ave, Xicheng District
Beijing
100053
China
Email: ligangyf@chinamobile.com
Yixue Lei
Tencent
Flat 9, No. 10 West Building,Xi Bei Wang East Road
Mertus, et al. Expires 2 September 2024 [Page 22]
Internet-Draft MoWIE for Network Aware Application March 2024
Beijing
100090
China
Email: yixuelei@tencent.com
Yunbo Han
Tencent
Tencent Building, No. 10000 Shennan Avenue, Nanshan District
Shenzhen
518000
China
Email: yunbohan@tencent.com
S. Randriamasy
Nokia
Nokia Bell Labs
Nozay
United States of America
Email: sabine.randriamasy@nokia-bell-labs.com
Mertus, et al. Expires 2 September 2024 [Page 23]
