[alto] ALTO recharter: proposed item - Extends the ALTO Service to provide cellular network Information

"chunshxiong(熊春山)" <chunshxiong@tencent.com> Wed, 11 November 2020 09:13 UTC

Return-Path: <chunshxiong@tencent.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D653A0F0F for <alto@ietfa.amsl.com>; Wed, 11 Nov 2020 01:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFJEDdJyCqxu for <alto@ietfa.amsl.com>; Wed, 11 Nov 2020 01:13:07 -0800 (PST)
Received: from mail1.tencent.com (mail1.tencent.com [203.205.248.43]) (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 C59FE3A0DAD for <alto@ietf.org>; Wed, 11 Nov 2020 01:13:06 -0800 (PST)
Received: from EX-SZ023.tencent.com (unknown [10.28.6.89]) by mail1.tencent.com (Postfix) with ESMTP id 54ACD5A227 for <alto@ietf.org>; Wed, 11 Nov 2020 17:13:04 +0800 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tencent.com; s=s202002; t=1605085984; bh=grrjz8r2cmi3R9ztd9NTSKb+NnyULTqHhkBnO8jtKKk=; h=From:To:CC:Subject:Date; b=U0vQIokp/oMuiM2JCox3k0rpyi1RZO3rUsaaZ8vE8hOInTwTA/sPM+P7rMnPpYA4e IOCDfe0d43KB5DWZfpQ2HHFcR0/qyQl47ir89IzAADN7qc7rtZSVPVbsp2iMBZOQot EU03K5U0FueIPneMmxw8SVssT1Npz/c9GP8jIrHE=
Received: from EX-SZ052.tencent.com (10.28.6.108) by EX-SZ023.tencent.com (10.28.6.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 11 Nov 2020 17:13:04 +0800
Received: from EX-SZ049.tencent.com (10.28.6.102) by EX-SZ052.tencent.com (10.28.6.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 11 Nov 2020 17:13:03 +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, 11 Nov 2020 17:13:03 +0800
From: =?utf-8?B?Y2h1bnNoeGlvbmco54aK5pil5bGxKQ==?= <chunshxiong@tencent.com>
To: alto <alto@ietf.org>
Thread-Topic: [alto] ALTO recharter: proposed item - Extends the ALTO Service to provide cellular network Information
Thread-Index: Ada4CoM3xla+0V5tRfSR3rij2LhMUw==
Date: Wed, 11 Nov 2020 09:13:03 +0000
Message-ID: <6ff173af2a604dbbb01f8f069d129864@tencent.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.99.16.11]
Content-Type: multipart/alternative; boundary="_000_6ff173af2a604dbbb01f8f069d129864tencentcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/9CAIL0hEW4cy90iVeOJn_gYO84o>
Subject: [alto] ALTO recharter: proposed item - Extends the ALTO Service to provide cellular network Information
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, 11 Nov 2020 09:13:12 -0000

Hello all,

I and Li Gang(China Mobile)  reconstruct the WG item proposal for “Extends the ALTO Service to provide cellular network Information” based on the previous email and discussion during the weekly meetings.
Welcome your comments.
BRs,
Chunshan Xiong

**** Context:Extends the ALTO Service to provide cellular network Information
-     Currently ALTO Information Services does not support cellular net.


1. Problem description
+++ Issue 1: Whether it is feasible to obtain the cellular information?
+++ Issue 2: How does ALTO server obtain cellular information from 5G NEF?
+++ Issue 3:What cellular information is from ALTO server to ALTO client?
+++ Issue 4:What cellular information is exposed from 5G network to ALTO server?


2.    Potential solutions and considerations
+++ Solution for Issue 1
       - It is feasible to obtain the cellular information from NEF
       - Reuse the CAPIF defined in 3GPP
       - Leverage the release-17 Edge computing Enhance to provide cellular network information wih low-latency.

+++ Solution for Issue 2:
       - For OB solution, it is proposed that the ALTO server reuses current standard to obtain the cellular information via NEF northbound interface.
       - For IB, it is proposed to investigate the potential solution and leverage the existing standardization outputs.

+++ Solution for Issue 3:
       - Measurement information: bandwidth, latency, jitter
       - Predicted information: available bandwidth for next a few seconds

+++ Solution for Issue 4:
       - Radio channel status: e.g. SINR, RSRP/RSRQ, CQI, MCS
       - L2 user plane measurements: e.g. thoughtputthroughput, latency
       - In addition, different levels can also be considered, i.e. flow, UE, slice, serving cell and neighboring cell. For those information defined but not exposed from 5G network, we can send LS to 3GPP to ask for such information exposure.

3.   Remaining issues to be addressed
+++ Security/sensitivity of info
       -     It is not sensitive for OB solution and
       -     for future study for IB.
       -     For OB+IB solution defined in 3GPP EC in Rel-17, it is treated as OB solution for IETF ALTO.

+++  Given 3GPP/layer 2 SDO are defining this interface/service, why do we need ALTO to do it as well? Why Internet standard, and 3GPP standards are not enough?
       - 3GPP NEF provides low layer information, which is hard for application usage directly.
       - ALTO server can aggregate such original cellular information, and have capability and possibility to process that information and provide it to applications (ALTO client) with more easy to use via a single interface.

+++ Is the info really useful?
       - The results from IETF MOWIE draft paper can prove the benefit of utilizing such cellular    information.  -

+++ Are the providers willing to provide the info?
       - It depends on business model. On one hand, operators can increase revenue by charging from OTT vendors. On the other hand, it is helpful to improve user QoE and increase user loyalty.

+++ Is the info from a single device or a set of devices, where the devices involved can span multiple autonomous domains, multiple wireless links may get involved? What does mean for this context?
       - For local breakout scenario, the NEF and radio network are within the same operator, no problem to get information.
       - For home domain routed scenario, the NEF and radio network belongs to different operators, but since the home routed traffic, there is a roaming agreement for multiple domains and NEF can provide some celluar network information.


4.    Who will work on it?
       - China Mobile, Tencent and Welcome more.

5. Rough Planning and outputs
       -     Mar 2021       Problem Description on support cellular network
       -     Nov 2021       Extend ALTO Information Service with Cellular network information and its information freshness
       -     2022              Best Practice to provide deployment guideline for network information exposure


From: yanniszhang(张云飞) <yanniszhang@tencent.com>
Sent: Saturday, October 31, 2020 1:49 PM
To: ligangyf <ligangyf@chinamobile.com>om>; chunshxiong(熊春山) <chunshxiong@tencent.com>om>; yry <yry@cs.yale.edu>du>; alto <alto@ietf.org>
Subject: Re: RE: [alto] ALTO recharter to support cellular network use cases(Internet mail)

Hi Ligang,
   Please see inline for the reply.

BR
Yunfei

________________________________
yanniszhang(张云飞)

From: Li Gang<mailto:ligangyf@chinamobile.com>
Date: 2020-10-30 16:58
To: yanniszhang(张云飞)<mailto:yanniszhang@tencent.com>; chunshxiong(熊春山)<mailto:chunshxiong@tencent.com>; 'yry'<mailto:yry@cs.yale.edu>; 'alto'<mailto:alto@ietf.org>
Subject: RE: Re: [alto] ALTO recharter to support cellular network use cases(Internet mail)
Hi, Yunfei, please see inline for some of my reply.

From: yanniszhang(张云飞) [mailto:yanniszhang@tencent.com]
Sent: Thursday, October 29, 2020 9:50 PM
To: ligangyf; chunshxiong(熊春山); yry; alto
Subject: Re: Re: [alto] ALTO recharter to support cellular network use cases(Internet mail)

Hi Ligang,
   Please see inline for the reply. Thanks.

BR
Yunfei

________________________________
yanniszhang(张云飞)

From: Li Gang<mailto:ligangyf@chinamobile.com>
Date: 2020-10-29 18:02
To: chunshxiong(熊春山)<mailto:chunshxiong@tencent.com>; 'Y. Richard Yang'<mailto:yry@cs.yale.edu>; 'IETF ALTO'<mailto:alto@ietf.org>
Subject: Re: [alto] ALTO recharter to support cellular network use cases(Internet mail)
Dear ALTOers,

Thank Chuanshan for your triggering discussion on cellular network information exposure via ALTO. Here are some of my thoughts.

1)      It is beneficial to investigate cellular information exposure to improve especially cloud interactive applications. I think the following categories of cellular information can be considered, for example,  radio channel status, L2 user plane measurements. In addition, different levels can also be considered, i.e. UE, slice, serving cell and neighboring cell. There are a number of specifications in 3GPP to define the specific meaning of each parameter and we don’t have to spend too much effort to define each of them.

[Yunfei] Agree. We don't need to define them while we need to summarize these parameters (group) that matters for ALTO.

2)      NEF, indeed, is a good interface for ALTO server to obtain cellular information. And  for ALTO WG we don’t have to dive too much in how those information is conveyed within 3GPP network. In addition, the NEF deployment is quite flexible and can collocate with UPF and MEC, which enable low latency transmission.

