Page Comparison

The most recent review (the latest one) can be found at the bottom of this page.

...

Time slot 1) 07:00 - 07:30am PDT + BPs Title + PTL Name + the Link to the Rel "X" Documentation

Time slot 2) 07:30 - 08:00am PDT + BPs Title + PTL Name

1/8/2021 schedule

1/ 7:00 am – 7:30 am PDT Public Cloud Edge Interface (PCEI) Blueprint Family Oleg Berzin

2/7:30am – 8:00 am -

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.

...

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).

Image Removed

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.

Image Removed PDF

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 ExperienceImage Removed PDFImage Removed PDFImage Removed PDFImage Removed PDFImage Removed PDF

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)

Image Removed Image Removed

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.

Image Removed Image Removed

Assessment summary and Recommendation to Akraino TSC: Overall assessment is that the BP's Documentation for Akraino Maturity Review 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 Maturity Review Documentation as accepted.

08/08/2021 BP PCEI, PTL Oleg Berzin, Rel. 5 Documentation Review. The link to PCEI Rel 5 Documentation is: PCEI Release 5 Documentation

Meeting notes:

The following remarks shall be treated by the TSC members as "recommendations" pursuing enhancements/improvements and in no way treated as "mandatory" to follow and/or implement/apply in the assessment of the BP's submitted documentation quality of the content. .

The Documentation review was performed per mail. All Documents are well structured and written. The submitted one page Data sheet PCEI R5 provides a good overview on the Key Features and Implementations in Akraino Rel 5 as related to Terraform Executor Controller Design Studio (CDS) enabling automatic and North Bound Interface (NBI) API driven pull from Gihub and execution of Terraform plan. Terraform is an Open Source “Infrastructure as Code” tool, created by HashiCorp and using "declarative" coding tool enabling developers to use a high-level configuration language called HCL (HashiCorp Configuration Language) to describe the desired “end-state” Cloud or On-premises Infrastructure for running an Application. It then generates a plan for reaching that end-state and executes the plan to provision the infrastructure. The PCEI BP also utilize CDS Helm Chart Processor and CDS Kubernetes Cluster Registration Processor enabling NBI API driven pull from Github of Composite Application Helm charts for onboarding Services and Apps to ONAP EMCO ( Edge Multi Cluster Orchestrator) as well as automatic target cluster registration (with ONAP EMCO) for Kubernetes Application deployment on registered target Cluster Orchestrator.

It is recommended to the TSC members to deem the submitted PCEI Rel 5 Documentation as approved and accepted (for Rel. 5).+ the Link to the Rel "X" Documentation

Summary Table to Akraino TSC for BP (Integration Projects) Review status from August 2021

Nr	Akraino BP Title	BP's PTL Name	Review Date	Release	Link to submitted BP's Documentation Templates	Documentation Sub-committee Recommendation to TSC (Approve/Not Approve)	Comments/Remarks
1	Public Cloud Edge Interface (PCEI)	Oleg Berzin	Aug. 8th, 2021	Rel. 5	https://lf-akraino.atlassian.net/wiki/display/AK/PCEI+Release+5+Documentation	Approve	Submitted Documents for Rel. 5 are well structured & written.
2	SmartNIC for IEC BP	Leo (acting as PTL due to the fact that the PTL Yihui stepped down)	Aug.13, 2021	Rel. 5	please see "Comments/Remarks" column	Approve	per mail notified that there is not any change in the documentation from Rel. 4 to Rel. 5.
3	5G MEC/Slice System BP	Eagan Fu	Aug. 16, 2021	Rel. 5	please see "Comments/Remarks" column	Approve	per mail notified that there is not any change in the documentation from Rel. 4 to Rel. 5. Currently awaiting update/input on requirements from the Customer.
4	IEC Type 2	Vinothini Raju	Aug. 17, 2021	Rel. 5	IEC Type 2 Release 5 Documentation	Approve	Submitted Documents for Rel. 5 are well structured & written. As both, the IEC Type 2 BP and PCEI BP, use Terraform, it might be worthwhile to explore the possibility for co-operation between the 2 BPs.
5	ICN (Integrated Cloud Native)	Kuralamudhan Ramakrishnan,	Aug. 20, 2021	Rel. 5	ICN Rel 5 Documentation	Approve	Submitted Documents for Rel. 5 are well structured & written.
6	ICN- MTSCN (Multi-Tenant Secure Cloud Native Platform)	Salvador Fuentes	Aug. 20, 2021	Rel. 5	ICN-MTSCN R5 Release Documentation	Approve	Submitted Documents for Rel. 5 are well structured & written.
7	EALTEdge (Enterprise Application on Lightweight 5G Telco Edge) BP	Khemendra Kumar	Aug. 27, 2021	Rel. 5	Enterprise Applications on Lightweight 5G Telco Edge Rel 5 Documentation	Approve	Submitted Documents for Rel. 5 are well structured & written.
8	Edge Lightweight and IoT Gateway (ELIOT GW) Blueprint	Khemendra Kumar	Aug., 27, 2021	Rel. 5	ELIOT IoT Gateway Blueprint Rel. 5 Documentation	Approve	Submitted Documents for Rel. 5 are well structured & written.

1/8/2021 schedule

1/ 7:00 am – 7:30 am PDT Public Cloud Edge Interface (PCEI) Blueprint Family Oleg Berzin

2/7:30am – 8:00 am -

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.