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]