1/8/2021 schedule
1/ 7:00 am – 7:30 am PDT Public Cloud Edge Interface (PCEI) Blueprint Family Oleg Berzin
Meeting notes:
The following remarks shall be treated as "recommendations" pursuing enhancements/improvements and in no way treated as "mandatory" to follow and/or implement.
As the Zoom session could not be started on time and it took about 20 min to re-schedule the Zoom meeting, it was decided per mail to convey the remarks of Documentation review per mail. The following is recommended:
- On the Architecture document:
- Related to UPF shunting at the MNO (CSPs) to check the already implemented in 3GPP System Architecture related Local Traffic Routing and Service Steering the functionalities related to multiple N6 UDP sessions and selection and re-selection of UPFs by the AF.
- If possible, to elaborate why it is selected to refer to UPF deployed in the DC and not the other 3 alternative UPF deployments
- With regard to MNO/CSP's Network (5G NSA/LTE and/or 5G SBA Network Architecture Configuration) selected functions invoked in the MEC host through partial and/or full intergration of MNO/CSPs Network CCF with ETSI MEC Host Service Registry
- On the management part, to elaborate on the MEC Host support for Virtualized Infrastructure (and defined on MEC Host support for 3rd Party to provide its own Application and enable its Mangement from its own Management environment without and integration with the MEC Orchestrator.
- If the aim/purpose of PCEI is to provide an "Enabler Layer" to briefly elaborate on the MNOs provided Capabilities through SEES/FMSS (in SCEF/NEF) to 3rd party ICPs/ISPs.
- In order to provide a better understanding to the reader on the maturity/evolvement level of the PCEI Solution, to elaborate whether PCEI current Availability Configuration and or the Rel 4 proposed implementation is a "Demo", "Concept", "Commercial" deployment version and/or there is/are references.
- The above remarks are also made with regard to the Test Document part related to APIs (test) indicated as "work in progress".
- Related to Latency in the defined 3GPP UCs ( as eMBB, URLLC, mIoT, V2X as with inidcated standard values for Slicing) is defined and published. It might be useful to add it to provide credibility that PCEI is aware of the required Latency requirements and therein able to contribute to be achieved. The IIoT (industry 4.0) within URLLC (for MCC/MCS - Mission Critical Communication/Mission Critical Services) in terms of Motion Control Discrete Automtion (for Robotics and Packaging) as well as Process Automation - Motion Control (for fluids, Gases, Electricity) is also defined/specified (even the manufacturing areas that shall be covered in terms of 30mx30mx10m and 100mx100mx30m. There is also support for 3GPP and non 3GPP access (3IWG and N3IWG) with ATSSS in order to comply with the QoS requirements for Service "Availability" and Service "Reliability" in MNOs Network.
2. On the attached Data sheet, to check on page 2, whether it should be "PCEI in Akraino Rel 4" (as the indicated term is probably a typing mistake, if not to elaborate what the indicated term means)?
3. In the Test Document, there is very limited information about performed tests (except for the Bluval) and even in the part on the tests related to APIs there is not provided any information except the inidication that this is a work in progress. It is recommended to provide a reference to either a Time Plan and/or Road Map indicating when the Testing is scheduled for (e.g. Q1 or Q2, 2021).
On your comment and inquiry on my remark about "Maturity of the Solution", I am sorry if I had been ambigous and/or misleading with my remark.
I meant about the status of Deployment Availability in terms of
1. "Concept" or
2. "Demo" or
3. "Commercial Deployment".
I suggest that with regard to the variety of preferences in terms of having a "Concept" that can be further built-upon (please read "Customized") or a "Demo", that provides a working SW/Functionality (that is "stable") or a Commercial Deployment that can be taken as it is (with integration to BSS/peripheral internal Platforms) to be deployed fast in order to be shown as a reference on the Market.
Such denomination (anyone of the listed 3 above) on the status of the "Solution Deployment Availability", depending on the party the Solution is discussed with, can provide opportunities.
Again, I would like to convey from my side that it is a remark-suggestion, rather than a requrement.
On the "Demo" elaboration, I suggest to people to elaborate about it in the "Architecture" documents as it is read by the Technical people, that provide recommendations to the Commercial people.
On the UPF deployment, please note that UPF might be deployed at the DC, Aggregation Point, BTS and/or 5G CN (Core Network) site.
There are certain conditions for that.
In your PCEI case, you chose DC. If you get some questions on that from people who are aware and work with that (that aso know the conditions, differences, requirements), depending on your answer, recipients of your answer, may measure your insights into various aspects that this issue concerns/relates to.
Just FYI.
The digram below may provide you with an insight about the use of the terms CSPs and Telco (difference) with regard to the presented by 3GPP High-level model of roles.
The below chart assigns a particular meaning in the Case of (5G NSA/SBA) Slicing (SST/SSI) deployment (NSaaS).
P.S. According to GSA, there are till now about 330 Applications to deploy 5G Private Network (and the allocated frequency is still witihn the Band 42). D.S.
1/15/2021 schedule
1/ 7:00 am – 7:30am PDT
2/7:30 am – 8:00 am -PDT
Meeting Notes: The scheduled for today two (2) BPs Documentation reviews, namely IEC Type 5 and IEC Type 3, had been re-scheduled to a further date as the respective PTLs had kindly inidcated per mail that they would like to have some additional time to resolve some issues. The PTLs had been notifed in the reply that they can take their time, but hopefully, perform the Documentation review before Feb. 10th, 2021.
1/22/2021 schedule
1/ 07:00 am - 07:30 am PDT - 5G MEC/Slice System to Support Cloud Gaming, HD Video and Live Broadcasting Blueprint Zigeng Fu Feng Yang
2/ 07:30 am - 08:00 am PDT
Meeting notes:
- BPs 5G MEC/Slice System to Support Cloud Gaming, HD Video and Live Broadcasting
All set of Documents for Rel 4 were reviewed. During review, there were shown reference to acceptance/approval from other Sub-committees as Upstream, Security, Bluval and APIs. There were elaborations about how the BP supports/implements (through OpenNESS) the 3GPP 5G and ETSI MEC Architecture specifications. The convyed remarks related to some indications and elaborations as e.g. explicit reference to support & implementing Open API 3.0, ETSI MEC MP1 & MP2 defined specifications, and related to 3GPP 5G Slicing to show some future planing on Slicing and, if possible, to show reference to which of the 3GPP 5G (4 -four) SST standardized UC value(s), the BP intends to support/implement in the future.
It is recommended to Akraino TSC to deem the BPs 5G MEC/Slice System to support Cloud Gaming documentation for Akraino Rel 4 as approved.
The attached below paper is just for information in case that it may contribute to the BPs with some information for further enhancement.
1/29/2021 schedule
1/ 07:00 am - 07:30 am PDT IEC type 5 SmartNIC Yihui Wang
Meeting notes:
The documentation is well prepared and detailed. The Architecture and HW and SW is well specified. The installation and verification are also well specified. There is elaboration on the differences between Rel 3 and Rel 4. In the Installation documentation there is also provided verification instructions. The performed tests are made on load throughput. The latency is left outside as it is dependant on UC Latency requirements. On the Test document, there shall be made some minor refinements to avoid misunderstandings from the text as it is presented the "tested and deployed Architecture" rather than ( as indicated in the text) "The Test Architecture".
Akraino TSC is recommended to accept and thereby, approve the BPs presented set of Documentation for Akraino Rel 4.
2/ 07:30 am - 08:00 am PDT
2/05/2021 schedule
1/ 07:00 am - 07:30 am PDT IEC Type 3: Android cloud native applications on Arm servers in edge for Integrated Edge Cloud (IEC) Blueprint Family hanyu ding
2/ 07:30 am - 08:00 am PDT
2/24/2021 Presentations on Amazon AI ML Platform (SageMaker) Algorithms, Models
The following presentations are listed below:
1. Amazon Innovate Opening Key notes
2. From PoC to Strategies for achieving ML at Scale
3. How do you innovate to drive Business outcomes
4. Use of AI ML to enhance the Customer Experience
5. Closing Keynotes
2/25/2021 Review/Meeting notes
Documentation review of Blueprint "The AI Edge: Intelligent Vehicle-Infrastructure Cooperation System (I-VICS) is done over e-mail. Akraino Rel 4 Blueprint Documentation set at link: The AI Edge: Intelligent Vehicle-Infrastructure Cooperation System(I-VICS).
All the required Blueprint's docs for Akraino Rel 4 are available and well prepared. There is provided reference to the utilized Blueprint's Open Source Platform SW (with link to the tool needed for Installation of SW as part of the Platform SW,namely, ROS2 - Robot Operating System 2) and support for 2 UCs namely, "Valet parking" and "SOTIF - Safety of the Intended Functionality". There is provided reference to HW list for a demo with Lexus RX 450h case. In the Installation Guide" document, the needed HW is specified. The Release document addresses mainly UC SOTIF. The Blueprint's APIs are based on FATE (Federated AI Technology Enabler), which is an Open-Source Project initiated by Webank’s AI Department to provide a Secure Computing Framework to support the Federated AI ecosystem.It seems that the current Blueprint HW and SW configueration is an outcome of Test/Trial/PoC (with Lexus RX 450h). The Blueprint had also added a document "Landing Applications", that provides a list of other Akraino Blueprints that can potentially run (as Application(s)) on the Blueprint (as a Platform). There is also a room for evolvement for the Blueprint to utilize the V2X UC specification(s) in ETSI MEC and 3GPP 5G for V2X SST.
It is recommended to Akraino TSC to accept the "AI Edge I-VICS" Blueprint documentation and deem them as "approved/eligible" for Akraino Rel. 4.
05 May 2021 Video Security Monitoring Maturity Documentation Review/Meeting notes, PTL Liya Yu.
Maturity Documentation review of Blueprint " Video Security Monitoring" is done over e-mail. All the required Blueprint's docs for Akraino Rel 4 are available and well prepared. The following remarks shall be considered as advisory and as a recommendation rather as mandaroty and subject to be used a ground for changein the BP's Documentation text:
- In the API document. There is not an explicit reference to Open API Specification (OAS https://spec.openapis.org/oas/v3.1.0) and if the API structure follows it. In the Architecure Document, there is justa title "Open API. In case that BP follows OAS, it is recommended to explicitly state that in the BP's API Document. The API document is thorough. It is follows any Architecture Standard API structure, it is recommended to also explicitly refere to it.
- In the Architecure Document, there is used the abbrerviation MEC. As "MEC" abbreviation is used by the ETSI MEC and respective Standard Solution Architecture, in case that the BluePrint follows the ETSI MEC Architecture Standard Specification, then it is recommended to use its complete denomination (ETSI MEC). If not, it is recommended not to use the abbreviation MEC, but its full name. The presented Architecture figures present the call flow based on Kubernetes (K3S Light and K8S). There is lack of indication of used interfaces and protocols. Therein, the respective presentation is just a "Diagram" rather than an "Architecure". It is recommended to indicate respective "Protocls" and "Interfaces" to indicate connections and/or dependencies. With regard to AI, there is harldy any information. It is recomended to add information about the utlized ML Algorithms, Type of Models and Models Training Approach, used Data Granularity and Charactristics for Training models, How the "test case data" is treated with regard to CNN RLU (to start with).
- Installation Document is thorough and detailed. It is recommended to update with a Section related to ML (AI) Data handling/treatment and New Data gathering, Storage, Update and use for ML Model build-up and Algorithm(s) training.
- Related to "Release" Document, it is recommended to provide the BP's Roadmap with respective Releases (Features, Functionalities, Dependancies, Security and Time Table) and with respect to that refer to what is new related to Akraino Rel. 4. It is impossible to understand how the Solution/Product/Platform is planned to be evolved.
- On the Security Test Document, it is preferable for the Akraino TSC to receive the Akraino Security Sub-committee assessment analysis.
Attached below 5G General Performance Requirements for Video Production Applications & Airborne Base Stations for NPN (Non Public Network)
Attack types related to Securing AI and related to it Mitigation Strategies are classified into two (2) main Categories, i.e. Training Attacks which occur during Development Stage and Inference Attacks which occur during Deployment Stage. Training Attacks include Poisoning Attacks and Backdoor Attacks while Inference Attacks include Evasion Attacks and Reverse Engineering Attacks. Model Stealing Attacks and Data Extraction Attacks are two (2) subtypes of Reverse Engineering Attacks. Some State-of-the-Art Adversarial ML papers & reports provide more details of existing attacks against Deep Learning (DL) Systems.
Assessment summary and Recommendation to Akraino TSC: Overall assessment is that the BP's Documentation for Akraino Rel 4 is well prepared and thorough for each Part. There is a good overview on the overall Solution and related UCs. Therein, it is recommended to the Akraino TSC to deem the BP's Rel. 4 Documentation as accepted.
Day/Month/Year Schedule Review
Time slot 1) 07:00 - 07:30am PDT + BPs Title + PTL Name
Time slot 2) 07:30 - 08:00am PDT + BPs Title + PTL Name