POC definition

1. SPONSOR– Min Zhang (CMCC), Cheng Huang (Huawei), Yaoguang Wang (Huawei).
2. NON BLOCKING- POC related defects shall not block the current release and not create any backward incompatibility.
3. COMPLIANCE- POC should be fully compliant with ONAP development guidelines, including development procedures.
   1. License/Vulnerabilities- POC development that includes entry points in the release version must comply with license scans and vulnerability fixes.
   2. Proprietary Components- PoC may include proprietary software or 3rd party software. It should be explicitly stated that the PoC is not contributing its software otherwise it is subject to CLAs.
   3. Security- PoC development shall be compliant to security guidelines and incorporate the latest security fixes so as not to create a security vulnerability.
   4. Performance- PoC should not impact the performance of the main code; this should be implied as it is kept in a separate Repo. The PoC development team should have an eye on ONAP performance if in the future it might be evolved to be incorporated into the ONAP platform.
   5. Back Doors- A POC should not introduce a back-door to the stable features so it must comply with security, code coverage, and license scans requirements.
   6. Resources- The PoC should perform an assessment to see that adequate resources are available such as PoC toolchains (Jenkins, Sonar, NexusID, LF resources, Test coverage resources etc).
   7. Approval for inclusion- The TSC or Use Case S/C shall approve the PoC to proceed as part of the current release.
4. INDEPENDENT OF MAIN RELEASE- PoC are not part of the (current) ONAP release product.
   1. Documentation- The PoC will have documentation in a wiki, linked by https://wiki.onap.org/display/DW/Support+for+Vertical+Industry .
   2. Independence- The PoC shall be kept independent of the official (current) release. The PoC shall not introduce any new requirements in the current release.
   3. Integration/Testing responsibility- The testing, integration and use of the PoC shall be in the purview of the PoC development team.
   4. ** PoC Release Notes**- Integration/Testing responsibility- The testing, integration and use of the PoC shall be in the purview of the PoC development team.
   5. ** PoC Release Notes - PoC release notes may be developed by the PoC team, they may include details of functionality available, known issues, and known limitations/incomplete features, and these info will be tracked by POC wiki (same as above) https://wiki.onap.org/display/DW/Support+for+Vertical+Industry .
5. CODE INDEPENDENCE- The PoC software shall be kept separate and independent of the main ONAP branch/repository.
   1. Common Code Usage- PoC software using common code, does not change the treatment of the common code with regards to completeness, S3P, documentation and other common code expectations.
   2. Separate Branch- PoC should be kept in separate repository branch.
   3. Evolutionary Platform Software- The main code for this POC on current ONAP components will be documented in POC wiki, https://wiki.onap.org/display/DW/Support+for+Vertical+Industry .
6. PROCESS- The PoC may follow a process during development.
   1. Milestones- The PoC team may follow some sort of development process. It is suggested that they use the Mx milestones/gates as the release progresses or some similar process.
   2. Final Approval - The final approval of a PoC shall ultimately be determined by the sponsor/leader of the PoC. We expect a "report" of how the PoC went to socialize at the end of Honolulu release and inform the TSC or Req S/C.
   3. PoC Overlap- It is recommended that the PoC team socialize their PoC so that other teams working on Use cases and PoCs are aware of potential cross-interactions that might occur and overlap in scope and functionality. Will use POC wiki (same as above): https://wiki.onap.org/display/DW/Support+for+Vertical+Industry .
7. SCOPE++- A PoC can be used to demonstrate functionality related to a project concept, a Use Case, functional or non-functional requirements, project specific extensions.
   1. Definition- Vertical Industry is one of the greatest potential 5G markets. Unlike traditional 2C scenarios, where the consumers of OSS are CSP internal operation staff or BSS system, in 5G era operators need to provide O&M capabilities for potentially multiple vertical industries consumers. This requirement propose to help operators to manage multiple vertical industry networks using ONAP. In R8, it will contain the following scenarios: a) One centralized operator ONAP only manages multiple vertical industry networks established by operators, and b) One centralized operator ONAP manages both vertical industry networks and traditional mobile networks (e.g. slicing).
   2. Project Review- the PoC team shall review the PoC with impacted Requirement sub-committees and projects PTLs (such as UUI, A&AI and SO).
8. POC INCORPORATION- The point of a PoC is to demonstrate something (hopefully) useful. PoCs teams that wish to incorporate the PoC code into the main repository should follow the standard procedures for introducing new functionality and use cases in subsequent ONAP releases
   1. Feature Proposals- There exists a standard procedure new functionality introduction leading up to M0 shall be followed by a PoC in subsequent releases by the PoC team if they wish to incorporate PoC Software into the main repository.
   2. Partial PoC Introduction- The original PoC scope may be altered from what is introduced in a future release. An ideal case might be that a PoC software might serve as seed code, but it does not have to. Lessons learned can guide what would get incorporated or proposed in the future release.
   3. Merge Responsibility- It will be the responsibility of the PoC Team to properly merge the PoC code into the main-line branch (S/W repo) if it becomes part of the future release. Merging should follow compliance principles (described in point #3 above).
   4. Proprietary Components - If the PoC used proprietary components or software, for formal including into ONAP it would need to be excluded in the final merge because ONAP is an open source initiative. Note: A PoC using proprietary components are "on" or "with" ONAP; a contributed PoC (without proprietary components) are said to be "in" ONAP.

======

Additional details are as following:

Description of Support for vertical industry scenarios:

• Goal- Unlike traditional 2C scenarios, where the consumers of OSS are CSP internal operation staff or BSS system, in 5G era operators need to provide O&M capabilities for potentially multiple vertical industries consumers. This requirement propose to help operators to manage multiple vertical industry networks using ONAP. In R8, it will start with managing the relations between providers and consumers (vertical industry) of network resources, considering the following use-cases: 
   - Scenario 1: Support 2B and 2C networks at the same time, in which 2B network and 2C industry network share part of network resources (slicing).

           - Scenario 2: Support multiple 2B networks, 2B networks refer to the enterprise  private networks established by operators for vertical industries.

Owners (one of these should be the Assignee - use @ notation):

CMCC: zm330

Huawei: HuangCheng , wangyaoguang

Link to HLD/LLD (if any): https://wiki.onap.org/display/DW/Support+for+Vertical+Industry 

Dependency Relationships with Other Projects:

As described in https://wiki.onap.org/display/DW/Honolulu+Impact+View+per+Component:

• Tenant management and isolation for Vertical Industry
  • Enhance A&AI Schema for vertical industry tenant, including basic tenant profile
  • Isolate resources (pnf/vnf/service instance etc.) from different vertical industry tenants, and shares potential resources between operator network and vertical industry network
• Provide centralized user interface in UUI for different vertical industry tenants, allowing them to access their own data, including resources and necessary configurations.
• Enhance NBI via ExternalAPI for OAM capability exposure
• Enhance service instantiation procedure with specified tenant and necessary vertical industry area
• Support for vertical industry scenario 2 in R8
  • Operator instantiates different services for two different vertical tenants, further creates initial NRM configurations for them.
  • Tenants are expected to access their own resources from centralized UUI.

Project Impact (Test Only (TO), Code (C)): SO (C), A&AI (C), ExternalAPI (C), UUI(C)

Integration Leads (use @ notation):

Company Engagement: China Mobile, Huawei

================================================

PoC Report has been updated in wiki page : https://wiki.onap.org/display/DW/Support+for+Vertical+Industry