[alto] ALTO recharter to support cellular network use cases

"chunshxiong(熊春山)" <chunshxiong@tencent.com> Wed, 28 October 2020 09:43 UTC

Return-Path: <chunshxiong@tencent.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 428F03A0992 for <alto@ietfa.amsl.com>; Wed, 28 Oct 2020 02:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tencent.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QcJ_rYqCpbG5 for <alto@ietfa.amsl.com>; Wed, 28 Oct 2020 02:43:26 -0700 (PDT)
Received: from mail3.tencent.com (mail3.tencent.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3AF23A098D for <alto@ietf.org>; Wed, 28 Oct 2020 02:43:25 -0700 (PDT)
Received: from EX-SZ019.tencent.com (unknown []) by mail3.tencent.com (Postfix) with ESMTP id A33829413B for <alto@ietf.org>; Wed, 28 Oct 2020 17:43:23 +0800 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tencent.com; s=s202002; t=1603878203; bh=/q8xlkolCclP7p15VAvMbybs8gJpU+WpwHTrhHKvJ5s=; h=From:To:Subject:Date; b=Of13n6skGX2bX6C7+/tMtzpoAE1vOO17imwCWJher8YUliqz4M0tptWqhP7TRRAwR mWSeXwGQmPF2pFD6zxnyKgv+ik5KZRHeDEzQ8qoCZL07pIcuYk3/Uh5h7PMLBCamxl Wjn7EHRkXc4BLgfJPs7krTKLhQAQyXc8BqTjfwl0=
Received: from EX-SZ050.tencent.com ( by EX-SZ019.tencent.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 28 Oct 2020 17:43:23 +0800
Received: from EX-SZ049.tencent.com ( by EX-SZ050.tencent.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 28 Oct 2020 17:43:23 +0800
Received: from EX-SZ049.tencent.com ([fe80::9d03:2012:f2ce:bc6]) by EX-SZ049.tencent.com ([fe80::9d03:2012:f2ce:bc6%8]) with mapi id 15.01.2106.002; Wed, 28 Oct 2020 17:43:23 +0800
From: "chunshxiong(熊春山)" <chunshxiong@tencent.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>, IETF ALTO <alto@ietf.org>
Thread-Topic: ALTO recharter to support cellular network use cases
Thread-Index: AdatDr+eC39DEYi4S2azSuat9z/73w==
Date: Wed, 28 Oct 2020 09:43:23 +0000
Message-ID: <603e57f9d7374de2802936650b411707@tencent.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_603e57f9d7374de2802936650b411707tencentcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/h_2hIuOTSmJ9Jpi39GKLJl39RaE>
Subject: [alto] ALTO recharter to support cellular network use cases
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2020 09:43:29 -0000

Hello All,

Now 3G/4G/5G becomes the infrastructure of a country. Business, education and entertainment are using the cellular network to provide seamless access.

To help the applications  (e.g. in the cloud) to provide good QoE to the end user, the application in the cloud needs to get the cellular network information, e.g. the available bitrate , the current latency in the cellular network, to adaptively change its bitrate or the video resolution.

Here, based on the above assumption, I identify the following new directions for ALTO re-charter:

1)      propose to include cellular network information to be provided to the ALTO Server,  then the ALTO server can further to provide the cellular network  information to the ALTO client.

2)      Define the cellular Network information with validity time .
Because the dynamic characteristics of the radio link, the information provided by the cellular network is almost always fresh and changing. So it is proposed that the freshness of the cellular network information provided is associated with a  validity time,  before the validity time expires, the cellular network information is fresh and can be trusted used, after validity time expires, the cellular network information is outdated  and cannot be trusted used.

One question is which network function sets the validity time for the cellular network information ? In my understanding, it is the 3G/4G/5G network nodes who provides such cellular network information will set the validity time.

3)      Define how the cellular network information is provided to the ALTO server

In  4G , SCEF-based  network information exposure architecture is defined.

In 5G, NEF-based network information exposure architecture is defined.

These SCEF and NEF based  network information exposure architecture can provide some information to the 3rd party via the Restful based API. The information provided by these two interface are normally events (e.g. UE’s connect available, or UE enters a defined area) which happens at current time. These real time events are very helpful some applications but it is still very limited for a lot of cloud-based applications.

