Internet Engineering Task Force G. Li
Internet-Draft China Mobile Research Institute
Intended status: Informational S. Randriamasy
Expires: 13 January 2022 Nokia Bell Labs
C. Xiong
Tencent
12 July 2021
ALTO Uses Cases for Cellular Networks
draft-li-alto-cellular-use-cases-00
Abstract
This draft presents a number of use cases of applications running on
endpoints located in cellular networks and whose performances highly
depend on network information. This document first, shows how the
performances of these applications can be further improved with ALTO
provided abstracted network information and transportation means
thereof. Second, upon reviewing the existing ALTO capabilities, it
lists the ALTO features that need to be extended or defined to
support the presented use cases.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 13 January 2022.
Copyright Notice
Copyright (c) 2021 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.
Li, et al. Expires 13 January 2022 [Page 1]
Internet-Draft ALTO Cellular Cases July 2021
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 Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivation And First Considerations . . . . . . . . . . . . . 5
2.1. Overview of challenges for applications on cellular
networks . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Benefits expected from using ALTO to expose network
topology to applications . . . . . . . . . . . . . . . . 6
2.3. First considerations on ALTO information features for
wireless network . . . . . . . . . . . . . . . . . . . . 7
3. Example applications and use cases . . . . . . . . . . . . . 8
3.1. Use case 1: rate adaptation for cloud VR/gaming . . . . . 8
3.1.1. Application needs in information capabilities from
network . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Missing ALTO information and features . . . . . . . . 10
3.2. Use case 2: Video-conferencing applications . . . . . . . 11
3.2.1. Application needs in information capabilities . . . . 12
3.2.2. How the application can get the 5G network information
from ALTO . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Use case 3: ALTO supporting applications on UEs . . . . . 14
3.3.1. Use case: Access-aware AEP selection from UE with
cascaded ALTO Servers . . . . . . . . . . . . . . . . 14
3.3.2. Scenario and assumptions . . . . . . . . . . . . . . 14
3.3.3. Missing ALTO information and features . . . . . . . . 15
4. Highlights on 3GPP Information Useful to ALTO . . . . . . . . 15
5. Gap analysis with Existing ALTO features . . . . . . . . . . 16
5.1. ALTO limits w.r.t. Cellular Network Information . . . . 16
5.2. ALTO Limits on network information transport: gap analysis
with ALTO SSE . . . . . . . . . . . . . . . . . . . . . . 16
6. Summarizing ALTO added value and gaps for cellular
networks . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Summarizing ALTO added value to cellular use cases . . . 17
6.2. Summarizing new ALTO features needed to support cellular
use cases . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.1. ALTO Cellular Network Information . . . . . . . . . . 18
6.2.2. Efficient transport for ALTO Cellular Network
Information based on SSE . . . . . . . . . . . . . . 18
6.2.3. Time constraints on ALTO-provided Cellular Network
Information . . . . . . . . . . . . . . . . . . . . . 19
Li, et al. Expires 13 January 2022 [Page 2]
Internet-Draft ALTO Cellular Cases July 2021
6.2.4. ALTO notifications to non-GBR as well as GBR
traffic . . . . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
The ALTO protocol has been defined as modern network traffic started
to convey a majority of user-initiated multimedia flows comprising
essentially video payload. The purpose of ALTO is to alleviate
network costs, congestion and load while maintaining application
performances. To this end, ALTO provides to applications that have a
choice among several endpoint location. This guidance consists for
ALTO in exposing a Network Map that is a subjective abstraction of
the Internet provider network. The Network Map is an arbitrary
provider-defined partition of the provider topology in zones that
have a human-readable identifier named PID and that gather network
endpoints that may be treated similarly, see RFC7285 sec 5.1. Among
these PIDs, the ALTO Cost Map defines abstracted network costs.
The design of ALTO is flexible and generic enough to support further
evolutions of application traffic and enable lightweight protocol
extensions. In particular as per section 5.2 of RFC7285, "There are
many types of addresses, such as IP addresses, MAC addresses, or
overlay IDs.", while the 7285 "document specifies (in Section 10.4)
how to specify IPv4/IPv6 addresses or prefixes." Likewise, the time
granularity of ALTO path costs was intended in the initial
requirements of RFC6708 to be in the order of days or more,
extensions such as RFC 8688 specifies the value encoding in floating
numbers, allowing thus smaller time interval durations.
Nevertheless, ALTO is by no means meant to provide information in
real-time.
Li, et al. Expires 13 January 2022 [Page 3]
Internet-Draft ALTO Cellular Cases July 2021
In the first two WG charters, the ALTO applications and use cases
have focused on applications using network maps, cost maps defined on
IP Networks. Nevertheless, while the central use case in the base
protocol was peer-to-peer file sharing, the ALTO WG progressively
moved to CDN use cases, following thus the usage trend and the needs
of the service providers exposing their network abstraction. This
has produced extensions supporting finer grained information in terms
of network capabilities and time span. Applications are today
evolving to require more resources, performance, service presence and
reactivity.
Modern Applications now span endpoints in both fixed and cellular
networks. They are usually catered by Servers located at the edge or
within the core network. Servers view and manage IP flows while
Clients are associated to one or more flows defined according to
their hosting network technology. For example, a Client located in
3GPP defined cell is mapped to a so-called QoS flow, that may map to
one or more IP flows, either because the application involves say
voice or video, or because the user equipment (UE) is running several
applications simultaneously. These applications are also the most
Quality of Experience (QoE ) demanding ones.
The COVID period has witnessed frequent service degradation and
interruption in applications such as videoconferencing or gaming on a
mobile phone. The Servers need to be reactive enough to correctly
adapt their resources to the challenged users. To do so, they need
to have a reliable view of the network capabilities and bottlenecks,
while that view should cover application paths end to end and not
only at the user access network. There is a strong need for
application vendors to sustain user QoE, especially low latency and
acceptable throughput. Given the number of user flows, the
complexity of the network and sensitivity of user and network
information, the application server should get all and only what
information it needs. In other words, the network abstraction
exposed to applications must be reliable, preserve confidentiality,
suit the application needs and minimize the data exchange volume.
This draft emphasizes the importance of abstracted cellular
information, as the cell resides in the last IP hop, which is usually
the bottleneck. Therefore, last hop network information is critical.
It is important to have end to end information for apps having
cellular user footprint that covers both the edge and core Internet
and the access plus the cloud. The current networking SDOs such as
3GPP, ETSI, IETF do not cover all these areas simultaneously but
provide each a separate focused view. Note that it is the same for
Open Source organizations such as Open RAN (ORAN) or Facebook
sponsored - Open Computing Platform (OCP) providing in-band telemetry
info for DC networks.
Li, et al. Expires 13 January 2022 [Page 4]
Internet-Draft ALTO Cellular Cases July 2021
This draft focuses on popular applications that have a user footprint
in cellular networks. It explores on one hand the requirements of
such applications in terms of network information, the capabilities
of 3GPP network information functionalities such as the Network
Exposure Function (NEF), and their the missing. On the other hand,
it explores what ALTO may potentially provide to compensate and
extend the scope of 3GPP information. The draft is thus motivated by
the following "gaps" between ALTO and 3GPP:
* Cellular information provided by 5G is limited in 2 ways: RAN
scope only, and QoS negotiation for only given type of traffic
(GBR),
* ALTO on the other hand is generic regarding the type of access.
However, it lacks small grain information and its dynamicity is
currently limited. Above all, the ALTO protocol and its
extensions are specified for IP networks.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology
TO BE COMPLETED
QoS, ABR, RTT, GBR, XR/VR, AR, CGS
2. Motivation And First Considerations
2.1. Overview of challenges for applications on cellular networks
This section lists some challenges faced by applications running on
cellular networks that motivate the definition of ALTO-based network
topology exposure to improve application performance.
* New popular applications running on mobile networks: The current
ALTO protocol exposes endpoint addresses or path information.
ALTO was initially designed for P2P file or chunked data download
applications. Nowadays, P2P-like applications are no more widely
used. Instead, mobile internet got more popular, the price to buy
legal music/video/ebook files for download or streaming from a
dedicated service provider have dramatically reduced.
Consequently, there is little need to allow a user to change the
destination server address the path to destination server. The
major challenge now is to better support applications running on
Li, et al. Expires 13 January 2022 [Page 5]
Internet-Draft ALTO Cellular Cases July 2021
the mobile internet. In 5G networking, selection of an
destination application server and related path is no major issue:
the 3GPP has defined a mechanism in [TS23.548] to let the
application change the Edge Compute server on the fly during the
download, where this change is automatic and transparent to the
user. A bigger issue, in 5G networks, is how to adapt the
application behavior, based on the data rate fluctuation in the
mobile network.
* 5G low-level network information too complex for application
developers: Too detailed radio level (low layer) parameters are
very hard to be understood by the application developers and are
thus very hard to be tested for the application development and
deployment.
* Notifications of RAN changes restricted to GBR traffic: In 5G
networks, notifications to CGS of QoS level change are currently
sent only for Guaranteed Bit Rate (GBR) traffic whereas they
should be used for non-GBR traffic as well.
2.2. Benefits expected from using ALTO to expose network topology to
applications
The first and fundamental benefit expected from ALTO is the ability
to expose simple and abstracted network topology information to
applications. An ALTO Client collocated with an application server
could easily get concise and safe information allowing adaptive
application behavior and QoE maintenance. Besides, with ALTO and its
handy JSON contents, application developers can take advantage of the
ALTO services to rapidly develop and update wireless applications
with less changes in their code.
Another important benefit is the ability of ALTO to support to
exposition to applications of the QoS supported by a path, given that
the supported QoS may vary over time. A fundamental ALTO service to
support the 5G would be the notification of different bit rates
supported in the access network. Providing such path QoS
notification to is of highest importance, as it allows the
applications to appropriately adapt their behavior, that is, in the
present case, their bitrate. Given that the path QoS can vary very
quickly, the information exchange must be fast, with simple terms,
while moderating the volume of exchanged information.
A first step in this direction is to introduce the definition of
three levels of path QoS supported for applications, that can be
defined in abstracted from 3GPP in ALTO terms. Each level may draw
specific requirements on the interaction between ALTO Client and ALTO
Server.
Li, et al. Expires 13 January 2022 [Page 6]
Internet-Draft ALTO Cellular Cases July 2021
* Basic Level: for e.g. video streaming; normal data rate, and loose
latency requirements (e.g. network transport latency lower that
150ms)). In such case, the ALTO interaction can use the basic QoS
Notification Control (QNC) and alternative QoS profile (different
bit rate) defined in 5G.
* Medium Level: for e.g. conference call; high data rate (e.g.
higher than 5Mbps), but moderate vlatency requirement (e.g.
network transport lower than 150 ms). In this case the ALTO
interaction can use the QNC and small measurement time.
* Hard/complex Level: for e.g. cloud gaming, XR/VR services; high
data rate (e.g. higher than 5Mbps) and low latency (lower than
10ms for network transport, lower than 100ms end to end in service
level) services. More technologies are being studied in 3GPP R18.
e.g. new QoS Notification Type.
It is desirable to have the same data model in ALTO to express the
different QoS values or levels for different the use cases.
2.3. First considerations on ALTO information features for wireless
network
This draft does not aim at defining ALTO extensions to support
applications on cellular networks. This section lists some initial
considerations that would characterize such extensions.
Firstly, the use cases and associated needs of this draft do not
restrict to 5G cellular networks. They cover potential application
queries for ALTO network information that happen within the first IP
hop. Such needs may be true for 4G and 5G networks.
Currently in ALTO, the only way for an application to get a more
adequate QoS level is to use another path by selecting another
endpoint. In a wireless network, the application must use the same
path in which the QoS can change over time. The end user cannot
create or select another path during an application session. But
because of the physics of the wireless, the QoS of the wireless
connection may change quickly, so the application in the end user and
in the application server needs to detect the change of the QoS value
and adapt the application bit rate accordingly. Therefore, if the
ALTO service is used in a wireless network, we need to extend ALTO to
support only one path but with changes in the path cost or supported
QoS that occur very quickly, e.g. within seconds or sub-seconds.
A first architectural assumption is needed here for the ALTO Server
that would expose "below 1st hop" network information. We assume the
availability of a Local ALTO Server, that manages the information
Li, et al. Expires 13 January 2022 [Page 7]
Internet-Draft ALTO Cellular Cases July 2021
covering the "below" first IP hop area delineated by the UEs and the
Packet Data Network (PDN). In the use cases of this draft a Local
ALTO Server may cover a 4G or 5G topology. It is queried by ALTO
Clients that may be associated to application functions in the
network edge or in end systems. It is not scalable to provide ALTO
information on paths from all UEs to all application endpoints in the
Internet. Therefore, it is desirable to use "cascaded" ALTO Servers,
where a local server covers the relevant access area and can, if
needed compose its information with a "core" ALTO Server that manages
information at an IP hop level or above. Such a solution is proposed
in sections 5.1 of [alto-cost-context] and section 2.3.3 of RFC 7971
on deployment cases. Thus:
* A Local ALTO Server (LAOS): covers a local and restricted part of
the network. It is typically located before the Internet gateway,
in the access network. For example, it can be collocated with the
NEF, as in the Cloud Gaming use case or with a gateway. It hosts
the information on the local 4G/5G network, covering the paths
between e.g. the UEs and the cells or the PGWs/UPFs. It may host
an ALTO Client that sends an ALTO request to a "core" ALTO Server,
covering the zone beyond the PGW/UPF.
* A "core" ALTO Server covers the whole ISP network view, at the IP
and beyond level, as it would if the "local ALTO Service" is not
available or deactivated. That is, it does not see the details
below the (UE, PGW/UPF) hop.
3. Example applications and use cases
This section presents emblematic examples of application use cases on
cellular networks. For each use case, it lists the network
information needed to maintain or improve application performances,
which one is available from 3GPP and from ALTO, which ones are
missing. Current examples applications are: Cloud gaming,
Conferencing, and use cases are divided in network-based decision
making and UE-based decision making.
3.1. Use case 1: rate adaptation for cloud VR/gaming
FOR FURTHER VERSIONS: Need artwork based on slide 1 of "ALTO
Recharter for Wireless Use cases-V6SR-2004"
5G is beginning to be commercialized globally since 2020, and there
is a great improvement regarding bandwidth enhancement and latency
reduction. Cloud-based interactive streaming applications such as
cloud Virtual Reality (VR) and cloud gaming are booming.
Li, et al. Expires 13 January 2022 [Page 8]
Internet-Draft ALTO Cellular Cases July 2021
This type of applications requires low latency and highly reliable
transmission of motion tracking instructions from user to server in
the cloud, while the cloud is required to perform the rendering of
pictures per frame and deliver them to users with usually low latency
and high data rate. The required end-to-end transmission delay may
be as low as 20ms. The less the latency, the better the user QoE as,
for instance, a slight extra delay may cause user dizziness. The
downlink bandwidth normally depends on different parameter settings
such as DoF (Degree of Freedom), image resolution, frame rate,
adapted rendering and compression algorithm. For example, a high
definition with 1080p with 60 frames per seconds may require at least
20Mbps and ultra-high definition with 4K may require more than
40Mbps.
Cloud VR/gaming is regarded as one of killer applications as well as
major traffic contributor to cellular 5G networks. The major
advantages of cloud VR/gaming are easy and quick start since there is
no need to download and install a big volume of software in the user
device beforehand, and also it is cost effective and demands too
moderate processing load in the user device. Last, it is also
regarded as a more trusted solution. Thus, cloud gaming becomes a
competitive replacement for console gaming using cheaper PCs or
laptops. On one hand, the above cloud-based interactive applications
normally require high bandwidth and low latency, on the other hand, a
larger radio bandwidth implies larger variations since radio
resources are shared and competed by mobile users in a cell.
Therefore, the last mile radio link is viewed as the bottleneck of
the QoE.
To address this problem, the application usually estimates available
bandwidth based on application-level measurements such as traffic
throughput, RTT and latency. It then uses an adaptive bitrate (ABR)
mechanism to change the video encoding bitrate so as to match the
fluctuation of radio bandwidth. However, it is hard to accurately
estimate or predict user cellular link status only from the
application's perspective since only the cellular network has a full
understanding of all users' radio channel status, traffic
fluctuation, moving in and out of cells. Moreover, bandwidth
estimation based on application level traffic throughput statistics,
rather than radio channel capabilities may be inaccurate.
3.1.1. Application needs in information capabilities from network
Based on the above use case analysis, it would be beneficial if the
cellular network could inform the cloud streaming application on the
cellular network link status. The following approaches may be
considered.
Li, et al. Expires 13 January 2022 [Page 9]
Internet-Draft ALTO Cellular Cases July 2021
* The application uses request/response to query the link status
from the cellular network for a specific user. This may cause
extra latency since two way signaling is required.
* The cellular network periodically reports network link status to
the application. This may cause extra signaling overhead if the
reporting period threshold is too frequent.
* The application uses a pub/sub-like mechanism, specifically, the
application may subscribe a certain condition (for example,
whether the QoS requirement is satisfied or significant QoS change
happens) for cellular network. As soon as the predefined
condition is fulfilled, the notification will be triggered
immediately and if the condition is not triggered, no signaling is
involved. Obviously, this approach is more cost effective from
signaling point of view and timely compared with request/response.
The application may inform the cellular network of the following
information ( not exhaustive list, new information may be added
later):
* QoS requirements of application, e.g., min and/or max bandwidth,
latency
* Significant QoS changes, e.g., 30% drop of bandwidth change
The cellular network link status may include the following
information (not exhaustive list, new information may be added
later):
* The available bandwidth and latency of the cellular network
* Whether QoS requirements of application are satisfied or not by
the radio network
* Whether significant QoS changes happen
3.1.2. Missing ALTO information and features
However, the current ALTO protocol and extensions are missing the
following information.
Li, et al. Expires 13 January 2022 [Page 10]
Internet-Draft ALTO Cellular Cases July 2021
* The ALTO representation of the QoS of an application path requires
to represent the path endpoints. That is the path source and
destination. It the ALTO Endpoint Cost Service (ECS) is used, it
requires to indicate the endpoints. This is possible for the
destination, as it is the CGS, usually identified with an IP
address. However, the UE address would to be identified with an
identifier relating to cellular address. And the current ALTO
protocol only supports IP addresses.
* One possible workaround would be to identify a cell as a PID.
However, a PID MUST specify the network addresses it contains and
only IP addresses are supported. The path cost from a UE/Cell to
a CGS should be specific to a cell, but the IP address that is
provided to the UE is not. The ALTO Server should ensure that the
metric used to indicate the quality of the path to a CGS reflects
the specifics of a cellular network.
3.2. Use case 2: Video-conferencing applications
In the current context of massive teleworking, reliable video-
conferencing tools are of utmost importance. Poor experience or
service interruption occur more than often and may be caused by
factors impacting functions at both the Server end and the UE end.
In 2019, over 500 million active users were using online personal
live show services in China and there are 4 million simultaneous
online audience watching a celebrity's show. Low delay live show
requires the close interaction between application and network.
Compared with conventional broadcast services, this service is
interactive which means the audience can be involved and is able to
provide feedback to the anchorwoman or the anchorman of the game. A
gaming show has almost the same QoS requirements as
videoconferencing. It broadcasts the game playing to all the
audience, and also requires playing game interaction between the
anchor and the audience. A delay lower than 100ms is desired. If
the delay is too large, there will be undesirable degradation on user
experiences especially in a large-scale show. To lower the latency
and provide size-adjustable show content, the application also
requires QoS information of the transport layer of the wireless.
Li, et al. Expires 13 January 2022 [Page 11]
Internet-Draft ALTO Cellular Cases July 2021
3.2.1. Application needs in information capabilities
The bit rate of radio link changes quickly. If the bit rate is
downgraded and the application still uses the previous bit rate to
send in the downlink to the user, the RAN will soon be in congestion
state, the user video will be frozen and user's QoE will be very bad.
So, the application needs to detect the bit rates of the transport
network. The DASH-based mechanism defined in MPEG can be used.
However, while the DASH based mechanism is normally for the file
download type video streaming, it is not suitable for the interactive
video. In the interactive video case, the transport can provide the
supported bit rate to the application, and application can adaptively
change its video bit rate down to the supported network bit rate and
there is no congestion anymore [TS 23.501]. The QoS Flow in the 5G
cellular network is established to transport the video streaming for
the conference, and application server may request the 5G network to
provide network information by the steps as described below, and
specified in [TS23.501]:
* The application requests the 5G network to notify the link status
and indicate whether the required GFBR (Guaranteed Flow Bit Rate)
can no longer be guaranteed or can be guaranteed again.
* The cellular network will notify the application that "GFBR can no
longer be guaranteed" if the radio link cannot provide the
required guaranteed bit rate. However, it does not specify the
amount of guaranteed bit rate. In this case, the cloud video
server (normally the medio server) will downgrade the video
streaming bit rate in order to avoid the video service being
frozen. However, since the video server does not know the
currently supported bit rate, the downgraded bit rate may be still
higher than the supported bit rate. After receiving the above
notification, the video service may still be frozen frequently.
If the video server downgrades the bit rate two much, the quality
of the video may be too downgraded and the user QoE becomes
unacceptable.
* The cellular network will notify the application that "GFBR can no
longer be guaranteed and the supported bit rate is XXX" if the
radio link cannot provide the required guaranteed bit rate, but
the cellular network can provide additional information of
supported guaranteed bit rate. Upon receiving this notification,
cloud video server can downgrade the video streaming bit rate
below the indicated bit rate. In such case, the user QoE does not
downgraded too much.
Li, et al. Expires 13 January 2022 [Page 12]
Internet-Draft ALTO Cellular Cases July 2021
* The cellular network will notify the application that "GFBR can be
guaranteed again" if the radio link can provide the required
guaranteed bit rate again (for example, the user handovers to
another radio station). After receiving this notification, the
cloud video server can upgrade the video streaming bit rate to the
previous required guaranteed bit rate. In such case, the user QoE
can be recover to the best.
The application may inform the cellular network of the following,
given that the list below will be completed in the future:
* QoS requirements of application, e.g., the guaranteed bit rate,
the alternative guaranteed bit rate.
* The measurement time for the guaranteed bit rate, e.g. 2 seconds
(i.e. 2000ms) or 200/500 ms (to improve the response time, i.e.
more quickly to provide QoS Notification from the 5G RAN).
The cellular network link status exposed to the application may
include the following, given that the list below will be completed in
the future:
* "GFBR can no longer be guaranteed",
* "GFBR can no longer be guaranteed and the supported bit rate is
XXX",
* "GFBR can be guaranteed again".
All in all, the network should more quickly provide QoS Notification
to the application
3.2.2. How the application can get the 5G network information from ALTO
The application (i.e. the ALTO client) can use the restful API to
subscribe and be notified by the message from the ALTO Server, the
application can adaptively change its encoding scheme to make the bit
rate just below the provided network bitrate notified by the network.
Also, the application can be pushed to get the message from the ALTO
server using the SSE as defined in RFC 8895[RFC 8895].
Li, et al. Expires 13 January 2022 [Page 13]
Internet-Draft ALTO Cellular Cases July 2021
3.3. Use case 3: ALTO supporting applications on UEs
This section presents use cases where a UE runs an application with
the support of an ALTO Client. The application in the UE needs to
decide to which application endpoint (AEP) in the Internet to
connect. An AEP is assumed to be an application server for e.g.
content download, videoconferencing, or other applications for which
many servers are deployed. For now, the ALTO-based selection of an
AEP is usually done in the network, sometimes with the help of an
authoritative entity based on the cost or performance of the path
from the UE to the AEP. However, the capabilities of the access
network, in the first path IP hop, may highly impact the application
performance and therefore needs a deeper insight. The use cases in
this section illustrate how network abstraction within the first hop
can be beneficial to optimize application path performance.
3.3.1. Use case: Access-aware AEP selection from UE with cascaded ALTO
Servers
In this use case, a UE is located in a 4G or 5G network and may
connect via several access technologies, e.g. 4G/5G Cellular or WiFi.
It is assumed that the UE has subscribed to the same ISP for both
fixed and mobile access with a given Service Level Agreement SLA.
Users and ISPs tend usually prefer fixed or WiFi connection to
cellular, because it is cheaper, more performant and cellular
resources are limited. However, it is observed that in many places,
including some urban areas in countries with a good average network
infrastructure, the fixed network coverage is very poor and worse
than the cellular coverage, so that users need to connect via a cell
phone or a 4G/5G dongle. Sometimes also, MNOs and ISPs have spare
data resources or offer them for free or at low price to users,
depending on their SLA. For both parties, access-aware Endpoint
selection for users is thus beneficial.
The major QoE challenges in wireless network arise in the access
network, that is, in the first hop, between the UE and its one or
more associated packet data network gateways (PGW for 4G) or user
plane function (UPF for 5G). The path of a UE to its associated PGW/
UPF impacts the path to the AEP and thus the application QoE.
Therefore, once the PGW/UPF has been selected and will stay
unchanged, it is beneficial to help the UE selecting between Cellular
and WiFi access.
3.3.2. Scenario and assumptions
The end to end path from the UE to the AEP is considered in 2 parts
* the path from the UE to the PDN,
Li, et al. Expires 13 January 2022 [Page 14]
Internet-Draft ALTO Cellular Cases July 2021
* the path from the PDN to the AEP.
FOR FUTURE VERSIONS: ARTWORK ON SCENARIO
We assume the availability of multiple cascaded ALTO Servers, as
mentioned in section XXXX, to provide a (UE, AEP) path cost. In our
"cascaded" use case, we define 2 types of servers involved in
conveying the end to end ALTO (UE, AEP) path cost, as follows:
* A Local ALTO Server (LAOS): hosts the information restricted to
the local 4G/5G network, covering the paths between e.g. the UEs
and the cells or the PGWs/UPFs. It receives the ALTO request
issued by the local ALTO Client LAOC associated to the UE. It May
host an ALTO Client that can send an ALTO request to a "core" ALTO
Server, covering the zone beyond the PGW/UPF, if needed by the
application. It composes, when applicable, the response of the
"core" ALTO Server with its own response to the LAOC query to
obtain a better-informed end to end view of the application path.
* A "core" ALTO Server covers the whole ISP network view, as it
would if the "local ALTO Service" is not available or deactivated.
That is, it does not see the details below the (UE, PGW/UPF) hop.
3.3.3. Missing ALTO information and features
However, the ALTO information in the path between a UE and an AEP
currently provides a cost for one single path only. It does not
consider that multiple paths to the PGW/UPF are possible. Currently,
the access technology is accounted in RFC 7971 (on deployment cases)
in the last hop, to prefer selecting an AEP located in a fixed
network over an AEP located in a mobile network. One way to achieve
this is that ALTO provides a path cost that, for a given metric,
takes multiple values each depending on parameters such as access
technology and the access technology or SLA.
4. Highlights on 3GPP Information Useful to ALTO
This section lists the 3GPP information that can be used by ALTO.
Either as it comes in, with a minimal encapsulation, or as input to
an aggregated form.
In 3GPP specifications [TS23.501, 23.502, 23.503], the following
mechanisms have been specified to enable the interaction between AF
(application function) and NEF (network exposure function) from
network's perspective.
* Alternative QoS profiles,
Li, et al. Expires 13 January 2022 [Page 15]
Internet-Draft ALTO Cellular Cases July 2021
* notification control.
The application inform the cellular network of the specific QoS
requirements, which may include a list of QRP( QoS requirement
parameters, such as min/max bandwidth) in a prioritized order. Such
requirements will be conveyed to the RAN and the RAN will always try
to fulfil the QoS requirement in the list with highest priority. And
in the meantime, whether QoS requirements is fulfilled or not in each
item of the list will be notified to the application timely. In
order to avoid too frequent signalling, it is assumed that RAN can
apply hysteresis (e.g., via a configurable time interval) to reduce
too much signalling overhead. On the other hand, the QoS values
within the list of QoS requirements are required not to be too close
to each other.
5. Gap analysis with Existing ALTO features
This section assesses the currently existing ALTO features against
the needs in network information and related transport capabilities
listed along with the use cases.
5.1. ALTO limits w.r.t. Cellular Network Information
ALTO is by design not expected to provide real time information. The
initial use cases were defined for cost maps conveying BGP-based path
costs. Later use cases for CDN and video download on individual end-
systems support finer grained network information. Nothing though
prevents ALTO information to be in minutes or sub-minutes frequency.
ALTO may convey values that are valid for a couple of seconds.
However, an interval of 2 seconds, in regard of a cellular, network
may be too large.
5.2. ALTO Limits on network information transport: gap analysis with
ALTO SSE
In RFC8895, ALTO Incremental Updates Using Server-Sent Events (SSE)
introduces a mechanism to allow an ALTO server to push updates to
ALTO clients to achieve two benefits:
* (1) updates can be incremental, in that if only a small section of
an information resource changes, the ALTO server can send just the
changes
* (2) updates can be immediate, in that the ALTO server can send
updates as soon as they are available.
Li, et al. Expires 13 January 2022 [Page 16]
Internet-Draft ALTO Cellular Cases July 2021
SSE is a well-shaped pub/sub-like mechanism based on subscription,
which quite matches the requirements of proposed cellular use cased
in section XXXX, for example, cost effective and immediate.
Therefore, SSE can be used as a baseline for protocol extension of
cellular use cases. The following message flows can be reused. In
the following figure, init request of step 1 is used to subscribe QoS
requirements. Data update message of step 2a is used to notify
whether subscribed QoS requirements are satisfied or not.
FUTURE VERSIONS: ARTWORK ON SSE COMES HERE
Based on the existing SSE message flows, attributes should be
extended for each message flow for the proposed cellular use cases.
For example, subscribed QoS parameters and conditions in step 1, the
corresponding notification/data update in step 2a.
6. Summarizing ALTO added value and gaps for cellular networks
6.1. Summarizing ALTO added value to cellular use cases
* ALTO abstraction covers several network technologies
* ALTO abstraction covers several network scopes (RAN, edge, core,
transport, WAN)
* ALTO can aggregate network information over several technologies
and scopes
ALTO can provide end to end path information with insight on selected
parts. To our knowledge, standards covering the RAN, the edge, the
transport and the WAN (cite 3gpp, ETSI, others) provide a separate
network view to applications, if ever. There is therefore no way
currently for applications to get an integrated view, allowing more
informed decisions. Additionally, ALTO provides abstracted network
information, that protects operator confidentiality by exposing only
relevant information to applications. This last aspect adds
simplicity to the efficiency gained with network-aware decisions.
Simplicity all the more allows quick decisions, which is crucial in
cellular networks, that have high dynamics.
6.2. Summarizing new ALTO features needed to support cellular use cases
The uses cases presented in this draft are stressing the need for new
or extended ALTO features to convey cellular network information.
This section also lists a number of concerns raised, in some cases,
by the exposure of particular cellular information to third party
applications. Other needs may be identified as the cellular use
cases will be further investigated.
Li, et al. Expires 13 January 2022 [Page 17]
Internet-Draft ALTO Cellular Cases July 2021
6.2.1. ALTO Cellular Network Information
ALTO features to represent identify a cell or a WiFi access point.
Abstracted and simplified metrics and costs for wireless networks:
ALTO Clients can request a list of supported values for a given set
of ALTO metrics. All these metrics are easy to be understood and to
be tested by the application developer and application platform
(service provider). Examples of useful metrics for our use cases
include: throughput/bit rate, latency, priority, error rate, Jitter.
Most of these metrics are being standardized in [alto-performance-
metrics]. However, their values need to be abstracted from the data
provided by the 5G network, typically via the NEF.
Other associated parameters associated to path cost metrics may be
useful. For instance, a new type of useful metric would be an
abstracted form of the time span to measure the bit rate. The
network also needs to expose the attributes of supported alternative
QoS. These include alternative throughput/bit rate, the time span to
measure the bit rate, latency, priority, error rate, Jitter and
associated priority.
Other abstracted and simplified parameters, thresholds or attributes
If radio level or low layer information are provided, a gateway is
needed to translate or map these information to the high level
terminology the ALTO Server. ALTO can then provide the abstracted
information to the application. This gateway can be implemented in
the southbound of the ALTO server and the gateway can be NEF or NWDA,
see reference to 3GPP TS XXx, TS23.288.
6.2.2. Efficient transport for ALTO Cellular Network Information based
on SSE
Improvements are necessary of the following ALTO SSE features:
FUTURE VERSIONS: ARTWORK ON EXTENDED SSE COMES HERE
Based on the existing SSE message flows, attributes should be
extended for each message flow for the proposed cellular use cases.
For step 1 in the procedure of "init request", the following
parameters may be included:
* User IP flow ID, or other information relating to UE IP address
* DL/UL capabilities
* A list of QoS requirements and conditions including: Priority, Min
bandwidth, Max bandwidth, delay threshold
Li, et al. Expires 13 January 2022 [Page 18]
Internet-Draft ALTO Cellular Cases July 2021
For step 2a, the corresponding notification/data update can be
included regarding subscribed QoS parameters and conditions in step
1.
* User IP flow ID, or other information relating to UE IP address
* DL/UL capabilities
* A list of QoS requirements and conditions including: Priority,
current bandwidth or current delay
6.2.3. Time constraints on ALTO-provided Cellular Network Information
The main constraint when conveying ALTO information is speed. When a
significant change occurs in the RAN it should be ideally be notified
to an application in real-time. As this is not feasible with ALTO,
it is necessary to specify constraints such as: acceptable
notification delay, maximum delay beyond which the application
performance would get degraded, parameters defining an acceptable
degradation.
A typical example is as follows. The default measurement time for
the guaranteed bit rate is 2000ms, and the maximum rate of
notification is 1 time every 2 seconds in the case of data rate
fluctuation. This causes too much latency for low latency (lower
than 10ms) and/or high date rate (higher than 20mbps) services such
as cloud gaming. But it is acceptable for normal latency (e.g.
higher than 150ms) and normal data rate (lower than 5mbps) services.
The measurement time can be changed to 500ms or 200ms to improve the
response time, but the total number of notifications should not
increase too much. That is, the total number of notification times
should be the same level with the measurement time = 2000ms in a long
time span such as 1 hour.
As opposed to fixed networks for which ALTO was initially specified,
mobile networks, especially RAN have high traffic and network state
dynamics. ALTO is by no means expected to provide real-time
information. A careful design of 5G metrics abstraction and
hysteresis thresholds triggering ALTO notifications is necessary.
The resulting non-real time but highly dynamic ALTO information can
reduce the volume of data exchanged with the applications and in some
extent facilitate anticipation and reduce oscillations.
Li, et al. Expires 13 January 2022 [Page 19]
Internet-Draft ALTO Cellular Cases July 2021
6.2.4. ALTO notifications to non-GBR as well as GBR traffic
In 5G networks, notifications to CGS are currently sent only for
Guaranteed Bit Rate (GBR) traffic whereas they should be for non-GBR
traffic as well. In practice nothing prevents an ALTO Server to do
so. To this end, the ALTO Server needs to have the necessary
identifiers of the IP flow that is impacted by the network conditions
(or QoS level) change.
7. Acknowledgements
8. IANA Considerations
This draft includes no request to IANA.
9. Security Considerations
FUTURE VERSIONS: TBC
10. References
10.1. Normative References
[min_ref] authSurName, authInitials., "Minimal Reference", 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References
[DOMINATION]
Mad Dominators, Inc., "Ultimate Plan for Taking Over the
World", 1984, <http://www.example.com/dominator.html>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<https://www.rfc-editor.org/info/rfc2629>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
Li, et al. Expires 13 January 2022 [Page 20]
Internet-Draft ALTO Cellular Cases July 2021
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
Appendix A. Additional Stuff
This becomes an Appendix.
Authors' Addresses
Li Gang
China Mobile Research Institute
Beijing
China
Email: ligangyf@chinamobile.com
Sabine Randriamasy
Nokia Bell Labs
Nozay
France
Email: sabine.randriamasy@nokia-bell-labs.com
Chunshan Xiong
Tencent
Beijing
China
Email: chunshxiong@tencent.com
Li, et al. Expires 13 January 2022 [Page 21]