2021 year

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

The review booking and schedule is per 30min slot and has the following structure:

Month/Day/Year Schedule Review

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 + the Link to the Rel "X" Documentation

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

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:

1. 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:

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

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 Experience PDF PDF PDF PDF 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)

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

08/20/2021 7:00 - 7:30 BP ICN, PTL Kuralamudhan Ramakrishnan Rel 5. Documentation Review. The link to ICN Rel. 5 Documentation is: ICN R5 Release

The PTL, Kural P. presented all the documents. There was indicated in the Documentation that it was an add on related to Local Broker that is the new BP part in the Rel. 5. It was recommended to add the ONAP EMCO API in YAML format to provide an opportunity for Automation and Intent-based Management. It was also recommended to provide reference to the input that the Community members had tried out the BP. There was made a remark to contemplate on the benefit from the the use of the term "edge" as it was explicitly indicated that the the BP objective is to be in close proximity to the source of Data through the deployment of Loal Broker and interact for defined set of Data to be sent to the Global Broker.

All the documents are well and thoroughly prepared. It is recommended to the TSC members to deem the ICN BP's Documentation for Rel. 5 as approved and accepted.

08/20/2021 7:30 - 8:00 BP ICN- Multi-Tenant Secure Cloud Native Platform, PTL Salvador Fuentes Rel 5. Documentation Review. The link to ICN Rel. 5 Documentation is: ICN-MTSCN R5 Release

The PTL, Salvador F. presented all the documents. There was recommended, as in the case of ICN Rel. 5, to benefit from API's in YAML format. There is an explicit comparison and presentation on the benefits with the Kata Containers, that the PTL presented, that provides a good overview on the BP's focus and provided advantages at its essence.

All the ICN MTSCN Rel. 5 documents are well and thoroughly prepared. It is recommended to the TSC members to deem the ICN MTSCN BP's Documentation for Rel. 5 as approved and accepted.

08/27/2021  07:00 - 07:30am PDT,  EALTEdge BP Rel 5 Documentation review, PTL Khemendra Kumar, the link to BP's Rel 5 Documentation is: Release 5 Documentation - Enterprise Applications on Lightweight 5G Telco Edge

The PTL Khemendra K. presented all the documents. There were suggested to refine the Data sheet summary with the parts remaning from the template as well as related to formating text, that is not readable (& in case that it doesn not work to follow the PCEI BP solution by downloading as *.pdf doc. Related to the BP's use of Edge Gallery as a way to connect to the CN, there was provided information per mail to the PTL about the way ETSI MEC/MEP is intergated with 5G through 3GPP 5G defined CCF (CAPIF Core Function) in the MEP Service Registry.

All the EALTEdge Rel. 5 documents are well and thoroughly prepared. It is recommended to the TSC members to deem the EALTEdge Rel. 5 BP's Documentation as approved and accepted.

08/27/2021 07:30 - 08:00am PDT, ELIOT IOT Gateway BP Rel 5 Documentation review, PTL Khemendra Kumar, the link to ELIOT BP Rel 5 documentation is: ELIOT R5 IoT Gateway Blueprint Documentation

The PTL Khemendra K. presented all the documents. As in the case of EALTEdge Rel. 5 Data sheet summary document, there were suggested to refine the Data sheet summary with the parts remaning from the template as well as related to formating text, that is not readable (& in case that it doesn not work to follow the PCEI BP solution by downloading as *.pdf doc.

In addition to OPC UA Architecture specifications that that BP ELIOT GW & CPE follows, it was recommended to follow (get uppdated) on the 3GPP specified CIoT for 5G specifications due to major enhancements embedded in the 5GS Architecure for IoT related to RG with support for MA through 3IWG & N3IWG and ATSSS and several/many more (e.g UPF in chain/series connection and RRC Inactive with enhanced security and move of LMF to RAN. The OPC UA was initially released in 2006 - 2008 and has a very broad Market deployment footprint since then. OPC UA specificifies a Platform independent Service-oriented Architecture, that integrates all the functionality of the individual OPC Classic Specifications into one (1) extensible Framework. OPC UA specifications are stipulated in International Standard IEC 62 541 (https://opcfoundation.org/news/opc-foundation-news/update-iec-62541-opc-ua-published/). The current version of the OPC UA specification is on 1.04 (22 November 2017). The new version of OPC UA now has added Publish/Subscribe in addition to the Client/Server communications infrastructure. The OPC UA Information Model is a so-called Full Mesh Network based on nodes. The OPC UA Architecure supports two (2) Protocols. This is visible to Application programmers only via changes to the URL. The binary protocol is opc.tcp://Server and http://Server is for Web Service. Otherwise OPC UA works completely transparent to the API. 

For furthr information, please see attached below the OPC UA Open IEC 62 541 (current) Standard specification from Jan 2021.

All the ELIOT IoT GW BP Rel. 5 documents are well and thoroughly prepared. It is recommended to the TSC members to deem the ELIOT GW BP Rel. 5 BP's Documentation as approved and accepted.

10 Dec 2021 Federated ML Application at Edge Maturity Documentation Review/Meeting notes

Day/Month/Year Schedule Review

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 + the Link to the Rel "X" Documentation