[Yunfei] Not very sure if current NEF can support very quick interaction bw network and application, even it's located in MEC. It doesn't work when the frequency of the parameters NEF exposes is quite low  even if its transmission latency is low. Can you elabrate the degree BCP NEF can support? We may need to extend the requirement of NEF in 3GPP if necessary.

[LiGang] I agree that we need to evaluate if the current flow&depolyment can satisfy the performance requirement of frequent cellular info exposure. Actually there is no direct interface between UPF and NEF, and the flow has to go through RAN->UPF->SMF->NEF, which is quite lengthy. Some extension may be needed in 3GPP. Or even more drastically, in-band related solution might be considered.

[Yunfei] Excatly I agree your comments on NEF in 3GPP.

Best Regards,

Li Gang
China Mobile

From: alto [mailto:alto-bounces@ietf.org] On Behalf Of chunshxiong(熊春山)
Sent: Wednesday, October 28, 2020 5:43 PM
To: Y. Richard Yang; IETF ALTO
Subject: [alto] ALTO recharter to support cellular network use cases

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.

BRs,
Chunshan Xiong

Tencent

From: alto <alto-bounces@ietf.org<mailto:alto-bounces@ietf.org>> On Behalf Of Y. Richard Yang
Sent: Wednesday, September 2, 2020 11:56 PM
To: IETF ALTO <alto@ietf.org<mailto: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.