Also 3GPP has defined CAPIF to help application to discovery and use the API provided by the 3GPP 3/4/5G.

So it is proposed that the ALTO Server  still  uses the open NEF-based interface to get cellular network information.

4)      Define how the ALTO Server get the fresh cellular network information

The NEF provided real-time events are valid on from the time of the  exposure to 3rd party because the event normally is a status, if the status is changed, a new event is provided. In such case, the event is valid always.

But the bitrate of radio link and the current latency in the 5G system are provided with detailed a value and not a status, in such case, a validity time is needed to define how long such value is usable as defined in 1).

In the 5G, the NET gets the network information from other network functions via the control plane. But these fresh cellular network information are changed frequently, this will introduce too much control plane signaling in the 5G. A reliable and efficient way for the NEF to get such fresh network information is needed in the 5G system.

3GPP 5G release-17 has defined a SID on EC enhancement to support cellular network information to the EC application server with low-latency. Now, 3GPP has agreed  (but still does not make final decision) that the  network information collection and exposure via combined IB and OB mechanism ( e.g. IB information signaling from radio network to the UPF via the user plane GTP-U header (this technology has been defined in release 16) and the UPF forwards such network information to the local NEF via a new control plane interface ( assumed to be defined in 3GPP release-17 Edge computing to support  low latency information exposure). It is assumed that there is an interface between local NEF and central NEF, in such case, the local NEF also can request (non latency sensitive) network information from the central NEF.

Based on such Release-17 EC low-latency information exposure technologies, the NEF can get fresh cellular network information from the user plane and from the radio station and provides these fresh cellular network information to the ALTO Server.

5)      Define which fresh cellular network information to be defined in the ALTO Server
This is very important question for us, at the start point, I think the bit rate and communication latency are needed, new  information can be defined.
And we also need to identify whether such cellular network information can be provided by the 5G network, If we need these network information, we can send LS to 3GPP to ask for exposure such information.

The above 5 bullets are the summary of my thinking on how to provide fresh cellular network information to the ALTO Server.

Thanks very much to  a lot people (e.g. Richard, Sabine, Li Gang, Kai, …) on the discussion during the weekly conference call.

Welcome your comments.

Chunshan Xiong


From: alto <alto-bounces@ietf.org> On Behalf Of Y. Richard Yang
Sent: Wednesday, September 2, 2020 11:56 PM
To: IETF ALTO <alto@ietf.org>
Subject: [alto] Short summary of recharter discussions on 3 items(Internet mail)

Dear ALTOers,

This is a brief update on the last two meetings. One focus was the rechartering items, and please see below for the discussion of three items. Please consider them definitely as *work in progress*, and the goal of posting them early is to better engage.

- Extension of ALTO to support cellular network use cases. The working group will extend ALTO information services to expose to mobile clients/applications about cellular network information, including general base station network information (e.g., spectrum allocation status) and network information on the links between the UE and the network (e.g., CSI). The extension should clearly address security issues including authentication, authorization, and confidentiality about UE and network information.

- Extension of ALTO to support east-west settings. The current ALTO framework receives network information from a single server, but the network devices (resources) traversed by a flow can consist of a sequence of network devices divided into segments, whose information can be managed by a sequence of ALTO servers. The working group will extend the ALTO framework to introduce capabilities to identify the full path (i.e., who provides the segment information), query the segments (e..g, identify segments of a path), and aggregate the information (e.g., standardize single aggregation in some settings, and more flexible aggregation such as non-dominant aggregation of high dimension using route algebra). The working group should consider realistic complexities such as some segments may not be identifiable, some segments may not have ALTO servers providing information, some segments may not provide the desired information, and dynamicity. The design should consider security issues such as access control policies, authorization (e.g., an ALTO server provides information for a network that the server has no authorization).

- Best practice documentation and extension of ALTO for operation automation. Operating an ALTO server can be complex, and the automation of the operations of the ALTO services can be highly valuable. The operations of an ALTO server includes decisions on the set of information resources (e.g., what metrics, how they are divided into multiple entries) exposed in the information resource directory (IRD), population (maybe proactive and reactive) of the content of the services (e.g., pull the backend, or trigger just-in-time measurements), and aggregation/processing of the collected information to give clients the proper response. The working group will investigate the best practices in ALTO operations automation, including interop/interfaces/protocols with routing systems and measurement tools.