[alto] Meeting minutes for Dec 1, 2020

kaigao@scu.edu.cn Wed, 02 December 2020 14:32 UTC

Return-Path: <kaigao@scu.edu.cn>
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 DC2BD3A1298 for <alto@ietfa.amsl.com>; Wed, 2 Dec 2020 06:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 015c2iscbUCB for <alto@ietfa.amsl.com>; Wed, 2 Dec 2020 06:32:30 -0800 (PST)
Received: from zg8tmty1ljiyny4xntqumjca.icoremail.net (zg8tmty1ljiyny4xntqumjca.icoremail.net [165.227.154.27]) by ietfa.amsl.com (Postfix) with SMTP id 4B9F03A1451 for <alto@ietf.org>; Wed, 2 Dec 2020 06:32:29 -0800 (PST)
Received: by ajax-webmail-app1 (Coremail) ; Wed, 2 Dec 2020 22:32:26 +0800 (GMT+08:00)
X-Originating-IP: [125.70.168.242]
Date: Wed, 2 Dec 2020 22:32:26 +0800 (GMT+08:00)
X-CM-HeaderCharset: UTF-8
From: kaigao@scu.edu.cn
To: alto@ietf.org, "alto-weekly-meeting@googlegroups.com" <alto-weekly-meeting@googlegroups.com>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version XT5.0.13 build 20200820(b2b8cba1) Copyright (c) 2002-2020 www.mailtech.cn mail
Content-Type: multipart/alternative; boundary="----=_Part_432107_961840081.1606919546146"
MIME-Version: 1.0
Message-ID: <538429fc.2669.17623de6523.Coremail.kaigao@scu.edu.cn>
X-Coremail-Locale: en_US
X-CM-TRANSID: 4wAACgDX36d6pcdfq1QSAA--.3128W
X-CM-SenderInfo: 5ndlwt3r6vu3oohg3hdfq/1tbiAQIQB138kkdKrwAys3
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/44hhcjEmsU5TmvQVXubXr7QCbtY>
Subject: [alto] Meeting minutes for Dec 1, 2020
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, 02 Dec 2020 14:32:37 -0000

Dear all,




Please find below the meeting minutes for the meeting on Dec 1, 2020.




In the beginning of the meeting, Sabine/Richard/Kai gave some updates on the progress of existing WG documents. Richard suggested WG members putting efforts on implementation and deployment of existing and future extensions.

Gang gave a wonderful talk on cellular extension. His talk listed some typical applications that can take advantage of cellular information, and also summarized what information is useful at both the UE level and cell/slice level, including measured/predicted radio link status, measured loading/traffic information, and predicted PRB usage. He also demonstrated how such information can be obtained from two cellular frameworks: 3GPP and O-RAN. For the 3GPP case, cellular information can be obtained from NEF as proposed in earlier documents, while for the O-RAN case, such information is first collected by a Near-RT RIC (RAN Intelligent Controller) through the E2 interface and then fed to an ALTO server.

Some discussions for the talk:

Richard: What would be the inteface between the ALTO server and the Near-RT RIC
Gang: ALTO server be implemented as an xAPP on top of Near-RT RIC
Richard: How does the E2 interface provide the information? Pub-sub?
Gang: It depends on what xAPP is deployed.
Richard: The RAN does not directly provide information to UEs. The near-rt RIC plays two roles: information aggregation/filtering and scaling
Richard: Does the ALTO server provide information that is directly translated from metrics already defined in E2 interface?
Gang: Yes. ALTO server can be a good complement to the near-rt RIC
Richard: Should we invite Young Lee to present on openAPI?
Qin: OpenAPI can use YANG to model metrics but NEF also defines data models that are not tight to YANG model. For O-RAN, it is related to ONF dealing with whitebox devices. E2 is related to the telemetry inteface. GMI to support pub/sub mechanism. SONiC also supports GMI/gRPC interfaces and also supports DB architecture. They translate from the telemetry interface and the db inteface.
Chunshan: In 3gpp, openAPI is also used widely. Very few information can be exposed according to 3gpp guidelines. Each UE has different channel status because of different locations. How to provide this general information for all the UE? It seems impossible. Only per-UE information is useful for the application.

Open issues:

- Jensen will talk about the implementation of Path Vector and/or CDNI
- Richard will invite Young Lee to present in the next meeting
- Reserve 15-20 min to continue the discussion on cellular information
- Richard will give a talk on integration of ALTO and GAN-G

Please let me know if anything is missing or misinterpreted.




Best,

Kai