diff --git a/404.html b/404.html
index 5de666d6..88de2328 100644
--- a/404.html
+++ b/404.html
@@ -4,7 +4,7 @@
 -->
 
 ---
-layout: openness
+layout: smartedge-open
 ---
 <style>
     .error-page{
diff --git a/README.md b/README.md
index f683ee4f..f356acc5 100644
--- a/README.md
+++ b/README.md
@@ -3,103 +3,103 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019-2020 Intel Corporation
 ```
 
-# OpenNESS Quick Start
+# Smart Edge Open Quick Start
 
    ## <b>Network Edge</b>
-   ### <b>Step 1.</b> Get Hardware &#9658; <b>Step 2.</b> [Getting started](https://github.com/open-ness/specs/blob/master/doc/getting-started/openness-cluster-setup.md) &#9658; <b>Step 3.</b> [Applications Onboarding](https://github.com/open-ness/specs/blob/master/doc/applications-onboard/network-edge-applications-onboarding.md)
+   ### <b>Step 1.</b> Get Hardware &#9658; <b>Step 2.</b> [Getting started](https://github.com/smart-edge-open/specs/blob/master/doc/getting-started/smartedge-open-cluster-setup.md) &#9658; <b>Step 3.</b> [Applications Onboarding](https://github.com/smart-edge-open/specs/blob/master/doc/applications-onboard/network-edge-applications-onboarding.md)
 
 
-# OpenNESS solution documentation index
+# Smart Edge Open solution documentation index
 
-Below is the complete list of OpenNESS solution documentation
+Below is the complete list of Smart Edge Open solution documentation
 
 ## Architecture
 
-* [<b>architecture.md</b>: OpenNESS Architecture overview](https://github.com/open-ness/specs/blob/master/doc/architecture.md)
-* [<b>flavors.md</b>: OpenNESS Deployment Flavors](https://github.com/open-ness/specs/blob/master/doc/flavors.md)
+* [<b>architecture.md</b>: Smart Edge Open Architecture overview](https://github.com/smart-edge-open/specs/blob/master/doc/architecture.md)
+* [<b>flavors.md</b>: Smart Edge Open Deployment Flavors](https://github.com/smart-edge-open/specs/blob/master/doc/flavors.md)
 
 ## Getting Started - Setup
 
-* [<b>getting-started</b>: Folder containing how to get started with installing and trying OpenNESS Network Edge solutions](https://github.com/open-ness/specs/blob/master/doc/getting-started)
-   * [<b>openness-cluster-setup.md</b>: Getting started here for installing and trying OpenNESS Network Edge](https://github.com/open-ness/specs/blob/master/doc/getting-started/openness-cluster-setup.md)
-   * [<b>converged-edge-experience-kits.md</b>: Overview of the Converged Edge Experience Kits that are used to install the Network Edge solutions](https://github.com/open-ness/specs/blob/master/doc/getting-started/converged-edge-experience-kits.md)
-   * [<b>non-root-user.md</b>: Using the non-root user on the OpenNESS Platform](https://github.com/open-ness/specs/blob/master/doc/getting-started/non-root-user.md)
-   * [<b>harbor-registry.md</b>: Enabling Harbor Registry service in OpenNESS](https://github.com/open-ness/specs/blob/master/doc/getting-started/harbor-registry.md)
-   * [<b>kubernetes-dashboard.md</b>: Installing  Kubernetes Dashboard for OpenNESS Network Edge cluster](https://github.com/open-ness/specs/blob/master/doc/getting-started/kubernetes-dashboard.md)
+* [<b>getting-started</b>: Folder containing how to get started with installing and trying Smart Edge Open Network Edge solutions](https://github.com/smart-edge-open/specs/blob/master/doc/getting-started)
+   * [<b>smartedge-open-cluster-setup.md</b>: Getting started here for installing and trying Smart Edge Open Network Edge](https://github.com/smart-edge-open/specs/blob/master/doc/getting-started/smartedge-open-cluster-setup.md)
+   * [<b>converged-edge-experience-kits.md</b>: Overview of the Converged Edge Experience Kits that are used to install the Network Edge solutions](https://github.com/smart-edge-open/specs/blob/master/doc/getting-started/converged-edge-experience-kits.md)
+   * [<b>non-root-user.md</b>: Using the non-root user on the Smart Edge Open Platform](https://github.com/smart-edge-open/specs/blob/master/doc/getting-started/non-root-user.md)
+   * [<b>harbor-registry.md</b>: Enabling Harbor Registry service in Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/getting-started/harbor-registry.md)
+   * [<b>kubernetes-dashboard.md</b>: Installing  Kubernetes Dashboard for Smart Edge Open Network Edge cluster](https://github.com/smart-edge-open/specs/blob/master/doc/getting-started/kubernetes-dashboard.md)
 
 ## Application onboarding - Deployment
 
-* [<b>applications-onboard</b>: Now that you have installed OpenNESS platform start in this folder to onboard sample application on OpenNESS Network Edge](https://github.com/open-ness/specs/blob/master/doc/applications-onboard)
-   * [<b>network-edge-applications-onboarding.md</b>: Steps for onboarding sample application on OpenNESS Network Edge](https://github.com/open-ness/specs/blob/master/doc/applications-onboard/network-edge-applications-onboarding.md)
-   * [<b>openness-edgedns.md</b>: Using edge DNS service](https://github.com/open-ness/specs/blob/master/doc/applications-onboard/openness-edgedns.md)
-   * [<b>openness-interface-service.md</b>: Using network interfaces management service](https://github.com/open-ness/specs/blob/master/doc/applications-onboard/openness-interface-service.md)
-   * [<b>using-openness-cnca.md</b>: Steps for configuring 4G CUPS or 5G Application Function for Edge deployment for Network Edge](https://github.com/open-ness/specs/blob/master/doc/applications-onboard/using-openness-cnca.md)
-   * [<b>openness-eaa.md</b>: Edge Application Agent: Description of Edge Application APIs and Edge Application Authentication APIs](https://github.com/open-ness/specs/blob/master/doc/applications-onboard/openness-eaa.md)
-   * [<b>openness-certsigner.md</b>: Steps for issuing platform certificates](https://github.com/open-ness/specs/blob/master/doc/applications-onboard/openness-certsigner.md)
+* [<b>applications-onboard</b>: Now that you have installed Smart Edge Open platform start in this folder to onboard sample application on Smart Edge Open Network Edge](https://github.com/smart-edge-open/specs/blob/master/doc/applications-onboard)
+   * [<b>network-edge-applications-onboarding.md</b>: Steps for onboarding sample application on Smart Edge Open Network Edge](https://github.com/smart-edge-open/specs/blob/master/doc/applications-onboard/network-edge-applications-onboarding.md)
+   * [<b>smartedge-open-edgedns.md</b>: Using edge DNS service](https://github.com/smart-edge-open/specs/blob/master/doc/applications-onboard/smartedge-open-edgedns.md)
+   * [<b>smartedge-open-interface-service.md</b>: Using network interfaces management service](https://github.com/smart-edge-open/specs/blob/master/doc/applications-onboard/smartedge-open-interface-service.md)
+   * [<b>using-smartedge-open-cnca.md</b>: Steps for configuring 4G CUPS or 5G Application Function for Edge deployment for Network Edge](https://github.com/smart-edge-open/specs/blob/master/doc/applications-onboard/using-smartedge-open-cnca.md)
+   * [<b>smartedge-open-eaa.md</b>: Edge Application Agent: Description of Edge Application APIs and Edge Application Authentication APIs](https://github.com/smart-edge-open/specs/blob/master/doc/applications-onboard/smartedge-open-eaa.md)
+   * [<b>smartedge-open-certsigner.md</b>: Steps for issuing platform certificates](https://github.com/smart-edge-open/specs/blob/master/doc/applications-onboard/smartedge-open-certsigner.md)
 
 ## Core Network - 4G and 5G
 
-* [<b>core-network</b>: Folder containing details of 4G CUPS and 5G edge cloud deployment support](https://github.com/open-ness/specs/tree/master/doc/reference-architectures/core-network)
-   * [<b>openness_epc.md</b>: Whitepaper detailing the 4G CUPS support for Edge cloud deployment in OpenNESS for Network Edge](https://github.com/open-ness/specs/blob/master/doc/reference-architectures/core-network/openness_epc.md)
-   * [<b>openness_ngc.md</b>: Whitepaper detailing the 5G Edge Cloud deployment support in OpenNESS for Network Edge](https://github.com/open-ness/specs/blob/master/doc/reference-architectures/core-network/openness_ngc.md)
-   * [<b>openness_upf.md</b>: Whitepaper detailing the UPF, AF, NEF deployment support on OpenNESS for Network Edge](https://github.com/open-ness/specs/blob/master/doc/reference-architectures/core-network/openness_upf.md)
+* [<b>core-network</b>: Folder containing details of 4G CUPS and 5G edge cloud deployment support](https://github.com/smart-edge-open/specs/tree/master/doc/reference-architectures/core-network)
+   * [<b>smartedge-open_epc.md</b>: Whitepaper detailing the 4G CUPS support for Edge cloud deployment in Smart Edge Open for Network Edge](https://github.com/smart-edge-open/specs/blob/master/doc/reference-architectures/core-network/smartedge-open_epc.md)
+   * [<b>smartedge-open_ngc.md</b>: Whitepaper detailing the 5G Edge Cloud deployment support in Smart Edge Open for Network Edge](https://github.com/smart-edge-open/specs/blob/master/doc/reference-architectures/core-network/smartedge-open_ngc.md)
+   * [<b>smartedge-open_upf.md</b>: Whitepaper detailing the UPF, AF, NEF deployment support on Smart Edge Open for Network Edge](https://github.com/smart-edge-open/specs/blob/master/doc/reference-architectures/core-network/smartedge-open_upf.md)
 
 ## Enhanced Platform Awareness
 
-* [<b>enhanced-platform-awareness</b>: Folder containing individual Silicon and Software EPA that are features that are supported in OpenNESS and Network Edge](https://github.com/open-ness/specs/tree/master/doc/building-blocks/enhanced-platform-awareness)
-   * [<b>openness-hugepage.md</b>: Hugepages support for Edge Applications and Network Functions](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-hugepage.md)
-   * [<b>openness-node-feature-discovery.md</b>: Edge Node hardware and software feature discovery support in OpenNESS](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-node-feature-discovery.md)
-   * [<b>openness-sriov-multiple-interfaces.md</b>: Dedicated Physical Network interface allocation support for Edge Applications and Network Functions](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-sriov-multiple-interfaces.md)
-   * [<b>openness-dedicated-core.md</b>: Dedicated CPU core allocation support for Edge Applications and Network Functions](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-dedicated-core.md)
-   * [<b>openness-bios.md</b>: Edge platform BIOS and Firmware and configuration support in OpenNESS](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-bios.md)
-   * [<b>openness-qat.md</b>: Resource allocation & configuration of Intel® QuickAssist Adapter](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-qat.md)
-   * [<b>openness-fpga.md</b>: Dedicated FPGA IP resource allocation support for Edge Applications and Network Functions](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-fpga.md)
-   * [<b>openness_hddl.md</b>: Using Intel® Movidius™ Myriad™ X High Density Deep Learning (HDDL) solution in OpenNESS](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness_hddl.md)
-   * [<b>openness-topology-manager.md</b>: Resource Locality awareness support through Topology manager in OpenNESS](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-topology-manager.md)
-   * [<b>openness-vca.md</b>: Visual Compute Accelerator Card - Analytics (VCAC-A)](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-vcac-a.md)
-   * [<b>openness-rmd.md</b>: Cache Allocation using Resource Management Daemon(RMD) in OpenNESS](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-rmd.md)
-   * [<b>openness-telemetry</b>: Telemetry Support in OpenNESS](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-telemetry.md)
+* [<b>enhanced-platform-awareness</b>: Folder containing individual Silicon and Software EPA that are features that are supported in Smart Edge Open and Network Edge](https://github.com/smart-edge-open/specs/tree/master/doc/building-blocks/enhanced-platform-awareness)
+   * [<b>smartedge-open-hugepage.md</b>: Hugepages support for Edge Applications and Network Functions](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-hugepage.md)
+   * [<b>smartedge-open-node-feature-discovery.md</b>: Edge Node hardware and software feature discovery support in Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-node-feature-discovery.md)
+   * [<b>smartedge-open-sriov-multiple-interfaces.md</b>: Dedicated Physical Network interface allocation support for Edge Applications and Network Functions](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-sriov-multiple-interfaces.md)
+   * [<b>smartedge-open-dedicated-core.md</b>: Dedicated CPU core allocation support for Edge Applications and Network Functions](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-dedicated-core.md)
+   * [<b>smartedge-open-bios.md</b>: Edge platform BIOS and Firmware and configuration support in Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-bios.md)
+   * [<b>smartedge-open-qat.md</b>: Resource allocation & configuration of Intel® QuickAssist Adapter](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-qat.md)
+   * [<b>smartedge-open-fpga.md</b>: Dedicated FPGA IP resource allocation support for Edge Applications and Network Functions](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-fpga.md)
+   * [<b>smartedge-open_hddl.md</b>: Using Intel® Movidius™ Myriad™ X High Density Deep Learning (HDDL) solution in Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open_hddl.md)
+   * [<b>smartedge-open-topology-manager.md</b>: Resource Locality awareness support through Topology manager in Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-topology-manager.md)
+   * [<b>smartedge-open-vca.md</b>: Visual Compute Accelerator Card - Analytics (VCAC-A)](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-vcac-a.md)
+   * [<b>smartedge-open-rmd.md</b>: Cache Allocation using Resource Management Daemon(RMD) in Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-rmd.md)
+   * [<b>smartedge-open-telemetry</b>: Telemetry Support in Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-telemetry.md)
 
 ## Dataplane
 
-* [<b>dataplane</b>: Folder containing Dataplane and inter-app infrastructure support in OpenNESS](https://github.com/open-ness/specs/tree/master/doc/building-blocks/dataplane)
-   * [<b>openness-interapp.md</b>: InterApp Communication support in OpenNESS](https://github.com/open-ness/specs/blob/master/doc/building-blocks/dataplane/openness-interapp.md)
-   * [<b>openness-ovn.md</b>: OpenNESS Support for OVS as dataplane with OVN](https://github.com/open-ness/specs/blob/master/doc/building-blocks/dataplane/openness-ovn.md)
-   * [<b>openness-userspace-cni.md</b>: Userspace CNI - Container Network Interface Kubernetes plugin](https://github.com/open-ness/specs/blob/master/doc/building-blocks/dataplane/openness-userspace-cni.md)
+* [<b>dataplane</b>: Folder containing Dataplane and inter-app infrastructure support in Smart Edge Open](https://github.com/smart-edge-open/specs/tree/master/doc/building-blocks/dataplane)
+   * [<b>smartedge-open-interapp.md</b>: InterApp Communication support in Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/dataplane/smartedge-open-interapp.md)
+   * [<b>smartedge-open-ovn.md</b>: Smart Edge Open Support for OVS as dataplane with OVN](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/dataplane/smartedge-open-ovn.md)
+   * [<b>smartedge-open-userspace-cni.md</b>: Userspace CNI - Container Network Interface Kubernetes plugin](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/dataplane/smartedge-open-userspace-cni.md)
 
 ## Edge Applications
 
-* [<b>applications</b>: Folder Containing resource material for Edge Application developers](https://github.com/open-ness/specs/blob/master/doc/applications)
-   * [<b>openness_appguide.md</b>: How to develop or Port existing cloud application to the Edge cloud based on OpenNESS](https://github.com/open-ness/specs/blob/master/doc/applications/openness_appguide.md)
-   * [<b>openness_ovc.md</b>: Open Visual Cloud Smart City reference Application for OpenNESS](https://github.com/open-ness/specs/blob/master/doc/applications/openness_ovc.md)
-   * [<b>openness_openvino.md</b>: AI inference reference Edge application for OpenNESS](https://github.com/open-ness/specs/blob/master/doc/applications/openness_openvino.md)
-   * [<b>openness_va_services.md</b>: Video Analytics Services for OpenNESS](https://github.com/open-ness/specs/blob/master/doc/applications/openness_va_services.md)
-   * [<b>openness_service_mesh.md</b>: Service Mesh support in OpenNESS](https://github.com/open-ness/specs/blob/master/doc/applications/openness_service_mesh.md)
+* [<b>applications</b>: Folder Containing resource material for Edge Application developers](https://github.com/smart-edge-open/specs/blob/master/doc/applications)
+   * [<b>smartedge-open_appguide.md</b>: How to develop or Port existing cloud application to the Edge cloud based on Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/applications/smartedge-open_appguide.md)
+   * [<b>smartedge-open_ovc.md</b>: Open Visual Cloud Smart City reference Application for Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/applications/smartedge-open_ovc.md)
+   * [<b>smartedge-open_openvino.md</b>: AI inference reference Edge application for Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/applications/smartedge-open_openvino.md)
+   * [<b>smartedge-open_va_services.md</b>: Video Analytics Services for Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/applications/smartedge-open_va_services.md)
+   * [<b>smartedge-open_service_mesh.md</b>: Service Mesh support in Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/applications/smartedge-open_service_mesh.md)
 
 ## Cloud Adapters
 
-* [<b>cloud-adapters</b>: How to deploy public cloud IoT gateways on OpenNESS Edge Cloud](https://github.com/open-ness/specs/blob/master/doc/cloud-adapters)
-     * [<b>openness_awsgreengrass.md</b>: Deploying single or multiple instance of Amazon Greengrass IoT gateway on OpenNESS edge cloud as an edge application](https://github.com/open-ness/specs/blob/master/doc/cloud-adapters/openness_awsgreengrass.md)
-     * [<b>openness_baiducloud.md</b>: Deploying single or multiple instance of Baidu IoT gateway on OpenNESS edge cloud as an edge application](https://github.com/open-ness/specs/blob/master/doc/cloud-adapters/openness_baiducloud.md)
+* [<b>cloud-adapters</b>: How to deploy public cloud IoT gateways on Smart Edge Open Edge Cloud](https://github.com/smart-edge-open/specs/blob/master/doc/cloud-adapters)
+     * [<b>smartedge-open_awsgreengrass.md</b>: Deploying single or multiple instance of Amazon Greengrass IoT gateway on Smart Edge Open edge cloud as an edge application](https://github.com/smart-edge-open/specs/blob/master/doc/cloud-adapters/smartedge-open_awsgreengrass.md)
+     * [<b>smartedge-open_baiducloud.md</b>: Deploying single or multiple instance of Baidu IoT gateway on Smart Edge Open edge cloud as an edge application](https://github.com/smart-edge-open/specs/blob/master/doc/cloud-adapters/smartedge-open_baiducloud.md)
 
 ## API and Schema
 
 * [<b>Edge Application API: EAA</b>](https://www.openness.org/api-documentation/?api=eaa)
 * [<b>Edge Application Authentication API</b>](https://www.openness.org/api-documentation/?api=auth)
 * [<b>Core Network Configuration API</b>](https://www.openness.org/api-documentation/?api=cups)
-* [<b>schema</b>: Folder containing APIs protobuf or schema for varios endpoints in OpenNESS solution](https://github.com/open-ness/specs/tree/master/schema)
+* [<b>schema</b>: Folder containing APIs protobuf or schema for varios endpoints in Smart Edge Open solution](https://github.com/smart-edge-open/specs/tree/master/schema)
 
 ## Orchestration
-* [<b>openness-helm.md</b>: Helm support in OpenNESS](https://github.com/open-ness/specs/blob/master/doc/orchestration/openness-helm.md)
+* [<b>smartedge-open-helm.md</b>: Helm support in Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/orchestration/smartedge-open-helm.md)
 
 ## Release history
 
-* [<b>openness_releasenotes.md</b>: This document provides high level system features, issues and limitations information for OpenNESS](https://github.com/open-ness/specs/blob/master/openness_releasenotes.md)
+* [<b>smartedge-open_releasenotes.md</b>: This document provides high level system features, issues and limitations information for Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/smartedge-open_releasenotes.md)
 
 ## Related resources
 
-* [<b>OpenNESS Website - Developers </b>: Website containing developer resources](https://www.openness.org/developers)
-* [<b>Intel Network Builders OpenNESS training </b>](https://builders.intel.com/university/networkbuilders/coursescategory/open-network-edge-services-software-openness)
+* [<b>Smart Edge Open Website - Developers </b>: Website containing developer resources](https://www.openness.org/developers)
+* [<b>Intel Network Builders Smart Edge Open training </b>](https://builders.intel.com/university/networkbuilders/coursescategory/open-network-edge-services-software-smartedge-open)
 
 ## List of Abbreviations
 - 3GPP: Third Generation Partnership Project
@@ -114,7 +114,7 @@ Below is the complete list of OpenNESS solution documentation
 - IMSI: International Mobile Subscriber Identity
 - JSON:	JavaScript Object Notation
 - MEC: Multi-Access Edge Computing
-- OpenNESS: Open Network Edge Services Software
+- Smart Edge Open: Open Network Edge Services Software
 - LTE: Long-Term Evolution
 - MCC: Mobile Country Code
 - MME: Mobility Management Entity
@@ -148,4 +148,4 @@ Below is the complete list of OpenNESS solution documentation
 - DU: Distributed Unit of RAN
 - CU: Centralized Unit of RAN
 - CEEK: Converged Edge Experience Kits
-- IDO: Intel Distribution of OpenNESS
+- IDO: Intel Distribution of Smart Edge Open
diff --git a/_data/navbars/applications-onboarding.yml b/_data/navbars/applications-onboarding.yml
index d99fe102..1ce607b2 100644
--- a/_data/navbars/applications-onboarding.yml
+++ b/_data/navbars/applications-onboarding.yml
@@ -7,35 +7,35 @@ order: 3
 section:
   - title: Network Edge Applications Onboarding
     path: /doc/applications-onboard/network-edge-applications-onboarding
-    meta_title: OpenNESS Network Edge Application On-Boarding Process
-    meta_description: OpenNESS application on-boarding process for the Network Edge provides instructions on how to deploy an application from the Edge Controller to Edge Nodes in the cluster.
+    meta_title: Smart Edge Open Network Edge Application On-Boarding Process
+    meta_description: Smart Edge Open application on-boarding process for the Network Edge provides instructions on how to deploy an application from the Edge Controller to Edge Nodes in the cluster.
 
   - title: Edge DNS
-    path: /doc/applications-onboard/openness-edgedns
-    meta_title: OpenNESS Provides Edge DNS and Supports DNS Microservice
-    meta_description: OpenNESS edge platform is required to provides access to DNS. The edge platform receives the application DNS rules from the controller.
+    path: /doc/applications-onboard/smartedge-open-edgedns
+    meta_title: Smart Edge Open Provides Edge DNS and Supports DNS Microservice
+    meta_description: Smart Edge Open edge platform is required to provides access to DNS. The edge platform receives the application DNS rules from the controller.
 
   - title: Edge Application Agent (EAA)
-    path: /doc/applications-onboard/openness-eaa
+    path: /doc/applications-onboard/smartedge-open-eaa
     meta_title: Edge Application Agent (EAA)
-    meta_description: OpenNESS enables Edge Applications to produce, discover and consume services that are available on the OpenNESS cluster through the Edge Application Agent (EAA) APIs.
+    meta_description: Smart Edge Open enables Edge Applications to produce, discover and consume services that are available on the Smart Edge Open cluster through the Edge Application Agent (EAA) APIs.
 
   - title: Certificate Signing
-    path: /doc/applications-onboard/openness-certsigner
+    path: /doc/applications-onboard/smartedge-open-certsigner
     meta_title: Certificate Signing
     meta_description: Each application that needs the TLS authentication certificate should generate it using the Certificate Signer by sending a CSR via Certificate Requester
 
   - title: Interface Service
-    path: /doc/applications-onboard/openness-interface-service
-    meta_title: OpenNESS Applications Onboard - OpenNESS Interface Service
-    meta_description: OpenNESS Interface service is an application running in Kubernetes pod on every node of OpenNESS Kubernetes cluster and provides OVS bridge, enabling external traffic scenarios.
+    path: /doc/applications-onboard/smartedge-open-interface-service
+    meta_title: Smart Edge Open Applications Onboard - Smart Edge Open Interface Service
+    meta_description: Smart Edge Open Interface service is an application running in Kubernetes pod on every node of Smart Edge Open Kubernetes cluster and provides OVS bridge, enabling external traffic scenarios.
 
-  - title: VM support in OpenNESS for Network Edge
-    path: /doc/applications-onboard/openness-network-edge-vm-support
-    meta_title: VM support in OpenNESS for Network Edge
-    meta_description: VM support in OpenNESS for Network Edge - Setup, deployment, and management considerations.
+  - title: VM support in Smart Edge Open for Network Edge
+    path: /doc/applications-onboard/smartedge-open-network-edge-vm-support
+    meta_title: VM support in Smart Edge Open for Network Edge
+    meta_description: VM support in Smart Edge Open for Network Edge - Setup, deployment, and management considerations.
 
   - title: Core Network Configuration Agent (CNCA)
-    path: /doc/applications-onboard/using-openness-cnca
-    meta_title: OpenNESS 4G/LTE Core Configuration Using CNCA
+    path: /doc/applications-onboard/using-smartedge-open-cnca
+    meta_title: Smart Edge Open 4G/LTE Core Configuration Using CNCA
     meta_description: CNCA provides a kubectl plugin to configure the 4G/LTE Core network. Kubernetes adopts plugins concepts to extend its functionality executes CNCA related functions.
diff --git a/_data/navbars/building-blocks.yml b/_data/navbars/building-blocks.yml
index 1f3cd9a4..758eafd1 100644
--- a/_data/navbars/building-blocks.yml
+++ b/_data/navbars/building-blocks.yml
@@ -9,92 +9,92 @@ section:
     path:
     section:
     - title: Inter-App Communication
-      path: /doc/building-blocks/dataplane/openness-interapp
-      meta_title: Inter-App Communication Support in OpenNESS
-      meta_description: OpenNESS provides Inter-App Communication support for Network edge modes of OpenNESS.
+      path: /doc/building-blocks/dataplane/smartedge-open-interapp
+      meta_title: Inter-App Communication Support in Smart Edge Open
+      meta_description: Smart Edge Open provides Inter-App Communication support for Network edge modes of Smart Edge Open.
       
     - title: OVN/OVS
-      path: /doc/building-blocks/dataplane/openness-ovn
-      meta_title: OpenNESS Support for OVS as Dataplane with OVN
-      meta_description: The primary objective of supporting OVN/OVS in OpenNESS is to demonstrate the capability of using a standard dataplane like OVS for an Edge Compute platform. 
+      path: /doc/building-blocks/dataplane/smartedge-open-ovn
+      meta_title: Smart Edge Open Support for OVS as Dataplane with OVN
+      meta_description: The primary objective of supporting OVN/OVS in Smart Edge Open is to demonstrate the capability of using a standard dataplane like OVS for an Edge Compute platform. 
       
     - title: Userspace CNI
-      path: /doc/building-blocks/dataplane/openness-userspace-cni
-      meta_title: OpenNESS Userspace CNI, Setup Userspace CNI
+      path: /doc/building-blocks/dataplane/smartedge-open-userspace-cni
+      meta_title: Smart Edge Open Userspace CNI, Setup Userspace CNI
       meta_description: Userspace CNI is a Container Network Interface Kubernetes plugin that was designed to simplify the process of deployment of DPDK based applications in Kubernetes pods.
 
   - title: "Enhanced Platform Awareness"
     path:
     section:
     - title: Hugepage Support
-      path: /doc/building-blocks/enhanced-platform-awareness/openness-hugepage
-      meta_title: OpenNESS Enhanced Platform Awareness - Hugepage Support on OpenNESS
-      meta_description: Huge page support openness, added to Kubernetes v1.8, enables the discovery, scheduling, and allocation of huge pages as a native first-class resource.
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open-hugepage
+      meta_title: Smart Edge Open Enhanced Platform Awareness - Hugepage Support on Smart Edge Open
+      meta_description: Huge page support smartedge-open, added to Kubernetes v1.8, enables the discovery, scheduling, and allocation of huge pages as a native first-class resource.
 
     - title: Node Feature Discovery Support
-      path: /doc/building-blocks/enhanced-platform-awareness/openness-node-feature-discovery
-      meta_title: Enhanced Platform Awareness - Node Feature Discovery Support in OpenNESS
-      meta_description: OpenNESS Node Feature Discovery is one of the Intel technologies that supports targeting of intelligent configuration and capacity consumption of platform capabilities.
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open-node-feature-discovery
+      meta_title: Enhanced Platform Awareness - Node Feature Discovery Support in Smart Edge Open
+      meta_description: Smart Edge Open Node Feature Discovery is one of the Intel technologies that supports targeting of intelligent configuration and capacity consumption of platform capabilities.
 
     - title: Multiple Interface And PCIe SRIOV Support
-      path: /doc/building-blocks/enhanced-platform-awareness/openness-sriov-multiple-interfaces
-      meta_title: Enhanced Platform Awareness - Multiple Interface And PCIe SRIOV Support in OpenNESS
-      meta_description: Multiple Interface and PCIe SRIOV support in OpenNESS, OpenNESS Network Edge uses the Multus container network interface is a container network interface plugin for Kubernetes.
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open-sriov-multiple-interfaces
+      meta_title: Enhanced Platform Awareness - Multiple Interface And PCIe SRIOV Support in Smart Edge Open
+      meta_description: Multiple Interface and PCIe SRIOV support in Smart Edge Open, Smart Edge Open Network Edge uses the Multus container network interface is a container network interface plugin for Kubernetes.
 
     - title: Dedicated CPU Core
-      path: /doc/building-blocks/enhanced-platform-awareness/openness-dedicated-core
-      meta_title: Enhanced Platform Awareness - Dedicated CPU Core for Workload Support in OpenNESS
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open-dedicated-core
+      meta_title: Enhanced Platform Awareness - Dedicated CPU Core for Workload Support in Smart Edge Open
       meta_description: Multi-core COTS platforms are typical in any cloud or Cloudnative deployment. Parallel processing on multiple cores helps achieve better density.
 
     - title: BIOS and Firmware Configuration
-      path: /doc/building-blocks/enhanced-platform-awareness/openness-bios
-      meta_title: BIOS and Firmware Configuration on OpenNESS Platform
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open-bios
+      meta_title: BIOS and Firmware Configuration on Smart Edge Open Platform
       meta_description: BIOS and Firmware are the fundamental platform configurations of a typical Commercial off-the-shelf (COTS) platform. 
 
     - title: FPGA Support
-      path: /doc/building-blocks/enhanced-platform-awareness/openness-fpga
-      meta_title: FPGA in OpenNESS - Programming, Resource Allocation and Configuration
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open-fpga
+      meta_title: FPGA in Smart Edge Open - Programming, Resource Allocation and Configuration
       meta_description: The FPGA Programmable acceleration card plays a key role in accelerating certain types of workloads which in-turn increases the overall compute capacity of a COTS platform.
 
     - title: Intel® vRAN Dedicated Accelerator ACC100
-      path: /doc/building-blocks/enhanced-platform-awareness/openness-acc100
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open-acc100
       meta_title: Intel® vRAN Dedicated Accelerator ACC100
-      meta_description: Using ACC100 eASIC in OpenNESS, Resource Allocation, and Configuration
+      meta_description: Using ACC100 eASIC in Smart Edge Open, Resource Allocation, and Configuration
 
     - title: Intel® Movidius™ Myriad™ X HDDL Support
-      path: /doc/building-blocks/enhanced-platform-awareness/openness_hddl
-      meta_title: Intel® Movidius™ Myriad™ X HDDL Solution in OpenNESS
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open_hddl
+      meta_title: Intel® Movidius™ Myriad™ X HDDL Solution in Smart Edge Open
       meta_description: Intel® Movidius™ Myriad™ X HDDL solution integrates multiple Myriad™ X SoCs in a PCIe add-in card form factor or a module form factor to build a scalable, high capacity deep learning solution.
 
     - title: Visual Compute Accelerator Card - Analytics (VCAC-A)
-      path: /doc/building-blocks/enhanced-platform-awareness/openness-vcac-a
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open-vcac-a
       meta_title: Visual Compute Accelerator Card - Analytics (VCAC-A)
       meta_description: The Visual Cloud Accelerator Card - Analytics (VCAC-A) equips Intel® Xeon® Scalable Processor based platforms and Intel Movidius™ VPU to enhance the video codec, computer vision, and inference capabilities.
 
     - title: Intel® QuickAssist Adapter
-      path: /doc/building-blocks/enhanced-platform-awareness/openness-qat
-      meta_title: Using Intel® QuickAssist Adapter in OpenNESS - Resource Allocation, and Configuration
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open-qat
+      meta_title: Using Intel® QuickAssist Adapter in Smart Edge Open - Resource Allocation, and Configuration
       meta_description: Intel® QuickAssist Adapter plays a key role in accelerating cryptographic operations in 5G networking.
 
     - title: Topology Manager Support
-      path: /doc/building-blocks/enhanced-platform-awareness/openness-topology-manager
-      meta_title: Topology Manager Support in OpenNESS, Resource Locality Awareness
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open-topology-manager
+      meta_title: Topology Manager Support in Smart Edge Open, Resource Locality Awareness
       meta_description: Topology Manager is a solution permitting k8s components like CPU Manager and Device Manager, to coordinate the resources allocated to a workload.
 
     - title: Resource Management Daemon
-      path: /doc/building-blocks/enhanced-platform-awareness/openness-rmd
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open-rmd
       meta_title: Cache Allocation for Containers with Resource Management Daemon (RMD)
       meta_description: Intel® Resource Director Technology (Intel® RDT) provides visibility and control over how shared resources such as last-level cache (LLC) and memory bandwidth are used by applications, virtual machines (VMs), and containers.
 
-    - title: Telemetry support in OpenNESS
-      path: /doc/building-blocks/enhanced-platform-awareness/openness-telemetry
-      meta_title: Telemetry support in OpenNESS
-      meta_description: OpenNESS supports platform and application telemetry allowing users to retrieve information about the platform, the underlying hardware, cluster and applications deployed.
+    - title: Telemetry support in Smart Edge Open
+      path: /doc/building-blocks/enhanced-platform-awareness/smartedge-open-telemetry
+      meta_title: Telemetry support in Smart Edge Open
+      meta_description: Smart Edge Open supports platform and application telemetry allowing users to retrieve information about the platform, the underlying hardware, cluster and applications deployed.
 
   - title: Multi-Cluster Orchestration
     path:
     section:
     - title: Edge Multi-Cluster Orchestrator (EMCO)
-      path: /doc/building-blocks/emco/openness-emco
+      path: /doc/building-blocks/emco/smartedge-open-emco
       meta_title: Edge Multi-Cluster Orchestrator 
       meta_description: Geo-Distributed multiple clusters application orchestration.
diff --git a/_data/navbars/cloud-adapters.yml b/_data/navbars/cloud-adapters.yml
index 0a5d465b..916296aa 100644
--- a/_data/navbars/cloud-adapters.yml
+++ b/_data/navbars/cloud-adapters.yml
@@ -6,11 +6,11 @@ path: /cloud-adapters/
 order: 6
 section:
   - title: AWS Greengrass
-    path: /doc/cloud-adapters/openness_awsgreengrass
-    meta_title: OpenNESS Integration with AWS Greengrass
-    meta_description: OpenNESS is an open source software platform that enables easy orchestration of edge services across diverse network platform and access technologies in multi-cloud environments.
+    path: /doc/cloud-adapters/smartedge-open_awsgreengrass
+    meta_title: Smart Edge Open Integration with AWS Greengrass
+    meta_description: Smart Edge Open is an open source software platform that enables easy orchestration of edge services across diverse network platform and access technologies in multi-cloud environments.
     
   - title: Baidu Cloud
-    path: /doc/cloud-adapters/openness_baiducloud
-    meta_title: OpenNESS Integration with Baidu OpenEdge
-    meta_description: OpenNESS can integrate with Baidu Cloud Connector, OpenEdge which is Edge IoT Gateway. Baidu Edge solution is called as Baidu® IntelliEdge.
+    path: /doc/cloud-adapters/smartedge-open_baiducloud
+    meta_title: Smart Edge Open Integration with Baidu OpenEdge
+    meta_description: Smart Edge Open can integrate with Baidu Cloud Connector, OpenEdge which is Edge IoT Gateway. Baidu Edge solution is called as Baidu® IntelliEdge.
diff --git a/_data/navbars/devkits.yml b/_data/navbars/devkits.yml
index 18c8cedf..14600404 100644
--- a/_data/navbars/devkits.yml
+++ b/_data/navbars/devkits.yml
@@ -5,7 +5,7 @@ title: "Development Kits"
 path: /devkits/
 order: 7
 section:
-  - title: OpenNESS Development Kit for Microsoft Azure
-    path: /doc/devkits/openness-azure-devkit
-    meta_title: OpenNESS Development Kit for Microsoft Azure
-    meta_description: This devkit supports the use of OpenNESS in cloud solutions. It leverages the Microsoft Azure Stack for OpenNESS deployment.
+  - title: Smart Edge Open Development Kit for Microsoft Azure
+    path: /doc/devkits/smartedge-open-azure-devkit
+    meta_title: Smart Edge Open Development Kit for Microsoft Azure
+    meta_description: This devkit supports the use of Smart Edge Open in cloud solutions. It leverages the Microsoft Azure Stack for Smart Edge Open deployment.
diff --git a/_data/navbars/edge-applications.yml b/_data/navbars/edge-applications.yml
index 9c00dae3..20916010 100644
--- a/_data/navbars/edge-applications.yml
+++ b/_data/navbars/edge-applications.yml
@@ -6,26 +6,26 @@ path: /applications/
 order: 5
 section:
   - title: Application Development & Porting Guide
-    path: /doc/applications/openness_appguide
+    path: /doc/applications/smartedge-open_appguide
     meta_title: Application Development and Porting Guide
-    meta_description: OpenNESS is an open source software toolkit to enable easy orchestration of edge services across diverse network platform and access technologies in multi-cloud environments. 
+    meta_description: Smart Edge Open is an open source software toolkit to enable easy orchestration of edge services across diverse network platform and access technologies in multi-cloud environments. 
 
   - title: OVC Smart City Application
-    path: /doc/applications/openness_ovc
-    meta_title: Open Visual Cloud Smart City Application on OpenNESS
+    path: /doc/applications/smartedge-open_ovc
+    meta_title: Open Visual Cloud Smart City Application on Smart Edge Open
     meta_description: The Open Visual Cloud is an open source project that offers a set of pre-defined reference pipelines for various target visual cloud use cases.
 
   - title: Intel OpenVINO Sample Application
-    path: /doc/applications/openness_openvino
-    meta_title: OpenVINO Sample Application in OpenNESS
+    path: /doc/applications/smartedge-open_openvino
+    meta_title: OpenVINO Sample Application in Smart Edge Open
     meta_description: OpenVINO toolkit, short for Open Visual Inference and Neural network Optimization toolkit, provides improved neural network performance on Intel processors.
 
-  - title: OpenNESS Video Analytics Services
-    path: /doc/applications/openness_va_services
-    meta_title: OpenNESS Video Analytics Services
-    meta_description: The Video Analytics Services provided by OpenNESS to enable third party edge application to deploy and use hardware optimized video analytics pipelines.
+  - title: Smart Edge Open Video Analytics Services
+    path: /doc/applications/smartedge-open_va_services
+    meta_title: Smart Edge Open Video Analytics Services
+    meta_description: The Video Analytics Services provided by Smart Edge Open to enable third party edge application to deploy and use hardware optimized video analytics pipelines.
 
-  - title: OpenNESS Service Mesh
-    path: /doc/applications/openness_service_mesh
-    meta_title: OpenNESS Service Mesh
-    meta_description: Service mesh acts as a middleware between the edge applications/services and the OpenNESS platform providing abstractions for traffic management, observability and security for the edge micro-services.
+  - title: Smart Edge Open Service Mesh
+    path: /doc/applications/smartedge-open_service_mesh
+    meta_title: Smart Edge Open Service Mesh
+    meta_description: Service mesh acts as a middleware between the edge applications/services and the Smart Edge Open platform providing abstractions for traffic management, observability and security for the edge micro-services.
diff --git a/_data/navbars/getting-started.yml b/_data/navbars/getting-started.yml
index 61dea6e4..04229d91 100644
--- a/_data/navbars/getting-started.yml
+++ b/_data/navbars/getting-started.yml
@@ -5,27 +5,27 @@ title: "Getting Started"
 path: /getting-started/
 order: 1
 section:
-  - title: OpenNESS Cluster Setup
-    path: /doc/getting-started/openness-cluster-setup
+  - title: Smart Edge Open Cluster Setup
+    path: /doc/getting-started/smartedge-open-cluster-setup
     meta_title: Controller and Edge Node Setup
-    meta_description: OpenNESS Network Edge Controller and Edge nodes must be set up on different machines and provided in the inventory may reboot during the installation.
+    meta_description: Smart Edge Open Network Edge Controller and Edge nodes must be set up on different machines and provided in the inventory may reboot during the installation.
 
   - title: Converged Edge Experience Kits
     path: /doc/getting-started/converged-edge-experience-kits
-    meta_title: OpenNESS Experience Kits Easy Setup of OpenNESS in Network Edge
-    meta_description: OpenNESS Experience Kits repository contains easy setup of OpenNESS in Network Edge mode.
+    meta_title: Smart Edge Open Experience Kits Easy Setup of Smart Edge Open in Network Edge
+    meta_description: Smart Edge Open Experience Kits repository contains easy setup of Smart Edge Open in Network Edge mode.
 
-  - title: Non-root User in OpenNESS
+  - title: Non-root User in Smart Edge Open
     path: /doc/getting-started/non-root-user
-    meta_title: The non-root user on the OpenNESS Platform
-    meta_description: OpenNESS provides a possibility to install all required files on Kubernetes a control plane and nodes with or without root rights.
+    meta_title: The non-root user on the Smart Edge Open Platform
+    meta_description: Smart Edge Open provides a possibility to install all required files on Kubernetes a control plane and nodes with or without root rights.
 
   - title: Harbor Registry Service
     path: /doc/getting-started/harbor-registry
-    meta_title: Harbor Registry Service in OpenNESS
-    meta_description: Enabling Harbor registry service in OpenNESS
+    meta_title: Harbor Registry Service in Smart Edge Open
+    meta_description: Enabling Harbor registry service in Smart Edge Open
 
-  - title: Kubernetes Dashboard in OpenNESS
+  - title: Kubernetes Dashboard in Smart Edge Open
     path: /doc/getting-started/kubernetes-dashboard
-    meta_title: Kubernetes Dashboard in OpenNESS
-    meta_description: OpenNESS supports Kubernetes Dashboard that can be used to inspect and manage Kubernetes cluster.
+    meta_title: Kubernetes Dashboard in Smart Edge Open
+    meta_description: Smart Edge Open supports Kubernetes Dashboard that can be used to inspect and manage Kubernetes cluster.
diff --git a/_data/navbars/introduction.yml b/_data/navbars/introduction.yml
index baabe3b1..bd5edefc 100644
--- a/_data/navbars/introduction.yml
+++ b/_data/navbars/introduction.yml
@@ -5,22 +5,22 @@ title: "Introduction"
 path: /introduction/
 order: 0
 section:
-  - title: OpenNESS Overview
+  - title: Smart Edge Open Overview
     path: /doc/overview
-    meta_title: OpenNESS Overview
-    meta_description: OpenNESS is an edge computing software toolkit that enables highly optimized and performant edge platforms to on-board and manage applications and network functions with cloud-like agility across any type of network.
+    meta_title: Smart Edge Open Overview
+    meta_description: Smart Edge Open is an edge computing software toolkit that enables highly optimized and performant edge platforms to on-board and manage applications and network functions with cloud-like agility across any type of network.
 
-  - title: OpenNESS Architecture & Solution Overview
+  - title: Smart Edge Open Architecture & Solution Overview
     path: /doc/architecture
-    meta_title: OpenNESS Architecture And Solution Overview
-    meta_description: OpenNESS is an open source software to enable easy orchestration of edge services and network functions across diverse network platform in multi-cloud environments.
+    meta_title: Smart Edge Open Architecture And Solution Overview
+    meta_description: Smart Edge Open is an open source software to enable easy orchestration of edge services and network functions across diverse network platform in multi-cloud environments.
 
-  - title: OpenNESS Deployment Flavors
+  - title: Smart Edge Open Deployment Flavors
     path: /doc/flavors
-    meta_title: OpenNESS Deployment Flavors
-    meta_description: Pre-defined deployment flavors using OpenNESS that are available in the OpenNESS Experience Kits.
+    meta_title: Smart Edge Open Deployment Flavors
+    meta_description: Pre-defined deployment flavors using Smart Edge Open that are available in the Smart Edge Open Experience Kits.
 
-  - title: OpenNESS Helm
-    path: /doc/orchestration/openness-helm
-    meta_title: OpenNESS Helm
-    meta_description: OpenNESS supports Helm for user to package, configure, and deploy applications and services onto Kubernetes clusters.
+  - title: Smart Edge Open Helm
+    path: /doc/orchestration/smartedge-open-helm
+    meta_title: Smart Edge Open Helm
+    meta_description: Smart Edge Open supports Helm for user to package, configure, and deploy applications and services onto Kubernetes clusters.
diff --git a/_data/navbars/reference-architectures.yml b/_data/navbars/reference-architectures.yml
index 4e177550..627a7575 100644
--- a/_data/navbars/reference-architectures.yml
+++ b/_data/navbars/reference-architectures.yml
@@ -9,37 +9,37 @@ section:
     path:
     section:
     - title: Evolved Packet Core (EPC)
-      path: /doc/reference-architectures/core-network/openness_epc
+      path: /doc/reference-architectures/core-network/smartedge-open_epc
       meta_title: Edge Cloud Deployment with 3GPP 4G LTE CUPS of EPC
-      meta_description: OpenNESS is an open source edge computing platform that enables Service Providers and Enterprises to deploy applications and services on a network edge.
+      meta_description: Smart Edge Open is an open source edge computing platform that enables Service Providers and Enterprises to deploy applications and services on a network edge.
 
     - title: 5G Non-Stand Alone (NSA)
-      path: /doc/reference-architectures/core-network/openness_5g_nsa
+      path: /doc/reference-architectures/core-network/smartedge-open_5g_nsa
       meta_title: Edge Cloud Deployment with 3GPP 5G Non Stand Alone
-      meta_description: OpenNESS is an open source edge computing platform that enables Service Providers and Enterprises to deploy applications and services on a network edge.
+      meta_description: Smart Edge Open is an open source edge computing platform that enables Service Providers and Enterprises to deploy applications and services on a network edge.
   
     - title: Next-Gen Core (NGC)
-      path: /doc/reference-architectures/core-network/openness_ngc
+      path: /doc/reference-architectures/core-network/smartedge-open_ngc
       meta_title: Edge Cloud Deployment with 3GPP 5G Stand Alone
-      meta_description: OpenNESS NGC provides reference REST-based APIs along with 3GPP standard traffic influencing APIs to address some of these major challenges in 5G edge deployments.
+      meta_description: Smart Edge Open NGC provides reference REST-based APIs along with 3GPP standard traffic influencing APIs to address some of these major challenges in 5G edge deployments.
       
     - title: User Plane Function (UPF)
-      path: /doc/reference-architectures/core-network/openness_upf
+      path: /doc/reference-architectures/core-network/smartedge-open_upf
       meta_title: User Plane Function (UPF)
       meta_description: User Plane Function is the evolution of Control and User Plane Separation which part of the Rel.14 in Evolved Packet core. CUPS enabled PGW to be split into PGW-C and PGW-U.
 
   - title: Radio Access Network
     path:
     section:
-    - title: OpenNESS Radio Access Network
-      path: /doc/reference-architectures/ran/openness_ran
-      meta_title: OpenNESS Radio Access Network is the Edge of Wireless Network
-      meta_description: OpenNESS Radio Access Network is the edge of the wireless network. OpenNESS Intel FlexRAN uses as a reference 4G and 5G base station for 4G and 5G end-to-end testing.
+    - title: Smart Edge Open Radio Access Network
+      path: /doc/reference-architectures/ran/smartedge-open_ran
+      meta_title: Smart Edge Open Radio Access Network is the Edge of Wireless Network
+      meta_description: Smart Edge Open Radio Access Network is the edge of the wireless network. Smart Edge Open Intel FlexRAN uses as a reference 4G and 5G base station for 4G and 5G end-to-end testing.
 
-    - title: O-RAN Front Haul Sample Application in OpenNESS 
-      path: /doc/reference-architectures/ran/openness_xran
-      meta_title: 5GNR FlexRAN Front Haul functional units deployment with OpenNESS based on O-RAN specifications at the Network Edge
-      meta_description: 5GNR FlexRAN Front Haul functional units deployment with OpenNESS based on O-RAN specifications at the Network Edge.
+    - title: O-RAN Front Haul Sample Application in Smart Edge Open 
+      path: /doc/reference-architectures/ran/smartedge-open_xran
+      meta_title: 5GNR FlexRAN Front Haul functional units deployment with Smart Edge Open based on O-RAN specifications at the Network Edge
+      meta_description: 5GNR FlexRAN Front Haul functional units deployment with Smart Edge Open based on O-RAN specifications at the Network Edge.
 
   - title: Converged Edge Reference Architecture Near Edge
     path: /doc/reference-architectures/CERA-Near-Edge
diff --git a/_data/navbars/release-history.yml b/_data/navbars/release-history.yml
index 5e1ccabd..03c2e795 100644
--- a/_data/navbars/release-history.yml
+++ b/_data/navbars/release-history.yml
@@ -6,6 +6,6 @@ path: /release-notes/
 order: 8
 section:
   - title: Release Notes
-    path: /openness_releasenotes
-    meta_title: OpenNESS Release Notes
-    meta_description: OpenNESS Release Notes provides high level system features, issues, and limitations information for OpenNESS.
+    path: /smartedge-open_releasenotes
+    meta_title: Smart Edge Open Release Notes
+    meta_description: Smart Edge Open Release Notes provides high level system features, issues, and limitations information for Smart Edge Open.
diff --git a/_includes/footer.html b/_includes/footer.html
index 80c5eb02..e6fad3bf 100644
--- a/_includes/footer.html
+++ b/_includes/footer.html
@@ -7,8 +7,8 @@
       <div class="container">
         <div class="col-md-12">
           <div class="footer-link">
-            <ul class="nav menu openness_footer mod-list">
-              <li class="divider"><span class="separator ">&copy; OpenNESS</span></li>
+            <ul class="nav menu smartedge-open_footer mod-list">
+              <li class="divider"><span class="separator ">&copy; Smart Edge Open</span></li>
               <li><a href="http://www.intel.com/content/www/us/en/legal/terms-of-use.html" rel="noopener noreferrer nofollow" target="_blank">Terms of Use</a></li>
               <li><a href="https://www.intel.com/content/www/us/en/privacy/intel-privacy-notice.html" rel="noopener noreferrer nofollow" target="_blank">Privacy</a></li>
               <li><a href="http://www.intel.com/content/www/us/en/privacy/intel-cookie-notice.html" rel="noopener noreferrer nofollow" target="_blank">Cookies</a></li>
diff --git a/_includes/header.html b/_includes/header.html
index 0d2fa41a..d420614e 100644
--- a/_includes/header.html
+++ b/_includes/header.html
@@ -16,9 +16,9 @@
           <div class="navbar-header col-lg-3 col-md-4 col-sm-3 col-xs-12">
             <div class="logoheader">
               <div class="logo">
-                <a class="navbar-brand" title="OpenNESS" href="/">
-                <img src="{{ '/images/openness-logo.png' | prepend: site.siteurl }}" alt="OpenNESS" width="340" height="85" class="tabRest">
-                <img src="{{ '/images/openness-logo-sm.png' | prepend: site.siteurl }}" alt="OpenNESS" width="170" height="45" class="tabOnly" style="display:none;">
+                <a class="navbar-brand" title="Smart Edge Open" href="/">
+                <img src="{{ '/images/smartedge-open-logo.png' | prepend: site.siteurl }}" alt="Smart Edge Open" width="340" height="85" class="tabRest">
+                <img src="{{ '/images/smartedge-open-logo-sm.png' | prepend: site.siteurl }}" alt="Smart Edge Open" width="170" height="45" class="tabOnly" style="display:none;">
                 </a>
               </div>
             </div>
@@ -32,11 +32,11 @@
 					<span class="hamb-middle"></span>
 					<span class="hamb-bottom"></span>
 				  </div>
-                  <ul class="nav menu opennessmenu mod-list">
+                  <ul class="nav menu smartedge-openmenu mod-list">
                     <li class="item-102 deeper parent">
 						<a href="/about">About</a>
 						<ul class="nav-child unstyled small" style="display: none;">
-							<li class="item-118"><a href="/about#openness-overview" class="lowerCase">OpenNESS OVERVIEW</a></li>
+							<li class="item-118"><a href="/about#smartedge-open-overview" class="lowerCase">Smart Edge Open OVERVIEW</a></li>
 							<li class="item-119"><a href="/about#technical-steering-committee-charter">Technical Steering Committee Charter</a></li>
 						</ul>
 					</li>
@@ -44,8 +44,8 @@
 						<a href="/products">Products</a>
 						<ul class="nav-child unstyled small" style="display: none;">
 							<li class="item-166"><a href="/products">Getting Started</a></li>
-							<li class="item-149"><a href="/docs/openness_releasenotes/" class="lowerCase">OpenNESS</a></li>
-							<li class="item-168"><a href="/products/intel-distribution" class="lowerCase">INTEL® DISTRIBUTION OF OpenNESS</a></li>
+							<li class="item-149"><a href="/docs/smartedge-open_releasenotes/" class="lowerCase">Smart Edge Open</a></li>
+							<li class="item-168"><a href="/products/intel-distribution" class="lowerCase">INTEL® DISTRIBUTION OF Smart Edge Open</a></li>
 						</ul>
 					</li>
 					<li class="item-103 deeper parent">
diff --git a/_includes/metainfo.html b/_includes/metainfo.html
index 72fcef32..cd04f97c 100644
--- a/_includes/metainfo.html
+++ b/_includes/metainfo.html
@@ -16,12 +16,12 @@
            {% if metainfo.meta_description != nil %}
                <meta name="description" content="{{metainfo.meta_description}}" />
            {% else %}
-               <meta name="description" content="{{pageTitleUpper}}: This document provides high level system features, issues and limitations information for OpenNESS." />
+               <meta name="description" content="{{pageTitleUpper}}: This document provides high level system features, issues and limitations information for Smart Edge Open." />
            {%- endif -%}
            {% if metainfo.meta_title != nil %}
                <title>{{metainfo.meta_title}}</title>
            {% else %}
-               <title>OpenNESS Documentation - {{pageTitleUpper}}</title>
+               <title>Smart Edge Open Documentation - {{pageTitleUpper}}</title>
            {%- endif -%}
         {%- endif -%}
     {%- endif -%}
diff --git a/_layouts/openness.html b/_layouts/smartedge-open.html
similarity index 94%
rename from _layouts/openness.html
rename to _layouts/smartedge-open.html
index dd5d8ca6..04447e3d 100644
--- a/_layouts/openness.html
+++ b/_layouts/smartedge-open.html
@@ -39,7 +39,7 @@
             {%- endif -%}
           </div>
           <div class="editLink pull-right">
-            <a data-proofer-ignore href="https://github.com/open-ness/specs/blob/master/{{page.path}}" rel="nofollow" class="edit-page-link" target="_blank">
+            <a data-proofer-ignore href="https://github.com/smart-edge-open/specs/blob/master/{{page.path}}" rel="nofollow" class="edit-page-link" target="_blank">
                 <i class="fa fa-github" aria-hidden="true"></i>
                 Edit this page
             </a>
diff --git a/_layouts/openness_pdf.html b/_layouts/smartedge-open_pdf.html
similarity index 93%
rename from _layouts/openness_pdf.html
rename to _layouts/smartedge-open_pdf.html
index bf9a2ca2..247bc242 100644
--- a/_layouts/openness_pdf.html
+++ b/_layouts/smartedge-open_pdf.html
@@ -9,7 +9,7 @@
       page_size: A4, Letter, etc. | default:A4 
       layout: layout | default:pdf
       
-  pdf_layout: openness_pdf
+  pdf_layout: smartedge-open_pdf
 ---
 
 <!DOCTYPE html>
diff --git a/css/custom.css b/css/custom.css
index 0272d7f1..503e516f 100644
--- a/css/custom.css
+++ b/css/custom.css
@@ -222,7 +222,7 @@ hr{margin-top:10px}
 .menubar>.container{padding:0}
 .nav-mobile{display:block;top:-35px;right:10px}
 .nav-mobile i{font-size:18px}
-.opennessmenu{display:none;width:340px;background-color:#193f6e;max-width:calc(100% - 20px)}
+.smartedge-openmenu{display:none;width:340px;background-color:#193f6e;max-width:calc(100% - 20px)}
 #header .row [class^="col-"]{width:100%!important}
 #header>.container{padding-left:15px;padding-right:15px}
 .menubar ul li{width:100%;float:none}
@@ -239,7 +239,7 @@ hr{margin-top:10px}
 .nav-mobile i{font-size:18px}
 .menubar ul li{width:100%;float:none}
 .menubar ul li:nth-child(2){border:none}
-.opennessmenu{display:none;width:340px;background-color:#193f6e;max-width:calc(100% - 20px)}
+.smartedge-openmenu{display:none;width:340px;background-color:#193f6e;max-width:calc(100% - 20px)}
 .menubar .nav.menu li ul.nav-child{position:static;width:100%}
 .menubar .nav.menu>li:hover ul.nav-child{position:static;display:none}
 .menubar ul li span.separator{cursor:pointer}
@@ -249,7 +249,7 @@ hr{margin-top:10px}
 .menubar .nav.menu>li.parent>a:after{display:none}
 .menubar{position:absolute;left:0;top:50px;right:0;box-shadow:inherit;margin-bottom:0}
 .menubar>.container{padding:0}
-.menubar .opennessmenu{padding-right:15px;padding-left:15px;float:right}
+.menubar .smartedge-openmenu{padding-right:15px;padding-left:15px;float:right}
 .menubar ul{border-bottom:0 solid #ececec}
 .menubar .nav.menu li span.separator,.menubar .nav.menu li a{padding-left:0;margin-left:0;margin-bottom:0;border-bottom:1px solid transparent;color:#fff}
 .menubar .nav.menu li ul.nav-child li a{border-bottom:none;padding:.4em 0 .4em 20px}
@@ -275,7 +275,7 @@ hr{margin-top:10px}
 @media (min-width:769px) {
 .menubar li:hover>ul{display:block!important;position:absolute}
 .nav-mobile{display:none}
-.opennessmenu{display:block!important;width:auto}
+.smartedge-openmenu{display:block!important;width:auto}
 .menubar li ul{display:none!important}
 .menubar li:hover>ul{display:block!important;position:absolute}
 }
diff --git a/doc/applications-onboard/index.html b/doc/applications-onboard/index.html
index 16489115..d278fc1f 100644
--- a/doc/applications-onboard/index.html
+++ b/doc/applications-onboard/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
 window.location = "network-edge-applications-onboarding"
 </script>
diff --git a/doc/applications-onboard/network-edge-applications-onboarding.md b/doc/applications-onboard/network-edge-applications-onboarding.md
index 6b516bb9..0dc7f968 100644
--- a/doc/applications-onboard/network-edge-applications-onboarding.md
+++ b/doc/applications-onboard/network-edge-applications-onboarding.md
@@ -5,7 +5,7 @@ Copyright (c) 2019-2020 Intel Corporation
 <!-- omit in toc -->
 # Network Edge Applications Onboarding
 - [Introduction](#introduction)
-- [Installing OpenNESS](#installing-openness)
+- [Installing Smart Edge Open](#installing-smart-edge-open)
 - [Building applications](#building-applications)
   - [Building sample application images](#building-sample-application-images)
   - [Building the OpenVINO application images](#building-the-openvino-application-images)
@@ -32,26 +32,26 @@ Copyright (c) 2019-2020 Intel Corporation
   - [Useful Commands:](#useful-commands)
 
 # Introduction
-This document aims to familiarize users with the Open Network Edge Services Software (OpenNESS) application on-boarding process for the Network Edge. This document provides instructions on how to deploy an application from the Edge Controller to Edge Nodes in the cluster; it also provides sample deployment scenarios and traffic configuration for the application. The applications will be deployed from the Edge Controller via the Kubernetes `kubectl` command-line utility. Sample specification files for application onboarding are also provided.
+This document aims to familiarize users with the Open Network Edge Services Software (Smart Edge Open) application on-boarding process for the Network Edge. This document provides instructions on how to deploy an application from the Edge Controller to Edge Nodes in the cluster; it also provides sample deployment scenarios and traffic configuration for the application. The applications will be deployed from the Edge Controller via the Kubernetes `kubectl` command-line utility. Sample specification files for application onboarding are also provided.
 
-# Installing OpenNESS
-The following application onboarding steps assume that OpenNESS was installed through [OpenNESS playbooks](../getting-started/openness-cluster-setup.md).
+# Installing Smart Edge Open
+The following application onboarding steps assume that Smart Edge Open was installed through [Smart Edge Open playbooks](../getting-started/smartedge-open-cluster-setup.md).
 
 # Building applications
-Users must provide the application to be deployed on the OpenNESS platform for Network Edge. The application must be provided in a Docker\* image format that is available either from an external Docker repository (Docker Hub) or a locally built Docker image. The image must be available on the Edge Node, which the application will be deployed on.
+Users must provide the application to be deployed on the Smart Edge Open platform for Network Edge. The application must be provided in a Docker\* image format that is available either from an external Docker repository (Docker Hub) or a locally built Docker image. The image must be available on the Edge Node, which the application will be deployed on.
 
 > **Note**: The Harbor registry setup is out of scope for this document. If users already have a docker container image file and would like to copy it to the node manually, they can use the `docker load` command to add the image. The success of using a pre-built Docker image depends on the application dependencies that users must know.
 
-The OpenNESS [edgeapps](https://github.com/open-ness/edgeapps) repository provides images for OpenNESS supported applications. Pull the repository to your Edge Node to build the images.
+The Smart Edge Open [edgeapps](https://github.com/smart-edge-open/edgeapps) repository provides images for Smart Edge Open supported applications. Pull the repository to your Edge Node to build the images.
 
 This document explains the build and deployment of two applications:
-1. Sample application: a simple “Hello, World!” reference application for OpenNESS
+1. Sample application: a simple “Hello, World!” reference application for Smart Edge Open
 2. OpenVINO™ application: A close to real-world inference application
 
 ## Building sample application images
-The sample application is available in [the edgeapps repository](https://github.com/open-ness/edgeapps/tree/master/applications/sample-app); further information about the application is contained within the `Readme.md` file.
+The sample application is available in [the edgeapps repository](https://github.com/smart-edge-open/edgeapps/tree/master/applications/sample-app); further information about the application is contained within the `Readme.md` file.
 
-The following steps are required to build the sample application Docker images for testing the OpenNESS Edge Application Agent (EAA) with consumer and producer applications:
+The following steps are required to build the sample application Docker images for testing the Smart Edge Open Edge Application Agent (EAA) with consumer and producer applications:
 
 1. To build the application binaries and Docker images run make:
    ```
@@ -64,7 +64,7 @@ The following steps are required to build the sample application Docker images f
    docker images | grep consumer
    ```
 ## Building the OpenVINO application images
-The OpenVINO application is available in [the EdgeApps repository](https://github.com/open-ness/edgeapps/tree/master/applications/openvino); further information about the application is contained within `Readme.md` file.
+The OpenVINO application is available in [the EdgeApps repository](https://github.com/smart-edge-open/edgeapps/tree/master/applications/openvino); further information about the application is contained within `Readme.md` file.
 
 The following steps are required to build the sample application Docker images for testing OpenVINO consumer and producer applications:
 
@@ -72,7 +72,7 @@ The following steps are required to build the sample application Docker images f
    ```
    ./build-image.sh
    ```
->**Note**: Only CPU inference support is currently available for OpenVINO application on OpenNESS Network Edge. The environmental variable `OPENVINO_ACCL` must be set to `CPU` within the Dockerfile available in the directory.
+>**Note**: Only CPU inference support is currently available for OpenVINO application on Smart Edge Open Network Edge. The environmental variable `OPENVINO_ACCL` must be set to `CPU` within the Dockerfile available in the directory.
 
 2. To build the consumer application image from the application directory, navigate to the `./consumer` directory and run:
    ```
@@ -96,11 +96,11 @@ Additionally, an application to generate sample traffic is provided. The applica
    ```
 
 # Onboarding sample application
-This section guides users through the complete process of onboarding a sample application and testing the EAA functionality of OpenNESS for the Network Edge. This process outlines how to start the application, setup network policies, and verify functionality.
+This section guides users through the complete process of onboarding a sample application and testing the EAA functionality of Smart Edge Open for the Network Edge. This process outlines how to start the application, setup network policies, and verify functionality.
 
 ## Prerequisites
 
-* OpenNESS for Network Edge is fully installed and set up.
+* Smart Edge Open for Network Edge is fully installed and set up.
 * Docker images for the sample application consumer and producer are available on Edge Node.
 
 ## Verifying image availability
@@ -442,7 +442,7 @@ This section guides users through the complete process of onboarding the OpenVIN
 
 ## Prerequisites
 
-* OpenNESS for Network Edge is fully installed and set up (kubeovn as cni to support Interfaceservice which is openness developed kubectl plugin.).
+* Smart Edge Open for Network Edge is fully installed and set up (kubeovn as cni to support Interfaceservice which is smartedge-open developed kubectl plugin.).
 * The Docker images for OpenVINO are available on the Edge Node.
 * A separate host used for generating traffic via Client Simulator is set up.
 * The Edge Node host and traffic generating host are connected point to point via unused physical network interfaces.
@@ -450,7 +450,7 @@ This section guides users through the complete process of onboarding the OpenVIN
 
 ## Setting up networking interfaces
 
-1. On the traffic generating host setup to run Client Simulator, configure the network interface connected to Edge Node host. External client traffic in the OpenNESS Network Edge configuration is routed via 192.168.1.1, the IP address of traffic generating host must be one from the same subnet. Configure the routing accordingly:
+1. On the traffic generating host setup to run Client Simulator, configure the network interface connected to Edge Node host. External client traffic in the Smart Edge Open Network Edge configuration is routed via 192.168.1.1, the IP address of traffic generating host must be one from the same subnet. Configure the routing accordingly:
    ```
    ip a a 192.168.1.10/24 dev <client_interface_name>
    route add -net 10.16.0.0/24 gw 192.168.1.1 dev <client_interface_name>
@@ -491,12 +491,12 @@ This section guides users through the complete process of onboarding the OpenVIN
 
 ## Deploying the Application
 
-1. An application `yaml` specification file for the OpenVINO producer that is used to deploy the K8s pod can be found in the Edge Apps repository at [./applications/openvino/producer/openvino-prod-app.yaml](https://github.com/open-ness/edgeapps/blob/master/applications/openvino/producer/openvino-prod-app.yaml). The pod will use the Docker image, which must be [built](#building-openvino-application-images) and available on the platform. Deploy the producer application by running:
+1. An application `yaml` specification file for the OpenVINO producer that is used to deploy the K8s pod can be found in the Edge Apps repository at [./applications/openvino/producer/openvino-prod-app.yaml](https://github.com/smart-edge-open/edgeapps/blob/master/applications/openvino/producer/openvino-prod-app.yaml). The pod will use the Docker image, which must be [built](#building-openvino-application-images) and available on the platform. Deploy the producer application by running:
    ```
    kubectl apply -f openvino-prod-app.yaml
    kubectl certificate approve openvino-prod-app
    ```
-2. An application `yaml` specification file for the OpenVINO consumer that is used to deploy K8s pod can be found in the Edge Apps repository at [./applications/openvino/consumer/openvino-cons-app.yaml](https://github.com/open-ness/edgeapps/blob/master/applications/openvino/consumer/openvino-cons-app.yaml). The pod will use the Docker image, which must be [built](#building-openvino-application-images) and available on the platform. Deploy the consumer application by running:
+2. An application `yaml` specification file for the OpenVINO consumer that is used to deploy K8s pod can be found in the Edge Apps repository at [./applications/openvino/consumer/openvino-cons-app.yaml](https://github.com/smart-edge-open/edgeapps/blob/master/applications/openvino/consumer/openvino-cons-app.yaml). The pod will use the Docker image, which must be [built](#building-openvino-application-images) and available on the platform. Deploy the consumer application by running:
    ```
    kubectl apply -f openvino-cons-app.yaml
    kubectl certificate approve openvino-cons-app
@@ -593,7 +593,7 @@ The following is an example of how to set up DNS resolution for OpenVINO consume
    dig openvino.openness
    ```
 3. On the traffic generating host build the image for the [Client Simulator](#building-openvino-application-images)
-4. Run the following from [edgeapps/applications/openvino/clientsim](https://github.com/open-ness/edgeapps/blob/master/applications/openvino/clientsim/run-docker.sh) to start the video traffic via the containerized Client Simulator. A graphical user environment is required to view the results of the returning augmented videos stream.
+4. Run the following from [edgeapps/applications/openvino/clientsim](https://github.com/smart-edge-open/edgeapps/blob/master/applications/openvino/clientsim/run-docker.sh) to start the video traffic via the containerized Client Simulator. A graphical user environment is required to view the results of the returning augmented videos stream.
    ```
    ./run_docker.sh
    ```
@@ -619,27 +619,27 @@ The following is an example of how to set up DNS resolution for OpenVINO consume
 
 The Smart City sample application is built on the OpenVINO and Open Visual Cloud (OVC) software stacks for media processing and analytics. It simulates regional offices that aggregate multiple (simulated) IP cameras and associated analytics. Each simulated office is deployed on an edge node. The sample app demonstrates the ability to reduce latency by running the media processing and analytics workloads on edge nodes.
 
-The full pipeline of the Smart City sample application on OpenNESS is distributed across three regions:
+The full pipeline of the Smart City sample application on Smart Edge Open is distributed across three regions:
 
  1. Client-side Cameras Simulator(s)
- 2. OpenNESS Cluster
+ 2. Smart Edge Open Cluster
  3. Smart City Cloud Cluster
 
-The Smart City setup with OpenNESS should typically be deployed as shown in this Figure. The drawing depicts two offices but there is no limitation to the number of offices.
+The Smart City setup with Smart Edge Open should typically be deployed as shown in this Figure. The drawing depicts two offices but there is no limitation to the number of offices.
 
 ![Smart City Setup](network-edge-app-onboarding-images/ovc-smartcity-setup.png)
 
-_Figure - Smart City Setup with OpenNESS_
+_Figure - Smart City Setup with Smart Edge Open_
 
 
 ## Setting up networking interfaces
 
-> **NOTE**: At the time of writing this guide, there was no [Network Policy for Kubernetes](https://kubernetes.io/docs/concepts/services-networking/network-policies/) defined yet for the Smart City application. Therefore, users are advised to remove the default OpenNESS network policies with the following command:
+> **NOTE**: At the time of writing this guide, there was no [Network Policy for Kubernetes](https://kubernetes.io/docs/concepts/services-networking/network-policies/) defined yet for the Smart City application. Therefore, users are advised to remove the default Smart Edge Open network policies with the following command:
 > ```shell
 > kubectl delete netpol block-all-ingress cdi-upload-proxy-policy
 > ```
 
-From the OpenNESS Controller, attach the physical ethernet interface to be used for dataplane traffic using the `interfaceservice` kubectl plugin by providing the office hostname and the PCI Function ID corresponding to the ethernet interface (the PCI ID below is just a sample and may vary on other setups):
+From the Smart Edge Open Controller, attach the physical ethernet interface to be used for dataplane traffic using the `interfaceservice` kubectl plugin by providing the office hostname and the PCI Function ID corresponding to the ethernet interface (the PCI ID below is just a sample and may vary on other setups):
 ```shell
 kubectl interfaceservice get <officeX_host_name>
 ...
@@ -661,9 +661,9 @@ kubectl interfaceservice get <officeX_host_name>
 
 ## Building Smart City ingredients
 
-   1. Clone the Smart City Reference Pipeline source code from [GitHub](https://github.com/OpenVisualCloud/Smart-City-Sample.git) to the following: 1) Camera simulator machines, 2) OpenNESS Controller machine, and 3) Smart City cloud control plane machine.
+   1. Clone the Smart City Reference Pipeline source code from [GitHub](https://github.com/OpenVisualCloud/Smart-City-Sample.git) to the following: 1) Camera simulator machines, 2) Smart Edge Open Controller machine, and 3) Smart City cloud control plane machine.
 
-   2. Build the Smart City application on all of the machines as explained in [Smart City deployment on OpenNESS](https://github.com/OpenVisualCloud/Smart-City-Sample/tree/openness-k8s/deployment/openness). At least 2 offices (edge nodes) must be installed on OpenNESS.
+   2. Build the Smart City application on all of the machines as explained in [Smart City deployment on Smart Edge Open](https://github.com/OpenVisualCloud/Smart-City-Sample/tree/openness-k8s/deployment/openness). At least 2 offices (edge nodes) must be installed on Smart Edge Open.
 
 ## Running Smart City
 
@@ -675,7 +675,7 @@ kubectl interfaceservice get <officeX_host_name>
       route add -net 10.16.0.0/24 gw 192.168.1.1 dev <office1_interface_name>
       ```
 
-      > **NOTE**: When adding office 2 and so on, change the CIDR (i.e: `192.168.1.0/24`) to the corresponding subnet. Allocated subnets to individual offices can be retrieved by entering the following command in the OpenNESS controller shell:
+      > **NOTE**: When adding office 2 and so on, change the CIDR (i.e: `192.168.1.0/24`) to the corresponding subnet. Allocated subnets to individual offices can be retrieved by entering the following command in the Smart Edge Open controller shell:
       > ```shell
       > kubectl get subnets
       > ```
@@ -704,9 +704,9 @@ kubectl interfaceservice get <officeX_host_name>
        > systemctl stop firewalld
        > ```
 
-       > **NOTE**: Do not stop the firewall on OpenNESS nodes.
+       > **NOTE**: Do not stop the firewall on Smart Edge Open nodes.
 
-   4. On the OpenNESS Controller machine, build and run the Smart City cloud containers:
+   4. On the Smart Edge Open Controller machine, build and run the Smart City cloud containers:
        ```shell
        export CAMERA_HOSTS=192.168.1.10,192.168.2.10
        export CLOUD_HOST=<cloud-control-plane-ip>
@@ -723,15 +723,15 @@ kubectl interfaceservice get <officeX_host_name>
 ## Inter application communication
 The IAC is available via the default overlay network used by Kubernetes - Kube-OVN.
 
-For more information on Kube-OVN, refer to the Kube-OVN support in OpenNESS [documentation](../building-blocks/dataplane/openness-interapp.md#interapp-communication-support-in-openness-network-edge)
+For more information on Kube-OVN, refer to the Kube-OVN support in Smart Edge Open [documentation](../building-blocks/dataplane/smartedge-open-interapp.md#interapp-communication-support-in-smart-edge-open-network-edge)
 
 # Enhanced Platform Awareness
-Enhanced platform awareness (EPA) is supported in OpenNESS via the use of the Kubernetes NFD plugin. This plugin is enabled in OpenNESS for Network Edge by default. Refer to the [NFD whitepaper](../building-blocks/enhanced-platform-awareness/openness-node-feature-discovery.md) for information on how to make your application pods aware of the supported platform capabilities.
+Enhanced platform awareness (EPA) is supported in Smart Edge Open via the use of the Kubernetes NFD plugin. This plugin is enabled in Smart Edge Open for Network Edge by default. Refer to the [NFD whitepaper](../building-blocks/enhanced-platform-awareness/smartedge-open-node-feature-discovery.md) for information on how to make your application pods aware of the supported platform capabilities.
 
-Refer to Building Blocks / Enhanced Platform Awareness section for the list of supported EPA features on OpenNESS network edge.
+Refer to Building Blocks / Enhanced Platform Awareness section for the list of supported EPA features on Smart Edge Open network edge.
 
 # VM support for Network Edge
-Support for VM deployment on OpenNESS for Network Edge is available and enabled by default, where certain configuration and prerequisites may need to be fulfilled to use all capabilities. For information on application deployment in VM, see [VM support in OpenNESS for Network Edge](../applications-onboard/openness-network-edge-vm-support.md) section.
+Support for VM deployment on Smart Edge Open for Network Edge is available and enabled by default, where certain configuration and prerequisites may need to be fulfilled to use all capabilities. For information on application deployment in VM, see [VM support in Smart Edge Open for Network Edge](../applications-onboard/smartedge-open-network-edge-vm-support.md) section.
 
 # Troubleshooting
 This section covers steps for debugging edge applications in Network Edge.
diff --git a/doc/applications-onboard/openness-certsigner.md b/doc/applications-onboard/smartedge-open-certsigner.md
similarity index 96%
rename from doc/applications-onboard/openness-certsigner.md
rename to doc/applications-onboard/smartedge-open-certsigner.md
index 014fb98e..1278f1d1 100644
--- a/doc/applications-onboard/openness-certsigner.md
+++ b/doc/applications-onboard/smartedge-open-certsigner.md
@@ -18,7 +18,7 @@ After that the Certificate Requester saves the certificate and key under `/home/
 
 Application can use the certificate by having a shared volume mounted under `/home/certrequester/certs` in Certificate Requester container and under a requried path in its service container.
 
-Each application needs to perform mutual TLS authentication with the [EAA](openness-eaa.md). To achieve that, the application should trust the CA certificate `root.pem` that is stored in `ca-certrequester` Kubernetes Secret.
+Each application needs to perform mutual TLS authentication with the [EAA](smartedge-open-eaa.md). To achieve that, the application should trust the CA certificate `root.pem` that is stored in `ca-certrequester` Kubernetes Secret.
 
 ### Deployment
 In order to use Certificate Requester the following Kubernetes entities needs to be created:
@@ -53,7 +53,7 @@ In order to use Certificate Requester the following Kubernetes entities needs to
  - *CSR.DNSSANs*: A list of DNS SANs
  - *CSR.IPSANs*: A list of IP SANs
  - *CSR.KeyUsages*: Specifies valid usage contexts for keys, list of elements of type https://godoc.org/k8s.io/api/certificates/v1#KeyUsage
- - *Signer*: Specifies Kubernetes Signer that will handle the CSR. OpenNESS Certificate Signer name should be used: "*openness.org/certsigner*"
+ - *Signer*: Specifies Kubernetes Signer that will handle the CSR. Smart Edge Open Certificate Signer name should be used: "*openness.org/certsigner*"
  - *WaitTimeout*: Specifies how much time the CSR can wait until it's approved before deletion.
 
    Sample config:
diff --git a/doc/applications-onboard/openness-eaa.md b/doc/applications-onboard/smartedge-open-eaa.md
similarity index 70%
rename from doc/applications-onboard/openness-eaa.md
rename to doc/applications-onboard/smartedge-open-eaa.md
index ecb5ebb6..43a41501 100644
--- a/doc/applications-onboard/openness-eaa.md
+++ b/doc/applications-onboard/smartedge-open-eaa.md
@@ -10,8 +10,8 @@ Copyright (c) 2020 Intel Corporation
 #### Edge Application API support
 
 There are two types of applications that can be deployed on the Edge Node:
-- **Producer Application**: The OpenNESS Producer application is an edge compute application that provides services to other applications running on the edge compute platform (location services, mapping services, transcoding services, etc.)
-- **Consumer Application**: The OpenNESS Consumer application is an edge compute application that serves end users traffic directly (CDN App, Augmented Reality App, VR Application, Infotainment Application, etc.). Pre-existing cloud applications that do not intend to call the EAA APIs but would like to serve the users (without any changes to the implementation) on the edge also fall into this category.
+- **Producer Application**: The Smart Edge Open Producer application is an edge compute application that provides services to other applications running on the edge compute platform (location services, mapping services, transcoding services, etc.)
+- **Consumer Application**: The Smart Edge Open Consumer application is an edge compute application that serves end users traffic directly (CDN App, Augmented Reality App, VR Application, Infotainment Application, etc.). Pre-existing cloud applications that do not intend to call the EAA APIs but would like to serve the users (without any changes to the implementation) on the edge also fall into this category.
 
 API endpoint for edge applications is implemented in the EAA (Edge Application Agent) microservice and is implemented in Go lang. APIs are classified into:
 
@@ -26,14 +26,14 @@ API endpoint for edge applications is implemented in the EAA (Edge Application A
 
 ### Edge Application APIs
 Edge Application APIs are implemented by the EAA. Edge Application APIs are important APIs for Edge application developers. EAA APIs are implemented as HTTPS REST. There are two types of use cases:
-1. **Porting an existing Public/Private Cloud application to the edge compute based on OpenNESS**: This is a scenario where a customer wants to run existing apps in the public cloud on OpenNESS edge without calling any APIs or changing code. In this case, the only requirement is for an Application image (VM/Container) should be uploaded to the controller and provisioned on the Edge Node using OpenNESS Controller. In this case, the Application cannot call any EAA APIs and consume services on the edge compute. It just services end-user traffic.
+1. **Porting an existing Public/Private Cloud application to the edge compute based on Smart Edge Open**: This is a scenario where a customer wants to run existing apps in the public cloud on Smart Edge Open edge without calling any APIs or changing code. In this case, the only requirement is for an Application image (VM/Container) should be uploaded to the controller and provisioned on the Edge Node using Smart Edge Open Controller. In this case, the Application cannot call any EAA APIs and consume services on the edge compute. It just services end-user traffic.
 3. **Native Edge compute Application calling EAA APIs**: This is a scenario where a customer wants to develop Edge compute applications that take advantage of Edge compute services resulting in a more tactile application that responds to the changing user, network, or resource scenarios.
 
-OpenNESS supports the deployment of both types of applications mentioned above. The Edge Application Agent is a service that runs on the Edge Node and operates as a discovery service and basic message bus between applications via `pubsub`. The connectivity and discoverability of applications by one another is governed by an entitlement system and is controlled by policies set with the OpenNESS Controller. The entitlement system is still in development but currently allows all applications on the executing Edge Node to discover one another as well as publish and subscribe to all notifications. The Figure below provides the sequence diagram of the supported APIs for the application.
+Smart Edge Open supports the deployment of both types of applications mentioned above. The Edge Application Agent is a service that runs on the Edge Node and operates as a discovery service and basic message bus between applications via `pubsub`. The connectivity and discoverability of applications by one another is governed by an entitlement system and is controlled by policies set with the Smart Edge Open Controller. The entitlement system is still in development but currently allows all applications on the executing Edge Node to discover one another as well as publish and subscribe to all notifications. The Figure below provides the sequence diagram of the supported APIs for the application.
 
 More details about the APIs can be found here [Edge Application APIs](https://www.openness.org/api-documentation/?api=eaa)
 
-![Edge Application APIs](eaa-images/openness-eaa.png)
+![Edge Application APIs](eaa-images/smartedge-open-eaa.png)
 
 _Figure - Edge Application API Sequence Diagram_
 
@@ -41,4 +41,4 @@ _Figure - Edge Application API Sequence Diagram_
 
 Connection to the EAA can be established after performing mutual TLS authentication. To achieve that the application needs to generate its certificate using Certificate Signer and should trust the CA certificate `root.pem` that is stored in `ca-certrequester` Kubernetes Secret.
 
-The details can be found on the [Certificate Signer page](openness-certsigner.md).
+The details can be found on the [Certificate Signer page](smartedge-open-certsigner.md).
diff --git a/doc/applications-onboard/openness-edgedns.md b/doc/applications-onboard/smartedge-open-edgedns.md
similarity index 79%
rename from doc/applications-onboard/openness-edgedns.md
rename to doc/applications-onboard/smartedge-open-edgedns.md
index 84312063..caebe3d2 100644
--- a/doc/applications-onboard/openness-edgedns.md
+++ b/doc/applications-onboard/smartedge-open-edgedns.md
@@ -12,15 +12,15 @@ Copyright (c) 2019 Intel Corporation
 The edge platform must provide access to DNS. The edge platform receives the application DNS rules from the controller. This is specified in the ETSI Multi-access Edge Computing (MEC). From a 5G edge deployment perspective, the Primary DNS (priDns) and Secondary DNS (secDns) needs to be configured which is going to be consumed by the SMF. 
 <!-- fix the last sentence above. Confusing. -->
 
-OpenNESS supports DNS microservice to address these DNS requirements and also DNS service for edge applications and network functions. 
+Smart Edge Open supports DNS microservice to address these DNS requirements and also DNS service for edge applications and network functions. 
 
-![DNS support on OpenNESS overview](dns-images/dns1.png)
+![DNS support on Smart Edge Open overview](dns-images/dns1.png)
 
-_Figure - DNS support on OpenNESS overview_
+_Figure - DNS support on Smart Edge Open overview_
 
->**NOTE**: Secondary DNS service is out of the scope of OpenNESS and is only used for DNS forwarding.
+>**NOTE**: Secondary DNS service is out of the scope of Smart Edge Open and is only used for DNS forwarding.
 
-EdgeDNS is a functionality to provide the Domain Name System (DNS) Server with a possibility to be controlled by its CLI. EdgeDNS Server listens for requests from a client's CLI. After receiving a CLI request, a function handling the request adds or removes the RULE inside of the EdgeDNS database. EdgeDNS supports only type A records for Set/Delete Fully Qualified Domain Names (FQDN) and the current forwarder is set to 8.8.8.8 (set in docker-compose.yml and openness.yaml). Network Edge mode provides EdgeDNS as a service, which is an application running in a K8s pod on each node of the OpenNESS K8s cluster. It allows users to add and remove DNS entries of the node directly from K8s control plane using kubectl plugin.
+EdgeDNS is a functionality to provide the Domain Name System (DNS) Server with a possibility to be controlled by its CLI. EdgeDNS Server listens for requests from a client's CLI. After receiving a CLI request, a function handling the request adds or removes the RULE inside of the EdgeDNS database. EdgeDNS supports only type A records for Set/Delete Fully Qualified Domain Names (FQDN) and the current forwarder is set to 8.8.8.8 (set in docker-compose.yml and smartedge-open.yaml). Network Edge mode provides EdgeDNS as a service, which is an application running in a K8s pod on each node of the Smart Edge Open K8s cluster. It allows users to add and remove DNS entries of the node directly from K8s control plane using kubectl plugin.
 
 ## Usage
 
diff --git a/doc/applications-onboard/openness-interface-service.md b/doc/applications-onboard/smartedge-open-interface-service.md
similarity index 83%
rename from doc/applications-onboard/openness-interface-service.md
rename to doc/applications-onboard/smartedge-open-interface-service.md
index f0a2b1e1..0790ab1d 100644
--- a/doc/applications-onboard/openness-interface-service.md
+++ b/doc/applications-onboard/smartedge-open-interface-service.md
@@ -3,7 +3,7 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019-2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# OpenNESS Interface Service
+# Smart Edge Open Interface Service
 - [Overview](#overview)
 - [Traffic from the external host](#traffic-from-the-external-host)
 - [Usage](#usage)
@@ -19,13 +19,13 @@ Copyright (c) 2019-2020 Intel Corporation
 
 ## Overview
 
-Interface service is an application running in the Kubernetes\* pod on each node of the OpenNESS Kubernetes cluster. It allows users to attach additional network interfaces of the node to the provided OVS bridge, enabling external traffic scenarios for applications deployed in the Kubernetes\* pods. Services on each node can be controlled from the control plane using kubectl plugin.
+Interface service is an application running in the Kubernetes\* pod on each node of the Smart Edge Open Kubernetes cluster. It allows users to attach additional network interfaces of the node to the provided OVS bridge, enabling external traffic scenarios for applications deployed in the Kubernetes\* pods. Services on each node can be controlled from the control plane using kubectl plugin.
 
 Interface service can attach both kernel and user space (DPDK) network interfaces to the appropriate OVS bridges. To perform that operation Kube-OVN needs to be set as main CNI.
 
 ## Traffic from the external host
 
-A machine (client-sim) that is physically connected to the OpenNESS edge node over a cable can communicate to the pods in the Kubernetes cluster when the physical network interface (through which the cable is attached) is bridged over to the Kubernetes cluster subnet. This is done by providing the PCI ID or MAC address to the `interfaceservice` kubectl plugin.
+A machine (client-sim) that is physically connected to the Smart Edge Open edge node over a cable can communicate to the pods in the Kubernetes cluster when the physical network interface (through which the cable is attached) is bridged over to the Kubernetes cluster subnet. This is done by providing the PCI ID or MAC address to the `interfaceservice` kubectl plugin.
 
 The machine that is connected to the edge node must be configured as described below to allow the traffic originating from the client-sim (`192.168.1.0/24` subnet) to be routed over to the Kubernetes cluster (`10.16.0.0/16` subnet).
 
@@ -35,7 +35,7 @@ Update the physical Ethernet interface with an IP from the `192.168.1.0/24` subn
   route add -net 10.16.0.0/16 gw 192.168.1.1 dev eth1
 ```
 
-> **NOTE**: The default OpenNESS network policy applies to pods in a `default` namespace and blocks all ingress traffic. Refer to [Kubernetes NetworkPolicies](https://github.com/open-ness/specs/blob/master/doc/applications-onboard/network-edge-applications-onboarding.md#applying-kubernetes-network-policies) for an example policy allowing ingress traffic from the `192.168.1.0/24` subnet on a specific port.
+> **NOTE**: The default Smart Edge Open network policy applies to pods in a `default` namespace and blocks all ingress traffic. Refer to [Kubernetes NetworkPolicies](https://github.com/smart-edge-open/specs/blob/master/doc/applications-onboard/network-edge-applications-onboarding.md#applying-kubernetes-network-policies) for an example policy allowing ingress traffic from the `192.168.1.0/24` subnet on a specific port.
 
 > **NOTE**: The subnet `192.168.1.0/24` is allocated by the Ansible\* playbook to the physical interface, which is attached to the first edge node. The second edge node joined to the cluster is allocated to the next subnet `192.168.2.0/24` and so on.
 
@@ -78,7 +78,7 @@ Currently, interface service supports the following values of the `driver` param
 
 ## Userspace (DPDK) bridge
 
-The default DPDK-enabled bridge `br-userspace` is only available if OpenNESS is deployed with support for [Userspace CNI](https://github.com/open-ness/specs/blob/master/doc/building-blocks/dataplane/openness-userspace-cni.md) and at least one pod was deployed using the Userspace CNI. You can check if the `br-userspace` bridge exists by running the following command on your node:
+The default DPDK-enabled bridge `br-userspace` is only available if Smart Edge Open is deployed with support for [Userspace CNI](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/dataplane/smartedge-open-userspace-cni.md) and at least one pod was deployed using the Userspace CNI. You can check if the `br-userspace` bridge exists by running the following command on your node:
 
 ```shell
 ovs-vsctl list-br
diff --git a/doc/applications-onboard/openness-network-edge-vm-support.md b/doc/applications-onboard/smartedge-open-network-edge-vm-support.md
similarity index 90%
rename from doc/applications-onboard/openness-network-edge-vm-support.md
rename to doc/applications-onboard/smartedge-open-network-edge-vm-support.md
index b02194a4..b8104c70 100644
--- a/doc/applications-onboard/openness-network-edge-vm-support.md
+++ b/doc/applications-onboard/smartedge-open-network-edge-vm-support.md
@@ -3,7 +3,7 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# VM support in OpenNESS for Network Edge - Setup, deployment, and management considerations
+# VM support in Smart Edge Open for Network Edge - Setup, deployment, and management considerations
 - [Overview](#overview)
 - [KubeVirt](#kubevirt)
 - [Stateless vs Stateful VMs](#stateless-vs-stateful-vms)
@@ -11,7 +11,7 @@ Copyright (c) 2020 Intel Corporation
   - [VMs with persistent Local Storage](#vms-with-persistent-local-storage)
   - [VMs with Cloud Storage](#vms-with-cloud-storage)
   - [Creating Docker image for stateless VM](#creating-docker-image-for-stateless-vm)
-- [Enabling in OpenNESS](#enabling-in-openness)
+- [Enabling in Smart Edge Open](#enabling-in-smart-edge-open)
 - [VM deployment](#vm-deployment)
   - [Stateless VM deployment](#stateless-vm-deployment)
   - [Stateful VM deployment](#stateful-vm-deployment)
@@ -29,10 +29,10 @@ Copyright (c) 2020 Intel Corporation
 
 ## Overview
 
-This document explores the support of virtual machine (VM) deployment in OpenNESS for Network Edge. Covered items include: 
+This document explores the support of virtual machine (VM) deployment in Smart Edge Open for Network Edge. Covered items include: 
 * design considerations and currently available solutions 
 * limitations
-* configuration of the environment for OpenNESS
+* configuration of the environment for Smart Edge Open
 * deployment of VMs with various requirements for storage and SRIOV support
  * troubleshooting
 
@@ -40,7 +40,7 @@ When designing support of VM deployment for Network Edge, a key consideration wa
 
 Virtlet VMs are treated as ordinary pods and can be natively controlled from `kubectl` but the deployment requires the introduction of an additional Container Runtime Interface (CRI) and CRI proxy into the cluster. In comparison, KubeVirt VMs are enabled by extending the functionality of K8s via Custom Resource Definitions (CRDs) and easy to deploy KubeVirt agents and controllers. No CRI proxy introduction is necessary in the cluster.
 
-Due to easy deployment and no impact on the existing OpenNESS architecture, KubeVirt is the chosen solution in OpenNESS.
+Due to easy deployment and no impact on the existing Smart Edge Open architecture, KubeVirt is the chosen solution in Smart Edge Open.
 
 ## KubeVirt
 
@@ -51,19 +51,19 @@ KubeVirt is an open-source project extending K8s with VM support via the previou
 The types of VM deployments can be split into two categories based on the storage required by the workload. 
 * **Stateless** VMs are backed by ephemeral storage, meaning that the data will disappear with VM restart/reboot. 
 * **Stateful** VMs are backed by persistent storage, meaning that data will persist after VM restart/reboot. 
-The type of storage required will be determined based on the use case. In OpenNESS, support for both types of VM is available with the aid of KubeVirt.
+The type of storage required will be determined based on the use case. In Smart Edge Open, support for both types of VM is available with the aid of KubeVirt.
 
 ### VMs with ephemeral storage
-These are VMs with ephemeral storage, such as ContainerDisk storage that would be similarly deployed to ordinary container pods. The data contained in the VM would be erased on each VM deletion/restart. Thus, it is suitable for stateless applications running inside the pods. A better fit for such an application would be running the workload in a container pod but for various reasons (e.g., a legacy application), users may not want to containerize their workload. From an K8s/OpenNESS perspective, the advantage of this deployment is no additional storage configuration; users only need to have a cluster with KubeVirt deployed and a dockerized version of a VM image to spin up the VM.
+These are VMs with ephemeral storage, such as ContainerDisk storage that would be similarly deployed to ordinary container pods. The data contained in the VM would be erased on each VM deletion/restart. Thus, it is suitable for stateless applications running inside the pods. A better fit for such an application would be running the workload in a container pod but for various reasons (e.g., a legacy application), users may not want to containerize their workload. From an K8s/Smart Edge Open perspective, the advantage of this deployment is no additional storage configuration; users only need to have a cluster with KubeVirt deployed and a dockerized version of a VM image to spin up the VM.
 
 ### VMs with persistent Local Storage
 Some VMs require persistent storage, and the data for this kind of VM stays persistent between restarts of the VM. 
 In the case of local storage, Kubernetes provides a ‘local volume plugin' which can be used to define a Persistent Volume (PV). 
-In the case of the local volume plugin, there is no support for dynamic creation (k8s 1.17.0) and the PVs must be created by a user before a Persistent Volume Claim (PVC) can be claimed by the pod/VM. This manual creation of PVs must be taken into consideration for an OpenNESS deployment as a PV will need to be created per each VM per each node, as the storage is local to the Edge Node. 
+In the case of the local volume plugin, there is no support for dynamic creation (k8s 1.17.0) and the PVs must be created by a user before a Persistent Volume Claim (PVC) can be claimed by the pod/VM. This manual creation of PVs must be taken into consideration for an Smart Edge Open deployment as a PV will need to be created per each VM per each node, as the storage is local to the Edge Node. 
 In the case of persistent storage, the VM image must be loaded to the PVC, this can be done via the use of KubeVirt's Container Data Importer (CDI). This kind of storage is meant for use with stateful workloads, and being local to the node is suitable for Edge deployments.
 
 ### VMs with Cloud Storage
-Support for persistent storage via Cloud Storage providers is possible in K8s but it is currently not supported in OpenNESS. There are no plans to support it but this can change according to demand.
+Support for persistent storage via Cloud Storage providers is possible in K8s but it is currently not supported in Smart Edge Open. There are no plans to support it but this can change according to demand.
 
 ### Creating Docker image for stateless VM
 To create a Docker\* image for a stateless VM, the VM image needs to be wrapped inside the Docker image. To do this users need to create a `Dockerfile` and place the VM image in the same directory and then build the Docker image per the example below:
@@ -75,7 +75,7 @@ ADD CentOS-7-x86_64-GenericCloud.qcow2 /disk/
 ```shell
 docker build -t centosimage:1.0 .
 ```
-## Enabling in OpenNESS
+## Enabling in Smart Edge Open
 
 The KubeVirt role responsible for bringing up KubeVirt components is enabled by default in the Converged Edge Experience Kits via Ansible\* automation. In this default state, it does not support SRIOV in a VM and additional steps are required to enable it. The following is a complete list of steps to bring up all components related to VM support in Network Edge. VM support also requires Virtualization and VT-d to be enabled in the BIOS of the Edge Node.
 
@@ -133,7 +133,7 @@ The KubeVirt role responsible for bringing up KubeVirt components is enabled by
 
 ## VM deployment
 Provided below are sample deployment instructions for different types of VMs.
-Please use sample `.yaml` specification files provided in the OpenNESS Edge Controller directory, [edgeservices/edgecontroller/kubevirt/examples/](https://github.com/open-ness/edgeservices/tree/master/edgecontroller/kubevirt/examples), to deploy the workloads. Some of the files require modification to suit the environment they will be deployed in. Specific instructions on modifications are provided in the following steps:
+Please use sample `.yaml` specification files provided in the Smart Edge Open Edge Controller directory, [edgeservices/edgecontroller/kubevirt/examples/](https://github.com/smart-edge-open/edgeservices/tree/master/edgecontroller/kubevirt/examples), to deploy the workloads. Some of the files require modification to suit the environment they will be deployed in. Specific instructions on modifications are provided in the following steps:
 
 ### Stateless VM deployment
 To deploy a sample stateless VM with containerDisk storage:
@@ -155,7 +155,7 @@ To deploy a sample stateless VM with containerDisk storage:
       ```shell
       [root@controller ~]# kubectl virt console cirros-stateless-vm
       ```
-  5. Check that IP address of OpenNESS/K8s overlay network is available in the VM:
+  5. Check that IP address of Smart Edge Open/K8s overlay network is available in the VM:
       ```shell
       [root@vm ~]# ip addr
       ```
@@ -165,7 +165,7 @@ To deploy a sample stateful VM with persistent storage and additionally use a Ge
 
 >**NOTE**: Each stateful VM with a new Persistent Volume Claim (PVC) requires a new Persistent Volume (PV) to be created. See more in the [limitations section](#limitations). Also, CDI needs two PVs when creating a PVC and loading a VM image from the qcow2 file: one PV for the actual PVC to be created and one PV to translate the qcow2 image to raw input.
 
->**NOTE**: An issue appears when the CDI upload pod is deployed with Calico CNI, the deployed pods readiness probe fails and pod is never in ready state. It is advised that the user uses other CNI such as Calico CNI when using CDI with OpenNESS.
+>**NOTE**: An issue appears when the CDI upload pod is deployed with Calico CNI, the deployed pods readiness probe fails and pod is never in ready state. It is advised that the user uses other CNI such as Calico CNI when using CDI with Smart Edge Open.
 
   1. Create a persistent volume for the VM:
 
@@ -364,11 +364,11 @@ Complete the following steps to create a snapshot:
 
 ### Cloud Storage
 
-Currently, there is no support for cloud storage in OpenNESS.
+Currently, there is no support for cloud storage in Smart Edge Open.
 
 ### Storage Orchestration and PV/PVC management
 
-Currently, Network Edge OpenNESS has no mechanism to manage storage. The assumption is made that the default HDD/SSD of the Edge Node is used for storage. Additionally, various methods for optimizing storage (e.g., using various file system types) for performance are out of scope for OpenNESS. When using K8s with local persistent volumes in Network Edge deployment, the user must create a directory per each PV, which will be used to store the VMs' virtual disk. The creation of directories to store PV is automated from OpenNESS but the creation of the PV itself and keeping track of which PV corresponds to which VM is currently the user’s responsibility. This is due to the local volume plugin enabling local storage in K8s, which does not provide dynamic PV creation when a PVC claim is made. A consideration of how to automate and simplify PV management for the user will be made in the future. An evaluation of currently available solutions is needed.
+Currently, Network Edge Smart Edge Open has no mechanism to manage storage. The assumption is made that the default HDD/SSD of the Edge Node is used for storage. Additionally, various methods for optimizing storage (e.g., using various file system types) for performance are out of scope for Smart Edge Open. When using K8s with local persistent volumes in Network Edge deployment, the user must create a directory per each PV, which will be used to store the VMs' virtual disk. The creation of directories to store PV is automated from Smart Edge Open but the creation of the PV itself and keeping track of which PV corresponds to which VM is currently the user’s responsibility. This is due to the local volume plugin enabling local storage in K8s, which does not provide dynamic PV creation when a PVC claim is made. A consideration of how to automate and simplify PV management for the user will be made in the future. An evaluation of currently available solutions is needed.
 
 ### Snapshot Creation
 
diff --git a/doc/applications-onboard/using-openness-cnca-images/af_pfd_transaction_home.png b/doc/applications-onboard/using-smartedge-open-cnca-images/af_pfd_transaction_home.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/af_pfd_transaction_home.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/af_pfd_transaction_home.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/af_subscription_create.png b/doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_create.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/af_subscription_create.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_create.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/af_subscription_create_part1.png b/doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_create_part1.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/af_subscription_create_part1.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_create_part1.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/af_subscription_create_part2.png b/doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_create_part2.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/af_subscription_create_part2.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_create_part2.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/af_subscription_create_part3.png b/doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_create_part3.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/af_subscription_create_part3.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_create_part3.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/af_subscription_delete.png b/doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_delete.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/af_subscription_delete.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_delete.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/af_subscription_display.png b/doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_display.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/af_subscription_display.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_display.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/af_subscription_display_home.png b/doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_display_home.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/af_subscription_display_home.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_display_home.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/af_subscription_edit.png b/doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_edit.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/af_subscription_edit.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_edit.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/af_subscription_patch.png b/doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_patch.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/af_subscription_patch.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/af_subscription_patch.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/ngc_af_service_config_log.png b/doc/applications-onboard/using-smartedge-open-cnca-images/ngc_af_service_config_log.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/ngc_af_service_config_log.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/ngc_af_service_config_log.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/ngc_homepage.png b/doc/applications-onboard/using-smartedge-open-cnca-images/ngc_homepage.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/ngc_homepage.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/ngc_homepage.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/ngc_pods_list_output.png b/doc/applications-onboard/using-smartedge-open-cnca-images/ngc_pods_list_output.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/ngc_pods_list_output.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/ngc_pods_list_output.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/ngc_services_list_output.png b/doc/applications-onboard/using-smartedge-open-cnca-images/ngc_services_list_output.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/ngc_services_list_output.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/ngc_services_list_output.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/oam_services_create.png b/doc/applications-onboard/using-smartedge-open-cnca-images/oam_services_create.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/oam_services_create.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/oam_services_create.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/oam_services_delete.png b/doc/applications-onboard/using-smartedge-open-cnca-images/oam_services_delete.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/oam_services_delete.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/oam_services_delete.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/oam_services_display.png b/doc/applications-onboard/using-smartedge-open-cnca-images/oam_services_display.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/oam_services_display.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/oam_services_display.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/oam_services_edit.png b/doc/applications-onboard/using-smartedge-open-cnca-images/oam_services_edit.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/oam_services_edit.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/oam_services_edit.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/oam_services_home.png b/doc/applications-onboard/using-smartedge-open-cnca-images/oam_services_home.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/oam_services_home.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/oam_services_home.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/pfd_transaction_create.png b/doc/applications-onboard/using-smartedge-open-cnca-images/pfd_transaction_create.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/pfd_transaction_create.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/pfd_transaction_create.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/pfd_transaction_delete.png b/doc/applications-onboard/using-smartedge-open-cnca-images/pfd_transaction_delete.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/pfd_transaction_delete.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/pfd_transaction_delete.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/pfd_transaction_delete_appID.png b/doc/applications-onboard/using-smartedge-open-cnca-images/pfd_transaction_delete_appID.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/pfd_transaction_delete_appID.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/pfd_transaction_delete_appID.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/pfd_transaction_display.png b/doc/applications-onboard/using-smartedge-open-cnca-images/pfd_transaction_display.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/pfd_transaction_display.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/pfd_transaction_display.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/pfd_transaction_edit.png b/doc/applications-onboard/using-smartedge-open-cnca-images/pfd_transaction_edit.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/pfd_transaction_edit.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/pfd_transaction_edit.png
diff --git a/doc/applications-onboard/using-openness-cnca-images/pfd_transaction_edit_appID.png b/doc/applications-onboard/using-smartedge-open-cnca-images/pfd_transaction_edit_appID.png
similarity index 100%
rename from doc/applications-onboard/using-openness-cnca-images/pfd_transaction_edit_appID.png
rename to doc/applications-onboard/using-smartedge-open-cnca-images/pfd_transaction_edit_appID.png
diff --git a/doc/applications-onboard/using-openness-cnca.md b/doc/applications-onboard/using-smartedge-open-cnca.md
similarity index 89%
rename from doc/applications-onboard/using-openness-cnca.md
rename to doc/applications-onboard/using-smartedge-open-cnca.md
index 0ece630d..6d7d0863 100644
--- a/doc/applications-onboard/using-openness-cnca.md
+++ b/doc/applications-onboard/using-smartedge-open-cnca.md
@@ -105,35 +105,35 @@ policy:
 
 # 5G NGC components bring up and Configuration using CNCA
 
-OpenNESS provides ansible scripts for setting up NGC components for two scenarios. Each of the scenarios is supported by a separate role in the Converged Edge Experience Kits:
+Smart Edge Open provides ansible scripts for setting up NGC components for two scenarios. Each of the scenarios is supported by a separate role in the Converged Edge Experience Kits:
 
 1. Role "ngc_test"
-  This role brings up the 5g OpenNESS setup in the loopback mode for testing and demonstrating its usability. This scenario is currently the default 5G OpenNESS scenario. The ansible scripts that are part of "ngc_test" role build, configure and start AF, NEF and OAM in the Network Edge. Within this role, AF, NEF and OAM are set up on the controller node.  Description of the configuration and setup of the NGC components provided in the next sections of this document refers to ngc_test role. The NGC componetns set up within ngc_test role can be fully integrated and tested with provided Kubectl plugin or CNCA UI.
+  This role brings up the 5g Smart Edge Open setup in the loopback mode for testing and demonstrating its usability. This scenario is currently the default 5G Smart Edge Open scenario. The ansible scripts that are part of "ngc_test" role build, configure and start AF, NEF and OAM in the Network Edge. Within this role, AF, NEF and OAM are set up on the controller node.  Description of the configuration and setup of the NGC components provided in the next sections of this document refers to ngc_test role. The NGC componetns set up within ngc_test role can be fully integrated and tested with provided Kubectl plugin or CNCA UI.
 
 2. Role "ngc"
-  This role brings up 5g OpenNESS components - AF and NEF - to present the real deployment scenario, where the components can be further integrated with the real 5G core network. The ansible scripts that are part of this role build, configure and start AF and NEF components on separate nodes in Network Edg. The ansible scripts place AF again on the controller node, whereas NEF is placed on a node. Similar functionality will be added for OAM component in the future release. Currently, integration with CNCA UI and Kubectl is not complete due to missing OAM component - the services can not be created and accessed. In CNCA UI the "services" web page does not show any content. The user should proceed to "subscriptions" web page to view and modify subscriptions.
+  This role brings up 5g Smart Edge Open components - AF and NEF - to present the real deployment scenario, where the components can be further integrated with the real 5G core network. The ansible scripts that are part of this role build, configure and start AF and NEF components on separate nodes in Network Edg. The ansible scripts place AF again on the controller node, whereas NEF is placed on a node. Similar functionality will be added for OAM component in the future release. Currently, integration with CNCA UI and Kubectl is not complete due to missing OAM component - the services can not be created and accessed. In CNCA UI the "services" web page does not show any content. The user should proceed to "subscriptions" web page to view and modify subscriptions.
 
 ## Network Edge mode
 
 ### Bring-up of NGC components in Network Edge mode
 
 1. If the Edge controller is not yet deployed through converged-edge-experience-kits then:
-   Enable the role for ngc by changing `ne_ngc_test_enable` variable to `true` in `inventory/default/group_vars/all/10-default.yml` before running `deploy.py` as described in [OpenNESS Network Edge: Controller and Edge node setup](../getting-started/openness-cluster-setup.md) document,  **otherwise skip this step.**
+   Enable the role for ngc by changing `ne_ngc_test_enable` variable to `true` in `inventory/default/group_vars/all/10-default.yml` before running `deploy.py` as described in [Smart Edge Open Network Edge: Controller and Edge node setup](../getting-started/smartedge-open-cluster-setup.md) document,  **otherwise skip this step.**
 
 2. If Edge-controller is already deployed (but without enabling ngc role) and at a later stage you want to enable NGC components on edge-controller then,
-  Enable the role for ngc by changing `ne_ngc_test_enable` variable to `true` in `inventory/default/group_vars/all/10-default.yml` and then re-run `deploy.py` with `limit` set to `controller_group` in `inventory.yml` (define only one cluster on which the role should be enabled) as described in [OpenNESS Network Edge: Controller and Edge node setup](../getting-started/openness-cluster-setup.md) document.
+  Enable the role for ngc by changing `ne_ngc_test_enable` variable to `true` in `inventory/default/group_vars/all/10-default.yml` and then re-run `deploy.py` with `limit` set to `controller_group` in `inventory.yml` (define only one cluster on which the role should be enabled) as described in [Smart Edge Open Network Edge: Controller and Edge node setup](../getting-started/smartedge-open-cluster-setup.md) document.
 
     **NOTE:**
-    In addition to the OpenNESS controller bringup, by enabling the ngc rule the playbook scripts performs:  Clone epcforedge repo from github, builds AF, NEF and OAM micro services, generates certificate files, creates docker images and starts PODs.
+    In addition to the Smart Edge Open controller bringup, by enabling the ngc rule the playbook scripts performs:  Clone epcforedge repo from github, builds AF, NEF and OAM micro services, generates certificate files, creates docker images and starts PODs.
 
 3. On successful start of AF, NEF and OAM PODs, status of PODS and Services can verified using the below commands:
    - `kubectl get pods --all-namespaces`
   expected out as below:
-  ![NGC list of PODS](using-openness-cnca-images/ngc_pods_list_output.png)
+  ![NGC list of PODS](using-smartedge-open-cnca-images/ngc_pods_list_output.png)
 
    - `kubectl get services--all-namespaces`
     expected out as below:
-    ![NGC list of PODS](using-openness-cnca-images/ngc_services_list_output.png)
+    ![NGC list of PODS](using-smartedge-open-cnca-images/ngc_services_list_output.png)
 
     *NOTE: In general, below steps #4 and #5 are not needed. If user wants to change the hostname/ip-address parameters for AF/NEF/OAM then #4 and #5 will provide the guidance.*
 
@@ -148,7 +148,7 @@ OpenNESS provides ansible scripts for setting up NGC components for two scenario
   Successful restart of AF with the updated config can be observed through AF container logs. Run the below command to get AF container logs:
   `kubectl logs af --namespace=ngc af-container`
   Sample output of the AF container logs with updated config may appear as:
-![NGC list of PODS](using-openness-cnca-images/ngc_af_service_config_log.png)
+![NGC list of PODS](using-smartedge-open-cnca-images/ngc_af_service_config_log.png)
 
 5. To update OAM configuration and restart OAM micro service:
    * Open the file `/opt/openness/configs/ngc/oam.json` and modify the below parameters.
@@ -159,17 +159,17 @@ OpenNESS provides ansible scripts for setting up NGC components for two scenario
   Successful restart of OAM with the updated config can be observed through OAM container logs. Run the below command to get logs:
   `kubectl logs oam --namespace=ngc oam-container`
 
->**NOTE**: In case of ngc-test rule/configuration, NEF and OAM PODs will run in OpenNESS-Controller/Kubernetes-Control-Plane node for testing purpose. In a real implementation, if NEF and OAM are being used, these two services will run on the 5G Core network servers either in a POD or a standalone application on the host depending on 5G Core server environment*
+>**NOTE**: In case of ngc-test rule/configuration, NEF and OAM PODs will run in Smart Edge Open-Controller/Kubernetes-Control-Plane node for testing purpose. In a real implementation, if NEF and OAM are being used, these two services will run on the 5G Core network servers either in a POD or a standalone application on the host depending on 5G Core server environment*
 
 ### Configuring in Network Edge mode
 
 For Network Edge mode, the CNCA provides a kubectl plugin to configure the 5G Core network. Kubernetes adopted plugin concepts to extend its functionality. The `kube-cnca` plugin executes CNCA related functions within the Kubernetes ecosystem. The plugin performs remote callouts against NGC OAM and AF microservice on the controller itself.
 
-The `kube-cnca` plugin is installed automatically on the control plane during the installation phase of the [Converged Edge Experience Kits](https://github.com/open-ness/specs/blob/master/doc/getting-started/openness-cluster-setup.md)
+The `kube-cnca` plugin is installed automatically on the control plane during the installation phase of the [Converged Edge Experience Kits](https://github.com/smart-edge-open/specs/blob/master/doc/getting-started/smartedge-open-cluster-setup.md)
 
 #### Edge Node services operations with 5G Core (through OAM interface)
 
->**NOTE**: Registration of the OpenNESS Controller's AF instance with the 5G core must be performed manually (or through any other interface) exposed by the 5G Core.  OAM capabilities will be enhanced in future releases to support this. The current version of OAM supports only one instance of the OpenNESS Controller to communicate.
+>**NOTE**: Registration of the Smart Edge Open Controller's AF instance with the 5G core must be performed manually (or through any other interface) exposed by the 5G Core.  OAM capabilities will be enhanced in future releases to support this. The current version of OAM supports only one instance of the Smart Edge Open Controller to communicate.
 
 ##### Registration of UPF services associated with Edge-node with 5G Core
 
diff --git a/doc/applications/app-guide/openness_apps.png b/doc/applications/app-guide/smartedge-open_apps.png
similarity index 100%
rename from doc/applications/app-guide/openness_apps.png
rename to doc/applications/app-guide/smartedge-open_apps.png
diff --git a/doc/applications/app-guide/openness_cloudadapter.png b/doc/applications/app-guide/smartedge-open_cloudadapter.png
similarity index 100%
rename from doc/applications/app-guide/openness_cloudadapter.png
rename to doc/applications/app-guide/smartedge-open_cloudadapter.png
diff --git a/doc/applications/app-guide/openness_openvinoexecflow.png b/doc/applications/app-guide/smartedge-open_openvinoexecflow.png
similarity index 100%
rename from doc/applications/app-guide/openness_openvinoexecflow.png
rename to doc/applications/app-guide/smartedge-open_openvinoexecflow.png
diff --git a/doc/applications/index.html b/doc/applications/index.html
index f1499d27..e013c887 100644
--- a/doc/applications/index.html
+++ b/doc/applications/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
-window.location = "openness_appguide"
+window.location = "smartedge-open_appguide"
 </script>
diff --git a/doc/applications/openness_appguide.md b/doc/applications/smartedge-open_appguide.md
similarity index 65%
rename from doc/applications/openness_appguide.md
rename to doc/applications/smartedge-open_appguide.md
index 66b14e04..625b8f68 100644
--- a/doc/applications/openness_appguide.md
+++ b/doc/applications/smartedge-open_appguide.md
@@ -3,9 +3,9 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019 Intel Corporation
 ```
 <!-- omit in toc -->
-# OpenNESS Application Development and Porting Guide
+# Smart Edge Open Application Development and Porting Guide
 - [Introduction](#introduction)
-- [OpenNESS Edge Node Applications](#openness-edge-node-applications)
+- [Smart Edge Open Edge Node Applications](#smart-edge-open-edge-node-applications)
   - [Producer Application](#producer-application)
   - [Consumer Application](#consumer-application)
   - [Example of Producer and Consumer Applications](#example-of-producer-and-consumer-applications)
@@ -15,61 +15,61 @@ Copyright (c) 2019 Intel Corporation
   - [Cloud Adapter Edge compute Application](#cloud-adapter-edge-compute-application)
 - [Application On-boarding](#application-on-boarding)
   - [Authentication](#authentication)
-  - [OpenNESS-aware Applications](#openness-aware-applications)
+  - [Smart Edge Open-aware Applications](#smart-edge-open-aware-applications)
     - [Service Activation](#service-activation)
     - [Service Discovery and Subscription](#service-discovery-and-subscription)
     - [Service Notifications](#service-notifications)
-  - [OpenNESS-agnostic Applications](#openness-agnostic-applications)
-  - [Make Legacy Applications OpenNESS-aware](#make-legacy-applications-openness-aware)
+  - [Smart Edge Open-agnostic Applications](#smart-edge-open-agnostic-applications)
+  - [Make Legacy Applications Smart Edge Open-aware](#make-legacy-applications-smart-edge-open-aware)
 
 ## Introduction
-OpenNESS is an open-source software toolkit to enable easy orchestration of edge services across diverse network platforms and access technologies in multi-cloud environments. It is inspired by the edge computing architecture defined by the [ETSI Multi-access Edge Computing (MEC) Framework and Reference Architecture](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/02.01.01_60/gs_MEC003v020101p.pdf) and the [3GPP System architecture for the 5G System TS 23.501](https://www.3gpp.org/DynaReport/23501.htm).
+Smart Edge Open is an open-source software toolkit to enable easy orchestration of edge services across diverse network platforms and access technologies in multi-cloud environments. It is inspired by the edge computing architecture defined by the [ETSI Multi-access Edge Computing (MEC) Framework and Reference Architecture](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/02.01.01_60/gs_MEC003v020101p.pdf) and the [3GPP System architecture for the 5G System TS 23.501](https://www.3gpp.org/DynaReport/23501.htm).
  
 It leverages major industry edge orchestration frameworks, such as Kubernetes\* and OpenStack\*, to implement a cloud-native architecture that is multi-platform, multi-access, and multi-cloud. It goes beyond these frameworks, however, by providing the ability for applications to publish their presence and capabilities on the platform, and for other applications to subscribe to those services. Services may be very diverse:
 - Providing location and radio network information
 - Operating a computer vision system that recognizes pedestrians/cars and forwards metadata from those objects to downstream traffic safety applications
  
-OpenNESS is access network agnostic, as it provides an architecture that interoperates with LTE, 5G, WiFi\*, and wired networks. In edge computing, dataplane flows must be routed to edge nodes concerning physical location (e.g., proximity to the endpoint, system load on the edge node, special hardware requirements). OpenNESS provides APIs that allow network orchestrators and edge computing controllers to configure routing policies uniformly.
+Smart Edge Open is access network agnostic, as it provides an architecture that interoperates with LTE, 5G, WiFi\*, and wired networks. In edge computing, dataplane flows must be routed to edge nodes concerning physical location (e.g., proximity to the endpoint, system load on the edge node, special hardware requirements). Smart Edge Open provides APIs that allow network orchestrators and edge computing controllers to configure routing policies uniformly.
  
 This guide is targeted at the <b><i>Cloud Application developers who want to</b></i>: 
-- Develop applications for Edge computing that take advantage of all the capabilities exposed through Edge Compute APIs in OpenNESS. 
+- Develop applications for Edge computing that take advantage of all the capabilities exposed through Edge Compute APIs in Smart Edge Open. 
 - Port the existing applications and services in the public/private cloud to the edge unmodified. 
 
-The document will describe how to develop applications from scratch using the template/example applications/services provided in the OpenNESS software release. All the OpenNESS Applications and services can be found in the [edgeapps repo](https://github.com/open-ness/edgeapps).
+The document will describe how to develop applications from scratch using the template/example applications/services provided in the Smart Edge Open software release. All the Smart Edge Open Applications and services can be found in the [edgeapps repo](https://github.com/smart-edge-open/edgeapps).
 
-## OpenNESS Edge Node Applications
-OpenNESS Applications can onboard and provision on the edge nodes only through the OpenNESS Controller. The first step in Onboarding involves uploading the application image to the controller through the web interface. Both VM and Container images are supported. 
+## Smart Edge Open Edge Node Applications
+Smart Edge Open Applications can onboard and provision on the edge nodes only through the Smart Edge Open Controller. The first step in Onboarding involves uploading the application image to the controller through the web interface. Both VM and Container images are supported. 
 
-OpenNESS application can be categorized in different ways depending on the scenarios. 
+Smart Edge Open application can be categorized in different ways depending on the scenarios. 
 
-- Depending on the OpenNESS APIs support 
+- Depending on the Smart Edge Open APIs support 
   - Applications calling EAA APIs for providing or consuming service on the edge compute along with servicing end-users traffic 
   - Applications not availing any services on the edge compute and just servicing end-user traffic 
 
 - Depending on the Application Execution platform 
-  - An application running natively on Edge node in a VM/Container provisioned by the OpenNESS controller 
-  - An application running on Local breakout not provisioned by the OpenNESS controller 
+  - An application running natively on Edge node in a VM/Container provisioned by the Smart Edge Open controller 
+  - An application running on Local breakout not provisioned by the Smart Edge Open controller 
 
 - Depending on the servicing the end-user traffic
   - Producer Application
   - Consumer Application 
 
 ### Producer Application
-OpenNESS Producer applications are edge compute applications that provide services to other applications running on the edge compute platform. Producer applications do not serve end users traffic directly. They are sometimes referred to as Edge services. The following are some characteristics of a producer app:
+Smart Edge Open Producer applications are edge compute applications that provide services to other applications running on the edge compute platform. Producer applications do not serve end users traffic directly. They are sometimes referred to as Edge services. The following are some characteristics of a producer app:
 - All producer apps must be TLS-capable and communicate through HTTPS. 
 - All producer apps need to activate if the service provided by them needs to be discoverable by other edge applications.
 - A producer apps can have one or more fields for which it will provide notification updates. 
 
 ### Consumer Application
-OpenNESS Consumer applications are edge compute applications that serve end users traffic directly. Consumer applications may or may not subscribe to the services from other producer applications on the edge node. The following are some characteristics of a consumer app:
+Smart Edge Open Consumer applications are edge compute applications that serve end users traffic directly. Consumer applications may or may not subscribe to the services from other producer applications on the edge node. The following are some characteristics of a consumer app:
 - It is not mandatory for consumer apps to be TLS-capable if they don't wish to call EAA APIs.  
 - A consumer application can subscribe to any number of services from producer apps. Future extensions can implement entitlements to consumer apps to create access control lists. 
 - Producer to Consumer update will use a web socket for notification. If there is further data to be shared between producer and consumer, other NFVi components such as OVS/VPP/NIC-VF can be used for data transfer. 
 
 ### Example of Producer and Consumer Applications
-The OpenNESS release includes reference producer and consumer applications.
+The Smart Edge Open release includes reference producer and consumer applications.
 
-![OpenNESS Reference Application](app-guide/openness_apps.png)
+![Smart Edge Open Reference Application](app-guide/smartedge-open_apps.png)
 
 _Figure - Example of Producer and Consumer Applications_
 
@@ -78,11 +78,11 @@ The consumer application is based on OpenVINO™ [OpenVINO] (https://software.in
 - The  OpenVINO™ consumer app executes inference on the input video stream.
 - The OpenVINO™ producer app generates notifications to the consumer app for changing the inference model.
 - The video input stream is captured from a webcam installed on an Embedded Linux\* client device.
-- The annotated video is streamed out of the OpenNESS edge node back to the client device for further data analysis
+- The annotated video is streamed out of the Smart Edge Open edge node back to the client device for further data analysis
 
 #### OpenVINO Producer Application
 
-The OpenVINO producer application is responsible for activating a service in OpenNESS Edge Node. This service is simply a publication of the inference model name that can be used by the OpenVINO consumer application(s). This service involves sending periodic `openvino-model` notifications (its interval is defined by `NotificationInterval`), which in turn is absorbed by the consumer application(s).
+The OpenVINO producer application is responsible for activating a service in Smart Edge Open Edge Node. This service is simply a publication of the inference model name that can be used by the OpenVINO consumer application(s). This service involves sending periodic `openvino-model` notifications (its interval is defined by `NotificationInterval`), which in turn is absorbed by the consumer application(s).
 
 The producer application commences publishing notifications after registration with the Edge Application Agent (EAA) over HTTPS REST API.
 
@@ -105,42 +105,42 @@ This sample OpenVINO consumer application represents a real-world application an
 
 The simplified execution flow of the consumer and producer applications with EAA is depicted in the sequence diagram below. Details on the various procedures of service activation/subscription and notifications are given in subsequent sections.
 
-![Figure caption \label{OpenVINO Execution Flow}](app-guide/openness_openvinoexecflow.png)
+![Figure caption \label{OpenVINO Execution Flow}](app-guide/smartedge-open_openvinoexecflow.png)
 
 _Figure - OpenVINO Application Execution Flow_
 
 ### Cloud Adapter Edge compute Application
 All the major Cloud Service providers are implementing frameworks to deploy edge applications that link back to their cloud via connectors. For example, Amazon Greengrass\* enables lambda functions to be deployed on the edge and connecting to the AWS\* cloud using the Greengrass service. While it was originally intended to host this type of edge software on IoT gateways, the same framework can be utilized by Service Providers and Enterprises to implement a multi-cloud strategy for their Edge Nodes.  
 
-OpenNESS enables this approach by running the Greengrass Core (with the Edge software) as Edge applications on the Edge Node. They can run unchanged or modified to utilize the EAA APIs to serve as Producer or Consumer apps on the Edge Node. By running multiple cloud connector instances from different cloud service providers on the same edge node, a multi-cloud experience can be easily implemented. 
+Smart Edge Open enables this approach by running the Greengrass Core (with the Edge software) as Edge applications on the Edge Node. They can run unchanged or modified to utilize the EAA APIs to serve as Producer or Consumer apps on the Edge Node. By running multiple cloud connector instances from different cloud service providers on the same edge node, a multi-cloud experience can be easily implemented. 
 
-OpenNESS supports this by the ability to deploy public cloud IoT gateways from cloud vendors like Amazon AWS IoT Greengrass and Baidu\* OpenEdge\* on edge compute platform. The existing IoT gateways can be migrated to OpenNESS as is or enhanced to call EAA APIs using extensions like Lambda functions. 
+Smart Edge Open supports this by the ability to deploy public cloud IoT gateways from cloud vendors like Amazon AWS IoT Greengrass and Baidu\* OpenEdge\* on edge compute platform. The existing IoT gateways can be migrated to Smart Edge Open as is or enhanced to call EAA APIs using extensions like Lambda functions. 
 
-![OpenNESS Cloud Adapters](app-guide/openness_cloudadapter.png)
+![Smart Edge Open Cloud Adapters](app-guide/smartedge-open_cloudadapter.png)
 
-_Figure - Example of Cloud Adapter Edge Application in OpenNESS Platform_
+_Figure - Example of Cloud Adapter Edge Application in Smart Edge Open Platform_
 
-More details about running Baidu OpenEdge as an OpenNESS application can be found here [Baidu OpenEdge Edge Application](../cloud-adapters/openness_baiducloud.md).
+More details about running Baidu OpenEdge as an Smart Edge Open application can be found here [Baidu OpenEdge Edge Application](../cloud-adapters/smartedge-open_baiducloud.md).
 
-More details about running Amazon AWS IoT Greengrass as an OpenNESS application can be found here  [Amazon AWS IoT Greengrass Edge Application](../cloud-adapters/openness_awsgreengrass.md).
+More details about running Amazon AWS IoT Greengrass as an Smart Edge Open application can be found here  [Amazon AWS IoT Greengrass Edge Application](../cloud-adapters/smartedge-open_awsgreengrass.md).
 
 ## Application On-boarding
 
-The OpenNESS toolkit allows application developers and content providers to onboard their own applications on the network edge, closer to the source of action. The edge computing development model imposes the business logic to be split and distributed across 3 sides: (a) _client side_, (b) _edge side_, and (c) _cloud side_. OpenNESS enables landing applications on the _edge side_.
+The Smart Edge Open toolkit allows application developers and content providers to onboard their own applications on the network edge, closer to the source of action. The edge computing development model imposes the business logic to be split and distributed across 3 sides: (a) _client side_, (b) _edge side_, and (c) _cloud side_. Smart Edge Open enables landing applications on the _edge side_.
 
-Applications to be onboarded on the OpenNESS framework must be self-contained in a container or a virtual machine (VM). The applications have the option to be landed with or without awareness of the hosting edge environment. The following sections will explore the two options and how they can be useful.
+Applications to be onboarded on the Smart Edge Open framework must be self-contained in a container or a virtual machine (VM). The applications have the option to be landed with or without awareness of the hosting edge environment. The following sections will explore the two options and how they can be useful.
 
 > **NOTE:** Code snippets given in this guide are written in Go language; this is purely for the ease of demonstration. All other programming languages should suffice for the same purposes.
 
 ### Authentication
 
-All communications over EAA REST APIs are secured with HTTPS and TLS (Transport Layer Security). Therefore, all applications that are onboarded on OpenNESS must obtain X.509 certificates from a Certificate Authority (CA). This is performed by [signing a certificate through the Kubernetes* API](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/). Each application that requires a certificate should generate it using the Certificate Signer by sending a CSR via Certificate Requester as detailed in [Certificate Signer guide](../applications-onboard/openness-certsigner.md). In brief, the application YAML specs must be extended to:
+All communications over EAA REST APIs are secured with HTTPS and TLS (Transport Layer Security). Therefore, all applications that are onboarded on Smart Edge Open must obtain X.509 certificates from a Certificate Authority (CA). This is performed by [signing a certificate through the Kubernetes* API](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/). Each application that requires a certificate should generate it using the Certificate Signer by sending a CSR via Certificate Requester as detailed in [Certificate Signer guide](../applications-onboard/smartedge-open-certsigner.md). In brief, the application YAML specs must be extended to:
 
 1. Include RBAC Service Account and Cluster Role Binding
 2. Include 2 Init Containers
 3. Create a ConfigMap with a JSON CSR config
 
-The above changes will enabled the application to exercise CSR with Kubernetes* API through the OpenNESS CertSigner service.
+The above changes will enabled the application to exercise CSR with Kubernetes* API through the Smart Edge Open CertSigner service.
 
 The cluster admin should manually approve the certificate in order to complete the application onboarding:
 
@@ -148,7 +148,7 @@ The cluster admin should manually approve the certificate in order to complete t
 kubectl certificate approve <app-name>
 ```
 
-> **NOTE:** The authentication steps is required when onboarding OpenNESS-aware and OpenNESS-agnostic applications.
+> **NOTE:** The authentication steps is required when onboarding Smart Edge Open-aware and Smart Edge Open-agnostic applications.
 
 The below Golang sample represent the logic that the application can use to load the signed certificate and use it for subsequent HTTPS communications. The function `CreateEncryptedClient` loads the certificates from the container local file system and instantiates the Golang's [TLS client](https://golang.org/pkg/net/http/#Client) instance that is subsequently used in further HTTP messaging.
 
@@ -215,17 +215,17 @@ func main() {
 }
 ```
 
-### OpenNESS-aware Applications
-Edge applications must introduce themselves to the OpenNESS framework and identify if they would like to activate new edge services or consume an existing service. The Edge Application Agent (EAA) component is the handler of all the edge applications hosted by the OpenNESS edge node and acts as their point of contact. All interactions with EAA are through REST APIs, which are defined in [Edge Application API](https://www.openness.org/api-documentation/?api=eaa).
+### Smart Edge Open-aware Applications
+Edge applications must introduce themselves to the Smart Edge Open framework and identify if they would like to activate new edge services or consume an existing service. The Edge Application Agent (EAA) component is the handler of all the edge applications hosted by the Smart Edge Open edge node and acts as their point of contact. All interactions with EAA are through REST APIs, which are defined in [Edge Application API](https://www.openness.org/api-documentation/?api=eaa).
 
-OpenNESS-awareness involves (a) service activation/deactivation, (b) service discovery, (c) service subscription, and (c) Websocket connection establishment. The Websocket connection retains a channel for EAA for notification forwarding to pre-subscribed consumer applications. Notifications are generated by "producer" edge applications and absorbed by "consumer" edge applications.
+Smart Edge Open-awareness involves (a) service activation/deactivation, (b) service discovery, (c) service subscription, and (c) Websocket connection establishment. The Websocket connection retains a channel for EAA for notification forwarding to pre-subscribed consumer applications. Notifications are generated by "producer" edge applications and absorbed by "consumer" edge applications.
 
 The sequence of operations for the producer application are:
 1. Activate new service and include the list of notifications involved
-2. Send notifications to the OpenNESS edge node, according to business logic
+2. Send notifications to the Smart Edge Open edge node, according to business logic
 
 The sequence of operations for the consumer application:
-1. Discover the available services on OpenNESS edge platform
+1. Discover the available services on Smart Edge Open edge platform
 2. Subscribe to services of interest and listen for notifications
 
 #### Service Activation
@@ -275,7 +275,7 @@ resp.Body.Close()
 
 #### Service Discovery and Subscription
 
-The consumer application must establish a Websocket before subscribing to services. The example code below shows how a Websocket connection can be established with the OpenNESS edge node:
+The consumer application must establish a Websocket before subscribing to services. The example code below shows how a Websocket connection can be established with the Smart Edge Open edge node:
 
 ```golang
 var socket = websocket.Dialer{
@@ -369,13 +369,13 @@ for keepListen {
 }
 ```
 
-### OpenNESS-agnostic Applications
+### Smart Edge Open-agnostic Applications
 
-In a situation where the developer has a legacy, pre-compiled or binary applications (which are not easy to edit or modify and are not looking for consuming edge services) can be onboarded without the awareness of the underlying hosting framework. In such a case, the OpenNESS edge framework will also be unaware of the existence of these applications. Therefore, the life-cycle management of these applications becomes the responsibility of the user to configure, upload, deploy, un-deploy, start, and stop. When an application requires ingress and/or egress traffic, the corresponding traffic policies must be configured manually to allow the concerning traffic to be steered in and out to the application.
+In a situation where the developer has a legacy, pre-compiled or binary applications (which are not easy to edit or modify and are not looking for consuming edge services) can be onboarded without the awareness of the underlying hosting framework. In such a case, the Smart Edge Open edge framework will also be unaware of the existence of these applications. Therefore, the life-cycle management of these applications becomes the responsibility of the user to configure, upload, deploy, un-deploy, start, and stop. When an application requires ingress and/or egress traffic, the corresponding traffic policies must be configured manually to allow the concerning traffic to be steered in and out to the application.
 
-### Make Legacy Applications OpenNESS-aware
+### Make Legacy Applications Smart Edge Open-aware
 
-Legacy, pre-compiled, or binary applications can be made OpenNESS-aware by following few steps without editing their code. This can be done by wrapping these applications with a separate program that is written purposefully to (a) communicate with OpenNESS Edge Node and (b) execute the legacy application.
+Legacy, pre-compiled, or binary applications can be made Smart Edge Open-aware by following few steps without editing their code. This can be done by wrapping these applications with a separate program that is written purposefully to (a) communicate with Smart Edge Open Edge Node and (b) execute the legacy application.
 
 The wrapper program interacts with EAA for (a) Websocket connection establishment, (b) service discovery, and (c) service subscription. And call the legacy application with the proper arguments based on the received notifications. Or, if the legacy application is intended to work as a producer application, then the wrapper programmer should activate the edge service with EAA and send the notifications based on the outcomes of the legacy application.
 
diff --git a/doc/applications/openness_openvino.md b/doc/applications/smartedge-open_openvino.md
similarity index 73%
rename from doc/applications/openness_openvino.md
rename to doc/applications/smartedge-open_openvino.md
index 6d2ee25e..3289d0ce 100644
--- a/doc/applications/openness_openvino.md
+++ b/doc/applications/smartedge-open_openvino.md
@@ -3,7 +3,7 @@ SPDX-License-Identifier: Apache-2.0
 Copyright © 2019 Intel Corporation  
 ```
 <!-- omit in toc -->
-# OpenVINO™ Sample Application in OpenNESS
+# OpenVINO™ Sample Application in Smart Edge Open
 - [Introduction](#introduction)
 - [Accelerating OpenVINO execution through Intel Movidius VPUs](#accelerating-openvino-execution-through-intel-movidius-vpus)
 - [Components](#components)
@@ -18,18 +18,18 @@ Copyright © 2019 Intel Corporation
 ## Introduction
 The Open Visual Inference and Neural network Optimization (OpenVINO™) toolkit provides improved neural network performance on Intel’s processors and enables the development of cost-effective and real-time vision applications. The toolkit enables deep learning inference and easy heterogeneous execution across multiple platforms—CPUs from Intel, integrated graphics from Intel, Intel® FPGA, Intel® Movidius™ Neural Compute Stick, Intel® Neural Compute Stick 2, and Intel® Vision Accelerator Design with Intel® Movidius™ VPUs—providing implementations across cloud architectures to edge devices.
 
-The Open Network Edge Services Software (OpenNESS) toolkit enables developers and businesses to easily land deep learning solutions that were optimized using the OpenVINO™ toolkit on-premises and on the network edge. Visual inference applications using OpenVINO™ are onboarded by OpenNESS for accelerated and low-latency execution on the edge.
+The Open Network Edge Services Software (Smart Edge Open) toolkit enables developers and businesses to easily land deep learning solutions that were optimized using the OpenVINO™ toolkit on-premises and on the network edge. Visual inference applications using OpenVINO™ are onboarded by Smart Edge Open for accelerated and low-latency execution on the edge.
 
-This sample application demonstrates OpenVINO object detection (pedestrian and vehicle detection) deployment and execution on the OpenNESS edge platform. A live data feed received from a client device is inferred using OpenVINO pre-trained models, `pedestrian-detection-adas-0002` and `vehicle-detection-adas-0002`
+This sample application demonstrates OpenVINO object detection (pedestrian and vehicle detection) deployment and execution on the Smart Edge Open edge platform. A live data feed received from a client device is inferred using OpenVINO pre-trained models, `pedestrian-detection-adas-0002` and `vehicle-detection-adas-0002`
 
-This sample application is based on the OpenVINO toolkit 2019 R1.1 and uses the provided OpenVINO "Object Detection SSD C++ Demo - Async API" sample application with some amendments to work with the OpenNESS deployment. The changes are applied using the provided patch: `object_detection_demo_ssd_async.patch`
+This sample application is based on the OpenVINO toolkit 2019 R1.1 and uses the provided OpenVINO "Object Detection SSD C++ Demo - Async API" sample application with some amendments to work with the Smart Edge Open deployment. The changes are applied using the provided patch: `object_detection_demo_ssd_async.patch`
 
 ## Accelerating OpenVINO execution through Intel Movidius VPUs
 
 The OpenVINO consumer application supports acceleration with Intel Movidius VPUs (Intel® Neural Compute Stick 2 (NCS2)) or HDDL (High Density Deep Learning) PCIe\* card.
 The OpenVINO toolkit accelerates inference execution across the CPU, NCS2, and HDDL through its Inference Engine Plugins: a) CPU, b) MYRIAD, and c) HDDL.
 
-> **NOTE**: Acceleration through Intel Movidius VPUs requires that hardware is plugged into the host platform. Refer to the [Intel® Movidius™ Myriad™ X HDDL](../enhanced-platform-awareness/openness_hddl.md) and [Intel® Neural Compute Stick 2](https://ark.intel.com/content/www/us/en/ark/products/140109/intel-neural-compute-stick-2.html) documents for more information.
+> **NOTE**: Acceleration through Intel Movidius VPUs requires that hardware is plugged into the host platform. Refer to the [Intel® Movidius™ Myriad™ X HDDL](../enhanced-platform-awareness/smartedge-open_hddl.md) and [Intel® Neural Compute Stick 2](https://ark.intel.com/content/www/us/en/ark/products/140109/intel-neural-compute-stick-2.html) documents for more information.
 
 ## Components
 
@@ -43,11 +43,11 @@ Each component is contained in a Docker\* container, namely: `client-sim:1.0`,`o
 
 ### Client Simulator
 
-The client simulator is responsible for continuously transmitting a video stream up to the OpenNESS edge platform. The video traffic is steered by NTS to the concerned OpenVINO consumer application.
+The client simulator is responsible for continuously transmitting a video stream up to the Smart Edge Open edge platform. The video traffic is steered by NTS to the concerned OpenVINO consumer application.
 
 ### OpenVINO Producer Application
 
-The OpenVINO producer application is responsible for activating a service in OpenNESS Edge Node. This service is simply a publication of the inference model name, which can be used by the OpenVINO consumer application(s). This service involves sending periodic `openvino-inference` notifications, which in turn are absorbed by the consumer application(s).
+The OpenVINO producer application is responsible for activating a service in Smart Edge Open Edge Node. This service is simply a publication of the inference model name, which can be used by the OpenVINO consumer application(s). This service involves sending periodic `openvino-inference` notifications, which in turn are absorbed by the consumer application(s).
 
 The producer application commences publishing notifications after it handshakes with the Edge Application Agent (EAA) over HTTPS REST API. This handshaking involves authentication and service activation. The HTTPS communication requires certificate which should be generated with using the Certificate Signer by sending a CSR via Certificate Requester.
 
@@ -88,26 +88,26 @@ The HTTPS communication requires certificate which should be generated with usin
 
 The simplified execution flow of the consumer and producer applications with EAA is depicted in the sequence diagram below.
 
-![Figure caption \label{OpenVINO Execution Flow}](app-guide/openness_openvinoexecflow.png)
+![Figure caption \label{OpenVINO Execution Flow}](app-guide/smartedge-open_openvinoexecflow.png)
 
 _Figure - OpenVINO Application Execution Flow_
 
-For more information about CSR, refer to [OpenNESS CertSigner](../applications-onboard/openness-certsigner.md)
+For more information about CSR, refer to [Smart Edge Open CertSigner](../applications-onboard/smartedge-open-certsigner.md)
 
 ## Build & Deployment of OpenVINO Applications
 
 ### Docker Images Creation
 
-Applications are deployed on the OpenNESS Edge Node as Docker containers. Three docker containers need to be built to get the OpenVINO pipeline working: `clientsim`, `producer`, and `consumer`. The `clientsim` Docker image must be built and executed on the client simulator machine while the `producer` and `consumer` containers/pods should be onboarded on the OpenNESS Edge Node.
+Applications are deployed on the Smart Edge Open Edge Node as Docker containers. Three docker containers need to be built to get the OpenVINO pipeline working: `clientsim`, `producer`, and `consumer`. The `clientsim` Docker image must be built and executed on the client simulator machine while the `producer` and `consumer` containers/pods should be onboarded on the Smart Edge Open Edge Node.
 
-On the client simulator, clone the [OpenNESS edgeapps](https://github.com/open-ness/edgeapps) and execute the following command to build the `client-sim` container:
+On the client simulator, clone the [Smart Edge Open edgeapps](https://github.com/smart-edge-open/edgeapps) and execute the following command to build the `client-sim` container:
 
 ```shell
 cd <edgeapps-repo>/openvino/clientsim
 ./build-image.sh
 ```
 
-On the OpenNESS Edge Node, clone the [OpenNESS edgeapps](https://github.com/open-ness/edgeapps) and execute the following command to build the `producer` and `consumer` containers:
+On the Smart Edge Open Edge Node, clone the [Smart Edge Open edgeapps](https://github.com/smart-edge-open/edgeapps) and execute the following command to build the `producer` and `consumer` containers:
 ```shell
 cd <edgeapps-repo>/openvino/producer
 ./build-image.sh
@@ -136,7 +136,7 @@ openvino-prod-app       1.0
 The OpenVINO edge application accepts a TCP video stream. This video stream can
 be from any video source such as an IP camera. The Client Simulator provided in
 this project uses a sample mp4 video file to continuously transmit the video
-stream to the OpenNESS Edge Node. Object detection is executed on this video
+stream to the Smart Edge Open Edge Node. Object detection is executed on this video
 transmission and sent back to the client for further analysis.
 
 The `client-sim` Docker container performs the operations:
diff --git a/doc/applications/openness_ovc.md b/doc/applications/smartedge-open_ovc.md
similarity index 59%
rename from doc/applications/openness_ovc.md
rename to doc/applications/smartedge-open_ovc.md
index 2374a07b..0552fca1 100644
--- a/doc/applications/openness_ovc.md
+++ b/doc/applications/smartedge-open_ovc.md
@@ -3,26 +3,26 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019 Intel Corporation
 ```
 <!-- omit in toc -->
-# Open Visual Cloud Smart City Application on OpenNESS - Solution Overview
-- [OpenNESS Introduction](#openness-introduction)
+# Open Visual Cloud Smart City Application on Smart Edge Open - Solution Overview
+- [Smart Edge Open Introduction](#smart-edge-open-introduction)
 - [Open Visual Cloud Introduction](#open-visual-cloud-introduction)
 - [Smart City Edge Application Introduction](#smart-city-edge-application-introduction)
 - [The Smart City Building Blocks](#the-smart-city-building-blocks)
-- [Smart City App Deployment with OpenNESS](#smart-city-app-deployment-with-openness)
-- [Open Visual Cloud and OpenNESS Integration using Virtual Machines](#open-visual-cloud-and-openness-integration-using-virtual-machines)
+- [Smart City App Deployment with Smart Edge Open](#smart-city-app-deployment-with-smart-edge-open)
+- [Open Visual Cloud and Smart Edge Open Integration using Virtual Machines](#open-visual-cloud-and-smart-edge-open-integration-using-virtual-machines)
   - [The Infrastructure Challenges](#the-infrastructure-challenges)
   - [The Smart City Application Challenges](#the-smart-city-application-challenges)
-- [Open Visual Cloud and OpenNESS Integration as cloud-native](#open-visual-cloud-and-openness-integration-as-cloud-native)
+- [Open Visual Cloud and Smart Edge Open Integration as cloud-native](#open-visual-cloud-and-smart-edge-open-integration-as-cloud-native)
 - [Conclusion](#conclusion)
 
-## OpenNESS Introduction
-OpenNESS is an open-source software toolkit that enables easy orchestration of edge services across diverse network platforms and access technologies in multi-cloud environments. It is inspired by the edge computing architecture defined by the [ETSI Multi-access Edge Computing (MEC) Framework and Reference Architecture](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/02.01.01_60/gs_MEC003v020101p.pdf) and the [3GPP System architecture for the 5G System TS 23.501](https://www.3gpp.org/DynaReport/23501.htm).
+## Smart Edge Open Introduction
+Smart Edge Open is an open-source software toolkit that enables easy orchestration of edge services across diverse network platforms and access technologies in multi-cloud environments. It is inspired by the edge computing architecture defined by the [ETSI Multi-access Edge Computing (MEC) Framework and Reference Architecture](https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/02.01.01_60/gs_MEC003v020101p.pdf) and the [3GPP System architecture for the 5G System TS 23.501](https://www.3gpp.org/DynaReport/23501.htm).
 
-OpenNESS leverages major industry edge orchestration frameworks, such as Kubernetes\* and OpenStack\*, to implement a cloud-native architecture that is multi-platform, multi-access, and multi-cloud. It goes beyond these frameworks, however, by providing the ability for applications to publish their presence and capabilities on the platform and for other applications to subscribe to those services. Services may be very diverse:
+Smart Edge Open leverages major industry edge orchestration frameworks, such as Kubernetes\* and OpenStack\*, to implement a cloud-native architecture that is multi-platform, multi-access, and multi-cloud. It goes beyond these frameworks, however, by providing the ability for applications to publish their presence and capabilities on the platform and for other applications to subscribe to those services. Services may be very diverse:
 * Providing location and radio network information
 * Operating a computer vision system that recognizes pedestrians and cars, and then forwards metadata from those objects to downstream traffic safety applications.
 
-OpenNESS is access network agnostic, as it provides an architecture that interoperates with LTE, 5G, WiFi\*, and wired networks. In edge computing, dataplane flows must be routed to edge nodes with respect to a physical location (e.g., proximity to the endpoint, system load on the edge node, and special hardware requirements). OpenNESS provides APIs that allow network orchestrators and edge computing controllers to configure routing policies uniformly.
+Smart Edge Open is access network agnostic, as it provides an architecture that interoperates with LTE, 5G, WiFi\*, and wired networks. In edge computing, dataplane flows must be routed to edge nodes with respect to a physical location (e.g., proximity to the endpoint, system load on the edge node, and special hardware requirements). Smart Edge Open provides APIs that allow network orchestrators and edge computing controllers to configure routing policies uniformly.
 
 ## Open Visual Cloud Introduction
 Open Visual Cloud is an open-source project that offers a set of pre-defined reference pipelines for various target visual cloud use cases. These reference pipelines are based on optimized open-source ingredients across four core building blocks (encode, decode, inference, and render), which are used to deliver visual cloud services.
@@ -32,13 +32,13 @@ Open Visual Cloud provides access to open-source interoperable building blocks t
 ## Smart City Edge Application Introduction
 The Smart City reference pipeline shows how the integration of various media building blocks, including SVT, with analytics powered by the OpenVINO<sup>TM</sup> Toolkit. Smart City use cases include traffic control/city planning as the starting point. This Smart City sample (not a finished product) can be referenced by developers to ease application development challenges. It enables real-time analytics of live video feeds from IP cameras.
 
-The Smart City sample when deployed on Edge nodes based on OpenNESS creates an impactful edge computing use case that utilizes the capability of OpenNESS, Open Visual Cloud, and OpenVINO™.
+The Smart City sample when deployed on Edge nodes based on Smart Edge Open creates an impactful edge computing use case that utilizes the capability of Smart Edge Open, Open Visual Cloud, and OpenVINO™.
 
-OpenNESS provides the underpinning network edge infrastructure which comprises three edge nodes (hosting three Smart City regional offices). The media processing and analytics utilizing the Open Visual Cloud software stack are executed on the network edge nodes to reduce latency. The analytics data are aggregated to the cloud for additional post-processing (such as calculating statistics) and display/visualization.
+Smart Edge Open provides the underpinning network edge infrastructure which comprises three edge nodes (hosting three Smart City regional offices). The media processing and analytics utilizing the Open Visual Cloud software stack are executed on the network edge nodes to reduce latency. The analytics data are aggregated to the cloud for additional post-processing (such as calculating statistics) and display/visualization.
 
-![Smart City Architecure Deployed with OpenNESS](ovc-images/smart-city-architecture.png)
+![Smart City Architecure Deployed with Smart Edge Open](ovc-images/smart-city-architecture.png)
 
-The Open Visual Cloud website is located at the [Open Visual Cloud project](https://01.org/openvisualcloud). Smart City sample source code and documentation are available on [GitHub](https://github.com/OpenVisualCloud/Smart-City-Sample) and its integration with OpenNESS is available at [OpenNESS branch](https://github.com/OpenVisualCloud/Smart-City-Sample).
+The Open Visual Cloud website is located at the [Open Visual Cloud project](https://01.org/openvisualcloud). Smart City sample source code and documentation are available on [GitHub](https://github.com/OpenVisualCloud/Smart-City-Sample) and its integration with Smart Edge Open is available at [Smart Edge Open branch](https://github.com/OpenVisualCloud/Smart-City-Sample).
 
 ## The Smart City Building Blocks
 The Smart City sample consists of the following major building blocks:
@@ -60,20 +60,20 @@ Each building block is implemented as one or a set of container services that qu
 
 For example, when launched, the analytics service queries the database for an available camera and its service URI. Then the service connects to the camera and analyzes the camera feeds. The resulted analytics data is stored back to the database for any subsequent processing such as triggering alerts and actions.
 
-## Smart City App Deployment with OpenNESS
+## Smart City App Deployment with Smart Edge Open
 
-The Smart City application is deployed through the OpenNESS Network Edge architecture, which requires the application micro-services to be adapted to match the distributed nature of the telecommunications network. The application micro-services are deployed across the following sub-networks:
+The Smart City application is deployed through the Smart Edge Open Network Edge architecture, which requires the application micro-services to be adapted to match the distributed nature of the telecommunications network. The application micro-services are deployed across the following sub-networks:
 
 - **Cloud**: The UI and the database controller run in the cloud, where the UI displays a summarization view of the active offices and the database controller coordinates the database requests.
 - **Office**: Most processing logics (multiple containers) and a local database reside in a regional office. The services include camera discovery, object detection, and other maintenance tasks such as clean up and health checks. There can be multiple offices.
 - **Camera**: A set of cameras, possibly connected through the wireless network, are hosted on a different camera network.
 
-The three edge nodes (representing three regional offices) are connected to the OpenNESS controller. All three nodes also have connectivity to the public/private cloud. The following are the typical steps involved in the deployment of the application using OpenNESS.
-  1. The OpenNESS controller enrolls the three Edge nodes.
+The three edge nodes (representing three regional offices) are connected to the Smart Edge Open controller. All three nodes also have connectivity to the public/private cloud. The following are the typical steps involved in the deployment of the application using Smart Edge Open.
+  1. The Smart Edge Open controller enrolls the three Edge nodes.
   2. Each Edge node sends the request for interface configuration.
-  3. The OpenNESS controller configures the interface policy for upstream and downstream for each node.
-  4. The OpenNESS controller deploys the Smart City VM to each edge node.
-  5. The OpenNESS controller configures the DNS and traffic policy for the applications on each node.
+  3. The Smart Edge Open controller configures the interface policy for upstream and downstream for each node.
+  4. The Smart Edge Open controller deploys the Smart City VM to each edge node.
+  5. The Smart Edge Open controller configures the DNS and traffic policy for the applications on each node.
   6. The Smart City VM starts on the edge node and launches the Smart City office services.
 
 When a Smart City office is launched, the office performs the following launch steps:
@@ -86,9 +86,9 @@ The **Cloud** and **Camera** parts of the Smart City Application are not part of
 
 ![Smart City Application UI](ovc-images/screenshot.gif)
 
-## Open Visual Cloud and OpenNESS Integration using Virtual Machines
+## Open Visual Cloud and Smart Edge Open Integration using Virtual Machines
 
-The integration of the Smart City application with the OpenNESS infrastructure presents unique challenges on both the application and the infrastructure. The following challenges were faced when packaging and deploying the Smart City application as Virtual Machines (VM) on OpenNESS: 
+The integration of the Smart City application with the Smart Edge Open infrastructure presents unique challenges on both the application and the infrastructure. The following challenges were faced when packaging and deploying the Smart City application as Virtual Machines (VM) on Smart Edge Open: 
 
 ### The Infrastructure Challenges
 
@@ -100,14 +100,14 @@ Most Edge applications require local storage to store data or to communicate amo
 
 The Smart City application initially assumed that each IP camera was standalone on the network and was associated with a unique IP address. It was soon realized that if the camera streams must be delivered through the LTE network, there had to be some sort of camera aggregation. As a result, the sensor simulation code is rewritten to simulate multiple cameras hosted on the same machine (streaming through different ports.)
 
-OpenNESS limits service requests initiated from the cloud to the Edge nodes. The Smart City application however sometimes needs to communicate to the offices (for example, to retrieve Edge workloads.) As a workaround, the application creates and maintains a secure tunnel to the cloud at the official launch time to facilitate the requests coming from the cloud.
+Smart Edge Open limits service requests initiated from the cloud to the Edge nodes. The Smart City application however sometimes needs to communicate to the offices (for example, to retrieve Edge workloads.) As a workaround, the application creates and maintains a secure tunnel to the cloud at the official launch time to facilitate the requests coming from the cloud.
 
 The deployment script is also rewritten to separate the launch of the services into three networks: cloud, edge, and camera. Using VM as a launch vehicle, we also have to develop automation scripts to bring up the containers within VM and to establish secure connections to the cloud for registration and service redirection.
 
-## Open Visual Cloud and OpenNESS Integration as cloud-native
+## Open Visual Cloud and Smart Edge Open Integration as cloud-native
 
-Integrating the [cloud-native Smart City application](https://github.com/OpenVisualCloud/Smart-City-Sample/blob/master/deployment/kubernetes/README.md) with OpenNESS was a seamless process due to the OpenNESS adoption of Kubernetes standard features (Namespaces, Services, DaemonSets, and Network Policies). In one step, the Smart City application is deployed on the OpenNESS setup based on the reference deployment on vanilla Kubernetes. Details about onboarding the cloud-native Smart City application with OpenNESS is covered in the [application onboarding guide](../applications-onboard/network-edge-applications-onboarding.md#onboarding-smart-city-sample-application).
+Integrating the [cloud-native Smart City application](https://github.com/OpenVisualCloud/Smart-City-Sample/blob/master/deployment/kubernetes/README.md) with Smart Edge Open was a seamless process due to the Smart Edge Open adoption of Kubernetes standard features (Namespaces, Services, DaemonSets, and Network Policies). In one step, the Smart City application is deployed on the Smart Edge Open setup based on the reference deployment on vanilla Kubernetes. Details about onboarding the cloud-native Smart City application with Smart Edge Open is covered in the [application onboarding guide](../applications-onboard/network-edge-applications-onboarding.md#onboarding-smart-city-sample-application).
 
 ## Conclusion
 
-The Smart City sample when deployed on the Edge nodes based on OpenNESS creates an impactful edge computing use case that utilizes the capability of OpenNESS, Open Visual Cloud, and OpenVINO™. The integration shows that the three can run together to show scalable Edge deployment and low-latency analytics processing on Edge nodes.
+The Smart City sample when deployed on the Edge nodes based on Smart Edge Open creates an impactful edge computing use case that utilizes the capability of Smart Edge Open, Open Visual Cloud, and OpenVINO™. The integration shows that the three can run together to show scalable Edge deployment and low-latency analytics processing on Edge nodes.
diff --git a/doc/applications/openness_service_mesh.md b/doc/applications/smartedge-open_service_mesh.md
similarity index 80%
rename from doc/applications/openness_service_mesh.md
rename to doc/applications/smartedge-open_service_mesh.md
index e96ef0d9..aab9af94 100644
--- a/doc/applications/openness_service_mesh.md
+++ b/doc/applications/smartedge-open_service_mesh.md
@@ -3,9 +3,9 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# Utilizing a Service Mesh for Edge Services in OpenNESS
+# Utilizing a Service Mesh for Edge Services in Smart Edge Open
 - [Overview](#overview)
-- [OpenNESS Service Mesh Enablement through Istio](#openness-service-mesh-enablement-through-istio)
+- [Smart Edge Open Service Mesh Enablement through Istio](#smart-edge-open-service-mesh-enablement-through-istio)
 - [Video Analytics Service Mesh](#video-analytics-service-mesh)
 - [Video Analytics Service Mesh Deployment](#video-analytics-service-mesh-deployment)
 - [Authentication, Authorization & Mutual TLS enforcement](#authentication-authorization--mutual-tls-enforcement)
@@ -25,23 +25,23 @@ Copyright (c) 2020 Intel Corporation
 
 ## Overview
 
-Service mesh acts as a middleware between the edge applications/services and the OpenNESS platform that provides abstractions for traffic management, observability, and security of the edge micro-services in the mesh.
+Service mesh acts as a middleware between the edge applications/services and the Smart Edge Open platform that provides abstractions for traffic management, observability, and security of the edge micro-services in the mesh.
 
 In the native Kubernetes deployment, the services are orchestrated by the Kubernetes controller and the consumer applications must decide which service endpoint they need to reach out according to the services information broadcasted on the Edge Application Agent (EAA) bus.
 
 With the Service Mesh approach, the applications do not decide which service endpoint it should reach. Instead, it requests a service name that is translated and load-balanced by the service mesh. The service mesh manages the traffic routing and the service scale-up and down behind the scenes, and it adds more capabilities to the mix such as tracing, monitoring, and logging.
 
 
-## OpenNESS Service Mesh Enablement through Istio
+## Smart Edge Open Service Mesh Enablement through Istio
 
-[Istio](https://istio.io/) is a feature-rich, cloud-native service mesh platform that provides a collection of key capabilities such as: [Traffic Management](https://istio.io/latest/docs/concepts/traffic-management/), [Security](https://istio.io/latest/docs/concepts/security/) and [Observability](https://istio.io/latest/docs/concepts/observability/) uniformly across a network of services. OpenNESS integrates natively with the Istio service mesh to help reduce the complexity of large scale edge applications, services, and network functions. The Istio service mesh is deployed automatically through Converged Edge Experience Kits (CEEK) with an option to onboard the media analytics services on the service mesh.
+[Istio](https://istio.io/) is a feature-rich, cloud-native service mesh platform that provides a collection of key capabilities such as: [Traffic Management](https://istio.io/latest/docs/concepts/traffic-management/), [Security](https://istio.io/latest/docs/concepts/security/) and [Observability](https://istio.io/latest/docs/concepts/observability/) uniformly across a network of services. Smart Edge Open integrates natively with the Istio service mesh to help reduce the complexity of large scale edge applications, services, and network functions. The Istio service mesh is deployed automatically through Converged Edge Experience Kits (CEEK) with an option to onboard the media analytics services on the service mesh.
 
-Istio mandates injecting [Envoy sidecars](https://istio.io/latest/docs/ops/deployment/architecture/#envoy) into the applications and services pods to become part of the service mesh. The Envoy sidecars intercept all inter-pod traffic, making it easy to manage, secure, and observe. Sidecar injection is automatically enabled to the `default` namespace in the OpenNESS cluster. This is done by applying the label `istio-injection=enabled` to the `default` namespace.
+Istio mandates injecting [Envoy sidecars](https://istio.io/latest/docs/ops/deployment/architecture/#envoy) into the applications and services pods to become part of the service mesh. The Envoy sidecars intercept all inter-pod traffic, making it easy to manage, secure, and observe. Sidecar injection is automatically enabled to the `default` namespace in the Smart Edge Open cluster. This is done by applying the label `istio-injection=enabled` to the `default` namespace.
 
 
 ## Video Analytics Service Mesh
 
-OpenNESS Video Analytics services enable third-party consumer applications running on OpenNESS to perform video analytics and inferencing workloads by consuming the Video Analytics Serving APIs as described in the [OpenNESS Video Analytics Services](./openness_va_services.md).
+Smart Edge Open Video Analytics services enable third-party consumer applications running on Smart Edge Open to perform video analytics and inferencing workloads by consuming the Video Analytics Serving APIs as described in the [Smart Edge Open Video Analytics Services](./smartedge-open_va_services.md).
 
 The proposed architecture with the video analytics use case is depicted in the graphic below:
 
@@ -106,9 +106,9 @@ spec:
 
 ## Authentication, Authorization & Mutual TLS enforcement
 
-Mutual TLS is enforced by default in OpenNESS to enable authentication of all applications and services onboarded on the mesh.
+Mutual TLS is enforced by default in Smart Edge Open to enable authentication of all applications and services onboarded on the mesh.
 
-To prevent non-mutual TLS for the whole mesh, the following `PeerAuthentication` policy is automatically applied to the `default` namespace in the OpenNESS cluster. This policy instructs Istio to *strictly* set the mutual TLS between all mesh applications and services running in the `default` namespace.
+To prevent non-mutual TLS for the whole mesh, the following `PeerAuthentication` policy is automatically applied to the `default` namespace in the Smart Edge Open cluster. This policy instructs Istio to *strictly* set the mutual TLS between all mesh applications and services running in the `default` namespace.
 
 ```yaml
 apiVersion: security.istio.io/v1beta1
@@ -144,9 +144,9 @@ spec:
         methods: ["GET", "POST", "DELETE"]
 ```
 
-In this `AuthorizationPolicy`, the Istio service mesh will allow "GET", "POST", and "DELETE" requests from any authenticated applications from the `default` namespace only to be passed to the service. For example, if using the [Video Analytics sample application](https://github.com/open-ness/edgeapps/tree/master/applications/vas-sample-app), the policy will allow requests from the sample application to be received by the service as it is deployed in the `default` namespace. However, if the application is deployed in a different namespace (for example, the `openness` namespace mentioned above in the output from the Kubernetes cluster), then the policy will deny access to the service as the request is coming from an application on a different namespace.
+In this `AuthorizationPolicy`, the Istio service mesh will allow "GET", "POST", and "DELETE" requests from any authenticated applications from the `default` namespace only to be passed to the service. For example, if using the [Video Analytics sample application](https://github.com/smart-edge-open/edgeapps/tree/master/applications/vas-sample-app), the policy will allow requests from the sample application to be received by the service as it is deployed in the `default` namespace. However, if the application is deployed in a different namespace (for example, the `openness` namespace mentioned above in the output from the Kubernetes cluster), then the policy will deny access to the service as the request is coming from an application on a different namespace.
 
-> **NOTE**: The above `AuthorizationPolicy` can be tailored so that the OpenNESS service mesh *selectively* authorizes particular applications to consume premium video analytics services such as those accelerated using HDDL or VCAC-A cards.
+> **NOTE**: The above `AuthorizationPolicy` can be tailored so that the Smart Edge Open service mesh *selectively* authorizes particular applications to consume premium video analytics services such as those accelerated using HDDL or VCAC-A cards.
 
 ## Traffic Management
 
@@ -158,7 +158,7 @@ The following examples are based on the [BookInfo sample application](https://is
 
 _Figure - Book Info Sample Application_
 
-> **NOTE**: By default, the Istio deployment namespace in OpenNESS is set to the `default` Kubernetes namespace where all the ingress traffic to the cluster is blocked by the default network policy `block-all-ingress`. At the time of writing this document, the Kubernetes NetworkPolicy does not support specifying port ranges that are needed by the BookInfo sample application. Therefore, as a workaround, the user should remove the network policy of the `default` namespace.
+> **NOTE**: By default, the Istio deployment namespace in Smart Edge Open is set to the `default` Kubernetes namespace where all the ingress traffic to the cluster is blocked by the default network policy `block-all-ingress`. At the time of writing this document, the Kubernetes NetworkPolicy does not support specifying port ranges that are needed by the BookInfo sample application. Therefore, as a workaround, the user should remove the network policy of the `default` namespace.
 > 
 > ```shell
 > kubectl delete netpol block-all-ingress
@@ -318,7 +318,7 @@ _Figure - Canary Deployment with TrafficSplit_
 
 ## Fault Injection
 
-Fault injection, in the context of Istio, is a mechanism by which failures can be purposefully injected into the service mesh to mimic how an application would behave in case failures or degradations are encountered. Application developers and cluster administrators can programmatically inject faults at the application layer instead of killing pods, delaying packets, or corrupting packets at the TCP layer. Istio provisions various APIs to perform fault injections such as delays, aborts, and circuit breakers to the application micro-services deployed in the OpenNESS cluster and to verify their resiliency.
+Fault injection, in the context of Istio, is a mechanism by which failures can be purposefully injected into the service mesh to mimic how an application would behave in case failures or degradations are encountered. Application developers and cluster administrators can programmatically inject faults at the application layer instead of killing pods, delaying packets, or corrupting packets at the TCP layer. Istio provisions various APIs to perform fault injections such as delays, aborts, and circuit breakers to the application micro-services deployed in the Smart Edge Open cluster and to verify their resiliency.
 
 ### Delays
 
@@ -393,9 +393,9 @@ circuitBreaker:
 
 ## Prometheus, Grafana & Kiali integration
 
-Prometheus\* and Grafana\* are deployed in OpenNESS platform as part of the [Telemetry support in OpenNESS](../enhanced-platform-awareness/openness-telemetry.md) and are integrated with the Istio service mesh. When enabled in OpenNESS, Istio's scraping endpoints are added to the Prometheus configuration file according to the [Prometheus configuration guide](https://istio.io/latest/docs/ops/integrations/prometheus/).
+Prometheus\* and Grafana\* are deployed in Smart Edge Open platform as part of the [Telemetry support in Smart Edge Open](../enhanced-platform-awareness/smartedge-open-telemetry.md) and are integrated with the Istio service mesh. When enabled in Smart Edge Open, Istio's scraping endpoints are added to the Prometheus configuration file according to the [Prometheus configuration guide](https://istio.io/latest/docs/ops/integrations/prometheus/).
 
-Istio related metrics can be viewed on Grafana\* dashboard by defining a filtration criteria such as `istio_requests_total` that displays all requests made through the service mesh. It can be narrowed down to a specific service version e.g: `istio_requests_total{destination_service_name="reviews",destination_version="v1"}` as shown in the following figure. The same approach can be done on Prometheus\* dashboard. More details can be found in the [Grafana](../enhanced-platform-awareness/openness-telemetry.md#grafana) section.
+Istio related metrics can be viewed on Grafana\* dashboard by defining a filtration criteria such as `istio_requests_total` that displays all requests made through the service mesh. It can be narrowed down to a specific service version e.g: `istio_requests_total{destination_service_name="reviews",destination_version="v1"}` as shown in the following figure. The same approach can be done on Prometheus\* dashboard. More details can be found in the [Grafana](../enhanced-platform-awareness/smartedge-open-telemetry.md#grafana) section.
 
 ![Grafana example metric](./service-mesh-images/grafana-telemetry-rule.png)
 
@@ -421,7 +421,7 @@ _Figure - Istio Telemetry with Grafana_
 
 ### Enabling Service Mesh through enabling the Service Mesh Role
 
-Istio service mesh can be deployed with OpenNESS using the CEEK through the defined istio role. Istio role is enabled with setting parameter `ne_istio_enable: true`. Istio is installed with `default` profile by default (for Istio installation profiles refer to: https://istio.io/latest/docs/setup/additional-setup/config-profiles/).
+Istio service mesh can be deployed with Smart Edge Open using the CEEK through the defined istio role. Istio role is enabled with setting parameter `ne_istio_enable: true`. Istio is installed with `default` profile by default (for Istio installation profiles refer to: https://istio.io/latest/docs/setup/additional-setup/config-profiles/).
 The Istio management console, [Kiali](https://kiali.io/), is deployed alongside Istio with the default credentials:
 
 * Username: `admin`
@@ -443,7 +443,7 @@ istio_kiali_nodeport: 30001
 To get the randomly generated password run the following command on Kubernetes controller:
 `kubectl get secrets/kiali -n istio-system -o json | jq -r '.data.passphrase' | base64 -d`
 
-Prometheus and Grafana are deployed in the OpenNESS platform as part of the telemetry role and are integrated with the Istio service mesh.
+Prometheus and Grafana are deployed in the Smart Edge Open platform as part of the telemetry role and are integrated with the Istio service mesh.
 
 To verify if Istio resources are deployed and running, use the following command:
 
@@ -484,7 +484,7 @@ Users can change the namespace labeled with istio label using the parameter `ist
 * in `flavors/media-analytics/all.yml` for deployment with media-analytics flavor
 * in `inventory/default/group_vars/all/10-default.yml` for deployment with any flavor (and istio role enabled)
 
-> **NOTE**: The default OpenNESS network policy applies to pods in the `default` namespace and blocks all ingress traffic. Users must remove the default policy and apply custom network policy when deploying applications in the `default` namespace. Refer to the [Kubernetes NetworkPolicies](https://github.com/open-ness/specs/blob/master/doc/applications-onboard/network-edge-applications-onboarding.md#applying-kubernetes-network-policies) for an example policy allowing ingress traffic from `192.168.1.0/24` subnet on a specific port.
+> **NOTE**: The default Smart Edge Open network policy applies to pods in the `default` namespace and blocks all ingress traffic. Users must remove the default policy and apply custom network policy when deploying applications in the `default` namespace. Refer to the [Kubernetes NetworkPolicies](https://github.com/smart-edge-open/specs/blob/master/doc/applications-onboard/network-edge-applications-onboarding.md#applying-kubernetes-network-policies) for an example policy allowing ingress traffic from `192.168.1.0/24` subnet on a specific port.
 
 Kiali console is accessible from a browser using `http://<CONTROLLER_IP>:30001` and credentials defined in Converged Edge Experience Kits:
 
@@ -494,10 +494,10 @@ _Figure - Kiali Dashboard Login_
 
 ### Enabling Service Mesh with the Media Analytics Flavor
 
-The Istio service mesh is not enabled by default in OpenNESS. It can be installed alongside the video analytics services by setting the flag `ne_istio_enable` to `true` in the *media-analytics* flavor. The media analytics services are installed with the OpenNESS service mesh through the CEEK playbook as described in the [Media Analytics](../flavors.md#media-analytics-flavor) section.
+The Istio service mesh is not enabled by default in Smart Edge Open. It can be installed alongside the video analytics services by setting the flag `ne_istio_enable` to `true` in the *media-analytics* flavor. The media analytics services are installed with the Smart Edge Open service mesh through the CEEK playbook as described in the [Media Analytics](../flavors.md#media-analytics-flavor) section.
 
 ## References
 
 - [Istio Service Mesh](https://istio.io/)
 - [Service Mesh Interface](https://smi-spec.io/)
-- [OpenNESS Video Analytics Services](./openness_va_services.md)
+- [Smart Edge Open Video Analytics Services](./smartedge-open_va_services.md)
diff --git a/doc/applications/openness_va_services.md b/doc/applications/smartedge-open_va_services.md
similarity index 71%
rename from doc/applications/openness_va_services.md
rename to doc/applications/smartedge-open_va_services.md
index 0a6a28a7..602b1595 100644
--- a/doc/applications/openness_va_services.md
+++ b/doc/applications/smartedge-open_va_services.md
@@ -4,7 +4,7 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# OpenNESS Video Analytics Services
+# Smart Edge Open Video Analytics Services
 - [Overview](#overview)
 - [Getting Started with Video Analytics Services](#getting-started-with-video-analytics-services)
 - [Video Analytics Services Deployment](#video-analytics-services-deployment)
@@ -12,7 +12,7 @@ Copyright (c) 2020 Intel Corporation
 - [References](#references)
 
 ## Overview
-OpenNESS furnishes the Video Analytics Services to enable third-party edge applications to deploy and use hardware optimized video analytics pipelines. The OpenNESS Video Analytics Services are based on [Video Analytics Serving](https://github.com/intel/video-analytics-serving) that expose REStful APIs to start, stop, enumerate, and customize pre-defined pipelines using either [GStreamer\*](https://github.com/OpenVisualCloud/Dockerfiles/blob/master/doc/ffmpeg.md) or [FFmpeg\*](https://github.com/OpenVisualCloud/Dockerfiles/blob/master/doc/ffmpeg.md). Application vendors can create pipeline templates using their framework of choice, and Video Analytics Services will manage to launch pipeline instances based on the incoming requests.
+Smart Edge Open furnishes the Video Analytics Services to enable third-party edge applications to deploy and use hardware optimized video analytics pipelines. The Smart Edge Open Video Analytics Services are based on [Video Analytics Serving](https://github.com/intel/video-analytics-serving) that expose REStful APIs to start, stop, enumerate, and customize pre-defined pipelines using either [GStreamer\*](https://github.com/OpenVisualCloud/Dockerfiles/blob/master/doc/ffmpeg.md) or [FFmpeg\*](https://github.com/OpenVisualCloud/Dockerfiles/blob/master/doc/ffmpeg.md). Application vendors can create pipeline templates using their framework of choice, and Video Analytics Services will manage to launch pipeline instances based on the incoming requests.
 
 ## Getting Started with Video Analytics Services
 
@@ -37,9 +37,9 @@ The *VAS sidecar* interfaces with the Edge Application Agent (EAA) to register a
 
 _Figure - Video Analytics Services Deployment\*_
 
-> **\*NOTE**: Video Analytics Services acceleration through HDDL & VCAC-A are directional and are not currently supported in OpenNESS.
+> **\*NOTE**: Video Analytics Services acceleration through HDDL & VCAC-A are directional and are not currently supported in Smart Edge Open.
 
-Multiple instances of the Video Analytics Service can co-exist in an OpenNESS cluster depending on the available hardware resources, as depicted in the figure above. Standalone service endpoints are created for every multimedia framework and acceleration type.
+Multiple instances of the Video Analytics Service can co-exist in an Smart Edge Open cluster depending on the available hardware resources, as depicted in the figure above. Standalone service endpoints are created for every multimedia framework and acceleration type.
 
 Examples of Video Analytics Services are:
 - Video Analytics Service based on FFmpeg framework on CPU: `http://analytics-ffmpeg.media:8080`
@@ -50,7 +50,7 @@ Examples of Video Analytics Services are:
 - Video Analytics Service based on GStreamer framework executing on VCAC-A: `http://analytics-gstreamer-vca-a.media:8080`
 
 ## Consuming Video Analytics Services
-When consumer applications land on the OpenNESS cluster, they must authenticate through the [Edge Application Authentication API](https://www.openness.org/api-documentation/?api=auth) to continue subsequent interactions with EAA that are taking place over TLS. Applications receive a JSON-formatted list when querying the [service discovery API](https://www.openness.org/api-documentation/?api=eaa#/Eaa/GetServices) that give information on the available services including the Video Analytics Services. This information includes elements such as the service endpoint URI, acceleration type, underpinning multimedia framework, and the available pipelines. The Video Analytics Services-specific information is contained in the `"info"` element.
+When consumer applications land on the Smart Edge Open cluster, they must authenticate through the [Edge Application Authentication API](https://www.openness.org/api-documentation/?api=auth) to continue subsequent interactions with EAA that are taking place over TLS. Applications receive a JSON-formatted list when querying the [service discovery API](https://www.openness.org/api-documentation/?api=eaa#/Eaa/GetServices) that give information on the available services including the Video Analytics Services. This information includes elements such as the service endpoint URI, acceleration type, underpinning multimedia framework, and the available pipelines. The Video Analytics Services-specific information is contained in the `"info"` element.
 
 A sample service discovery JSON return is given below:
 ```json
@@ -96,4 +96,4 @@ _Figure - VAS Activation and Discovery through EAA_
 ## References
 * [Video Analytics Serving](https://github.com/intel/video-analytics-serving)
 * [Edge Application API](https://www.openness.org/api-documentation/?api=eaa)
-* [OpenNESS Application Development and Porting Guide](./openness_appguide.md)
+* [Smart Edge Open Application Development and Porting Guide](./smartedge-open_appguide.md)
diff --git a/doc/arch-images/openness-arc.png b/doc/arch-images/smartedge-open-arc.png
similarity index 100%
rename from doc/arch-images/openness-arc.png
rename to doc/arch-images/smartedge-open-arc.png
diff --git a/doc/arch-images/openness-emco.png b/doc/arch-images/smartedge-open-emco.png
similarity index 100%
rename from doc/arch-images/openness-emco.png
rename to doc/arch-images/smartedge-open-emco.png
diff --git a/doc/arch-images/openness-flexran.png b/doc/arch-images/smartedge-open-flexran.png
similarity index 100%
rename from doc/arch-images/openness-flexran.png
rename to doc/arch-images/smartedge-open-flexran.png
diff --git a/doc/arch-images/openness-ovc.png b/doc/arch-images/smartedge-open-ovc.png
similarity index 100%
rename from doc/arch-images/openness-ovc.png
rename to doc/arch-images/smartedge-open-ovc.png
diff --git a/doc/arch-images/openness_overview.png b/doc/arch-images/smartedge-open_overview.png
similarity index 100%
rename from doc/arch-images/openness_overview.png
rename to doc/arch-images/smartedge-open_overview.png
diff --git a/doc/architecture.md b/doc/architecture.md
index 219204fd..9593c3fd 100644
--- a/doc/architecture.md
+++ b/doc/architecture.md
@@ -3,13 +3,13 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019-2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# OpenNESS Architecture and Solution Overview
+# Smart Edge Open Architecture and Solution Overview
 
 - [Architecture Overview](#architecture-overview)
   - [Logical](#logical)
   - [Architecture](#architecture)
-    - [OpenNESS Kubernetes Control Plane](#openness-kubernetes-control-plane)
-    - [OpenNESS Edge Node](#openness-edge-node)
+    - [Smart Edge Open Kubernetes Control Plane](#smart-edge-open-kubernetes-control-plane)
+    - [Smart Edge Open Edge Node](#smart-edge-open-edge-node)
 - [Building Blocks, Kubernetes Extensions, and Enhancements](#building-blocks-kubernetes-extensions-and-enhancements)
   - [Multi-Access Networking](#multi-access-networking)
   - [Edge Multi-Cluster Orchestration](#edge-multi-cluster-orchestration)
@@ -24,49 +24,49 @@ Copyright (c) 2019-2020 Intel Corporation
   - [Edge Services](#edge-services)
   - [Software Development Kits](#software-development-kits)
 - [Converged Edge Reference Architecture](#converged-edge-reference-architecture)
-  - [CERA Minimal Flavor](#cera-minimal-flavor)
-  - [CERA Access Edge Flavor](#cera-access-edge-flavor)
-  - [CERA Near Edge Flavor](#cera-near-edge-flavor)
-  - [CERA SD-WAN Edge Flavor](#cera-sd-wan-edge-flavor)
-  - [CERA SD-WAN Hub Flavor](#cera-sd-wan-hub-flavor)
-  - [CERA Media Analytics Flavor with VCAC-A](#cera-media-analytics-flavor-with-vcac-a)
-  - [CERA Media Analytics Flavor](#cera-media-analytics-flavor)
-  - [CERA CDN Transcode Flavor](#cera-cdn-transcode-flavor)
-  - [CERA CDN Caching Flavor](#cera-cdn-caching-flavor)
-  - [CERA Core Control Plane Flavor](#cera-core-control-plane-flavor)
-  - [CERA Core User Plane Flavor](#cera-core-user-plane-flavor)
-  - [CERA for Untrusted Non-3GPP Access Flavor](#cera-for-untrusted-non-3gpp-access-flavor)
+  - [Smart Edge Open Experience Kit Minimal Flavor](#smart-edge-open-experience-kit-minimal-flavor)
+  - [Smart Edge Open Experience Kit Access Edge Flavor](#smart-edge-open-experience-kit-access-edge-flavor)
+  - [Smart Edge Open Experience Kit Near Edge Flavor](#smart-edge-open-experience-kit-near-edge-flavor)
+  - [Smart Edge Open Experience Kit SD-WAN Edge Flavor](#smart-edge-open-experience-kit-sd-wan-edge-flavor)
+  - [Smart Edge Open Experience Kit SD-WAN Hub Flavor](#smart-edge-open-experience-kit-sd-wan-hub-flavor)
+  - [Smart Edge Open Experience Kit Media Analytics Flavor with VCAC-A](#smart-edge-open-experience-kit-media-analytics-flavor-with-vcac-a)
+  - [Smart Edge Open Experience Kit Media Analytics Flavor](#smart-edge-open-experience-kit-media-analytics-flavor)
+  - [Smart Edge Open Experience Kit CDN Transcode Flavor](#smart-edge-open-experience-kit-cdn-transcode-flavor)
+  - [Smart Edge Open Experience Kit CDN Caching Flavor](#smart-edge-open-experience-kit-cdn-caching-flavor)
+  - [Smart Edge Open Experience Kit Core Control Plane Flavor](#smart-edge-open-experience-kit-core-control-plane-flavor)
+  - [Smart Edge Open Experience Kit Core User Plane Flavor](#smart-edge-open-experience-kit-core-user-plane-flavor)
+  - [Smart Edge Open Experience Kit for Untrusted Non-3GPP Access Flavor](#smart-edge-open-experience-kit-for-untrusted-non-3gpp-access-flavor)
 - [Reference Edge Apps and Network Functions](#reference-edge-apps-and-network-functions)
-- [OpenNESS Optimized Commercial Applications](#openness-optimized-commercial-applications)
-  - [OpenNESS DevKit for Microsoft Azure](#openness-devkit-for-microsoft-azure)
+- [Smart Edge Open Optimized Commercial Applications](#smart-edge-open-optimized-commercial-applications)
+  - [Smart Edge Open DevKit for Microsoft Azure](#smart-edge-open-devkit-for-microsoft-azure)
 - [Other References](#other-references)
 - [List of Abbreviations](#list-of-abbreviations)
 
 ## Architecture Overview 
 
-Before reviewing the detailed architecture overview of OpenNESS, take a look at the logical overview of how the OpenNESS Building Blocks are laid out. 
+Before reviewing the detailed architecture overview of Smart Edge Open, take a look at the logical overview of how the Smart Edge Open Building Blocks are laid out. 
 
 ### Logical 
 
-The OpenNESS solution is built on top of Kubernetes, which is a production-grade container orchestration environment. A typical OpenNESS-based deployment consists of an **OpenNESS Kubernetes Control Plane** and an **OpenNESS Edge Node**.
+The Smart Edge Open solution is built on top of Kubernetes, which is a production-grade container orchestration environment. A typical Smart Edge Open-based deployment consists of an **Smart Edge Open Kubernetes Control Plane** and an **Smart Edge Open Edge Node**.
 
-![](arch-images/openness_overview.png)
+![](arch-images/smartedge-open_overview.png)
 
-**OpenNESS Kubernetes Control Plane**: This node consists of microservices and Kubernetes extensions, enhancements, and optimizations that provide the functionality to configure one or more OpenNESS Edge Nodes and the application services that run on those nodes (Application Pod Placement, Configuration of Core Network, etc). 
+**Smart Edge Open Kubernetes Control Plane**: This node consists of microservices and Kubernetes extensions, enhancements, and optimizations that provide the functionality to configure one or more Smart Edge Open Edge Nodes and the application services that run on those nodes (Application Pod Placement, Configuration of Core Network, etc). 
 
-**OpenNESS Edge Node**: This node consists of microservices and Kubernetes extensions, enhancements, and optimizations that are needed for edge application and network function deployments. It also consists of APIs that are often used for the discovery of application services. 
+**Smart Edge Open Edge Node**: This node consists of microservices and Kubernetes extensions, enhancements, and optimizations that are needed for edge application and network function deployments. It also consists of APIs that are often used for the discovery of application services. 
 
-Another key ingredient is the 4G/5G core network functions that enable a private or public edge. OpenNESS uses reference network functions to validate this end-to-end edge deployment. This is key to understanding and measuring edge Key Performance Indicators (KPIs).  
+Another key ingredient is the 4G/5G core network functions that enable a private or public edge. Smart Edge Open uses reference network functions to validate this end-to-end edge deployment. This is key to understanding and measuring edge Key Performance Indicators (KPIs).  
 
 ### Architecture 
 
-![](arch-images/openness-arc.png)
+![](arch-images/smartedge-open-arc.png)
 
-#### OpenNESS Kubernetes Control Plane
+#### Smart Edge Open Kubernetes Control Plane
 
-The OpenNESS Kubernetes Control Plane consists of Vanilla Kubernetes Control Plane components along with OpenNESS microservices that interact with the Kubernetes Control Plane using Kubernetes defined APIs. 
+The Smart Edge Open Kubernetes Control Plane consists of Vanilla Kubernetes Control Plane components along with Smart Edge Open microservices that interact with the Kubernetes Control Plane using Kubernetes defined APIs. 
 
-The following are the high-level features of the OpenNESS Kubernetes Control Plane building blocks:
+The following are the high-level features of the Smart Edge Open Kubernetes Control Plane building blocks:
 
 - Configuration of the hardware platform that hosts applications and network functions 
 - Configuration of network functions (4G, 5G, and WiFi\*)
@@ -75,11 +75,11 @@ The following are the high-level features of the OpenNESS Kubernetes Control Pla
 - Enable collection of hardware infrastructure, software, and application monitoring 
 - Expose edge cluster capabilities northbound to a controller
 
-#### OpenNESS Edge Node 
+#### Smart Edge Open Edge Node 
 
-The OpenNESS Edge Node consists of Vanilla Kubernetes Node components along with OpenNESS Building Blocks that interact with Kubernetes node using Kubernetes defined APIs.
+The Smart Edge Open Edge Node consists of Vanilla Kubernetes Node components along with Smart Edge Open Building Blocks that interact with Kubernetes node using Kubernetes defined APIs.
 
-The following are the high-level features of the OpenNESS Kubernetes node building blocks:
+The following are the high-level features of the Smart Edge Open Kubernetes node building blocks:
 
 - Container runtime (Docker\*) and virtualization infrastructure (libvirt\*, Open vSwitch (OVS)\*, etc.) support
 - Platform pods consisting of services that enable the configuration of a node for a particular deployment, device plugins enabling hardware resource allocation to an application pod, and detection of interfaces and reporting to the Control Plane.
@@ -87,61 +87,61 @@ The following are the high-level features of the OpenNESS Kubernetes node buildi
 - Telemetry consisting of services that enable hardware, operating system, infrastructure, and application-level telemetry for the edge node 
 - Support for real-time kernel for low latency applications and network functions like 4G and 5G base station and non-real-time kernel 
 
-The OpenNESS Network functions are the key 4G and 5G functions that enable edge cloud deployment. OpenNESS provides these key reference network functions and the configuration agent in the Intel Distribution of OpenNESS.  
+The Smart Edge Open Network functions are the key 4G and 5G functions that enable edge cloud deployment. Smart Edge Open provides these key reference network functions and the configuration agent in the Intel Distribution of Smart Edge Open.  
 
-The OpenNESS solution validates the functionality and performance of key software development kits used for applications and network functions at the edge. This spans across edge applications that use Intel® Media SDK, OpenVINO™, Intel® Math Kernel Library (Intel® MKL), etc. and network functions that use Data Plane Development Kit (DPDK), Intel® Performance Primitives, Intel® MKL, OpenMP\*, OpenCL\*, etc.
+The Smart Edge Open solution validates the functionality and performance of key software development kits used for applications and network functions at the edge. This spans across edge applications that use Intel® Media SDK, OpenVINO™, Intel® Math Kernel Library (Intel® MKL), etc. and network functions that use Data Plane Development Kit (DPDK), Intel® Performance Primitives, Intel® MKL, OpenMP\*, OpenCL\*, etc.
 
 ## Building Blocks, Kubernetes Extensions, and Enhancements
 
-This section provides of an overview of the various OpenNESS Building Blocks, extensions to Kubernetes and enhancements to other open source frameworks required for the development of Edge platforms. These building blocks span across the system and platform pods discussed earlier. Many are provided as Helm charts.
+This section provides of an overview of the various Smart Edge Open Building Blocks, extensions to Kubernetes and enhancements to other open source frameworks required for the development of Edge platforms. These building blocks span across the system and platform pods discussed earlier. Many are provided as Helm charts.
 
 ### Multi-Access Networking
 
 This building block represents a set of microservices that enables steering of traffic from various access networks to and from edge apps and services. 
 
-- **Application Function (AF):** is a microservice in the OpenNESS Kubernetes Control Plane that supports Traffic Influencing Subscription, Packet Flow Description Management functionality, and Policy Authorization to help steer the Edge-specific traffic in UPF towards the applications deployed on the OpenNESS edge node. AF is developed as per the Rel.15 3gpp specifications. AF is only available in the Intel Distribution of OpenNESS.  
-- **Network Exposure Function (NEF)**: is a microservice used for validation of AF functionality in OpenNESS before integrating with the 5G Core.  The functionality is limited and in line with the AF functional scope. It includes a reference implementation for Traffic influence and PFD management. NEF is developed as per the Rel.15 3gpp specifications. NEF is only available in the Intel Distribution of OpenNESS. 
-- **Core Network Configuration Agent (CNCA)**: is a microservice that provides an interface for orchestrators that interact with OpenNESS Kubernetes Control Plane to interact with the 5G Core network solution. CNCA provides a CLI (kube-ctl plugin) interface to interact with the AF and OAM services. CNCA is only available in the Intel Distribution of OpenNESS.
+- **Application Function (AF):** is a microservice in the Smart Edge Open Kubernetes Control Plane that supports Traffic Influencing Subscription, Packet Flow Description Management functionality, and Policy Authorization to help steer the Edge-specific traffic in UPF towards the applications deployed on the Smart Edge Open edge node. AF is developed as per the Rel.15 3gpp specifications. AF is only available in the Intel Distribution of Smart Edge Open.  
+- **Network Exposure Function (NEF)**: is a microservice used for validation of AF functionality in Smart Edge Open before integrating with the 5G Core.  The functionality is limited and in line with the AF functional scope. It includes a reference implementation for Traffic influence and PFD management. NEF is developed as per the Rel.15 3gpp specifications. NEF is only available in the Intel Distribution of Smart Edge Open. 
+- **Core Network Configuration Agent (CNCA)**: is a microservice that provides an interface for orchestrators that interact with Smart Edge Open Kubernetes Control Plane to interact with the 5G Core network solution. CNCA provides a CLI (kube-ctl plugin) interface to interact with the AF and OAM services. CNCA is only available in the Intel Distribution of Smart Edge Open.
 - **Edge Application Agent (EAA)**: Edge application APIs are implemented by the EAA. Edge application APIs are important APIs for edge application developers. EAA APIs provide APIs for service discovery, subscription, and update notification. EAA APIs are based on ETSI MEC- MEC11 MP1 APIs specifications.
-- **Edge Interface Service**: This service is an application that runs in a Kubernetes pod on each node of the OpenNESS Kubernetes cluster. It allows attachment of additional network interfaces of the node host to provide an OVS bridge, enabling external traffic scenarios for applications deployed in Kubernetes pods. Services on each node can be controlled from the Control Plane using a kubectl plugin. This interface service can attach both kernel and userspace (DPDK) network interfaces to OVS bridges of a suitable type.
+- **Edge Interface Service**: This service is an application that runs in a Kubernetes pod on each node of the Smart Edge Open Kubernetes cluster. It allows attachment of additional network interfaces of the node host to provide an OVS bridge, enabling external traffic scenarios for applications deployed in Kubernetes pods. Services on each node can be controlled from the Control Plane using a kubectl plugin. This interface service can attach both kernel and userspace (DPDK) network interfaces to OVS bridges of a suitable type.
 - **DNS Service**: Supports DNS resolution and forwarding services for the application deployed on edge computing. The DNS server is implemented based on the DNS library in Go. DNS service supports resolving DNS requests from user equipment (UE) and applications on the edge cloud.  
 
 ### Edge Multi-Cluster Orchestration
 
 Edge Multi-Cluster Orchestration(EMCO), is a Geo-distributed application orchestrator for Kubernetes*. The main objective of EMCO is automation of the deployment of applications and services across clusters. It acts as a central orchestrator that can manage edge services and network functions across geographically distributed edge clusters from different third parties. Finally, the resource orchestration within a cluster of nodes will leverage Kubernetes* and Helm charts.
 
-![](arch-images/openness-emco.png)
+![](arch-images/smartedge-open-emco.png)
 
-Link: [EMCO](https://github.com/open-ness/specs/blob/master/doc/building-blocks/emco/openness-emco.md)
+Link: [EMCO](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/emco/smartedge-open-emco.md)
 ### Resource Management
 
 Resource Management represents a methodology which involves identification of the hardware and software resources on the edge cluster, Configuration and allocation of the resources and continuous monitoring of the resources for any changes.
 
 ![](arch-images/resource.png)
 
-OpenNESS provides set of enhancements across multiple layers of the orchestration stack, targeting identification of platform capabilities as well as configuration and capacity consumption. 
+Smart Edge Open provides set of enhancements across multiple layers of the orchestration stack, targeting identification of platform capabilities as well as configuration and capacity consumption. 
 
 Why should users consider using Resource Management? To achieve optimal performance and efficiency characteristics. Resource Management extensions facilitate the automation of an advanced selection of capabilities and tuning parameters during the deployment of cloud-native solutions. Resource Management also enables service providers to offer differentiating and/or revenue-generating services that require leveraging specific hardware features.
 
-OpenNESS provides a complete solution for users to integrate key resource management features needed for applications (CDN, AI inference, transcoding, gaming, etc.) and CNFs (RAN DU, CU, and Core) to work optimally for edge deployments.
+Smart Edge Open provides a complete solution for users to integrate key resource management features needed for applications (CDN, AI inference, transcoding, gaming, etc.) and CNFs (RAN DU, CU, and Core) to work optimally for edge deployments.
 
 #### Resource Identification
 
-Resource identification involves detecting key hardware and software features on the platform that can be used for scheduling of the workload on the cluster. OpenNESS support Node Feature Discovery (NFD) microservices that detects hardware and software features and labels the nodes with relevant features. 
+Resource identification involves detecting key hardware and software features on the platform that can be used for scheduling of the workload on the cluster. Smart Edge Open support Node Feature Discovery (NFD) microservices that detects hardware and software features and labels the nodes with relevant features. 
 
 #### Resource Allocation
 
-Resource Allocation involves configuration of the certain hardware resources like CPU, IO devices, GPU, Accelerator devices, Memory (Hugepages) etc.. to the applications and services. OpenNESS provides many Device Plugins, Kubernetes jobs, CRD Operators and Red Hat OpenShift Operator: Special Resource Operators for configuration and resource allocation of VPU, GPU, FPGA, CPU L3 cache, Memory bandwidth resources to applications and services. 
+Resource Allocation involves configuration of the certain hardware resources like CPU, IO devices, GPU, Accelerator devices, Memory (Hugepages) etc.. to the applications and services. Smart Edge Open provides many Device Plugins, Kubernetes jobs, CRD Operators and Red Hat OpenShift Operator: Special Resource Operators for configuration and resource allocation of VPU, GPU, FPGA, CPU L3 cache, Memory bandwidth resources to applications and services. 
 
 #### Resource Monitoring
 
-Resource monitoring involves tracking the usage of allocated resources to the applications and services and also tracking the remaining allocatable resources. OpenNESS provides collectors, node exporters using collectd, telegraf and custom exporters as part of telemetry and monitoring of current resource usage. Resource monitoring support is provided for CPU, VPU, FPGA AND Memory.
+Resource monitoring involves tracking the usage of allocated resources to the applications and services and also tracking the remaining allocatable resources. Smart Edge Open provides collectors, node exporters using collectd, telegraf and custom exporters as part of telemetry and monitoring of current resource usage. Resource monitoring support is provided for CPU, VPU, FPGA AND Memory.
 
-Link: [Enhanced Platform Awareness: Documents covering Accelerators and Resource Management](https://github.com/open-ness/specs/tree/master/doc/building-blocks/enhanced-platform-awareness)
+Link: [Enhanced Platform Awareness: Documents covering Accelerators and Resource Management](https://github.com/smart-edge-open/specs/tree/master/doc/building-blocks/enhanced-platform-awareness)
 
 ### Accelerators
 
-OpenNESS supports the following accelerator microservices.
+Smart Edge Open supports the following accelerator microservices.
 
 - <b>High-Density Deep Learning (HDDL)</b>: Software that enables OpenVINO™-based AI apps to run on Intel® Movidius™ Vision Processing Units (VPUs). It consists of the following components:
   - HDDL device plugin for K8s
@@ -160,14 +160,14 @@ OpenNESS supports the following accelerator microservices.
 
 ### Dataplane/Container Network Interfaces
 
-OpenNESS provides a flexible and high-performance set of container networking using Container Networking Interfaces (CNIs). Some of the high-performance, open-source CNIs are also supported. 
+Smart Edge Open provides a flexible and high-performance set of container networking using Container Networking Interfaces (CNIs). Some of the high-performance, open-source CNIs are also supported. 
 
-Container networking support in OpenNESS addresses the following: 
+Container networking support in Smart Edge Open addresses the following: 
 
 - Highly-coupled, container-to-container communications
 - Pod-to-pod communications on the same node and across the nodes 
 
-OpenNESS supports the following CNIs:
+Smart Edge Open supports the following CNIs:
 
 - <b>SRIOV CNI</b>: works with the SR-IOV device plugin for VF allocation for a container. 
 - <b>User Space CNI</b>: designed to implement userspace networking (as opposed to kernel space networking). 
@@ -177,19 +177,19 @@ OpenNESS supports the following CNIs:
 - <b>Kube-OVN CNI</b>: integrates the OVN-based network virtualization with Kubernetes. It offers an advanced container network fabric for enterprises with the most functions and the easiest operation.
 - <b>Calico CNI/eBPF</b>: supports applications with higher performance using eBPF and IPv4/IPv6 dual-stack
 
-Link: [Dataplane and CNI](https://github.com/open-ness/specs/tree/master/doc/building-blocks/dataplane)
+Link: [Dataplane and CNI](https://github.com/smart-edge-open/specs/tree/master/doc/building-blocks/dataplane)
 
 ### Edge Aware Service Mesh 
 
-Istio is a feature-rich, cloud-native service mesh platform that provides a collection of key capabilities such as: Traffic Management, Security and Observability uniformly across a network of services. OpenNESS integrates natively with the Istio service mesh to help reduce the complexity of large scale edge applications, services, and network functions. 
+Istio is a feature-rich, cloud-native service mesh platform that provides a collection of key capabilities such as: Traffic Management, Security and Observability uniformly across a network of services. Smart Edge Open integrates natively with the Istio service mesh to help reduce the complexity of large scale edge applications, services, and network functions. 
 
-Link: [Service Mesh](https://github.com/open-ness/specs/blob/master/doc/applications/openness_service_mesh.md)
+Link: [Service Mesh](https://github.com/smart-edge-open/specs/blob/master/doc/applications/smartedge-open_service_mesh.md)
 
 ### Telemetry and Monitoring
 
 Edge builders need a comprehensive telemetry framework that combines application telemetry, hardware telemetry, and events to create a heat-map across the edge cluster and enables the orchestrator to make scheduling decisions.
 
-Industry-leading, cloud-native telemetry and monitoring frameworks are supported on OpenNESS:
+Industry-leading, cloud-native telemetry and monitoring frameworks are supported on Smart Edge Open:
 
 - <b>Prometheus\* and Grafana\*</b>: This is a cloud-native, industry-standard framework that provides a monitoring system and time series database. 
 - <b>Telegraf</b> This is a cloud-native, industry-standard agent for collecting, processing, aggregating, and writing metrics.
@@ -201,7 +201,7 @@ Hardware Telemetry support:
 - Dataplane: Supported metrics - ovs_stats and ovs_pmd_stats
 - Accelerator: Supported Metrics from - FPGA–PAC-N3000, VCAC-A, HDDL-R, eASIC, GPU, and NIC
 
-OpenNESS also supports a reference application of using telemetry to take actions using Kubernetes APIs. This reference is provided to the Telemetry Aware Scheduler project. 
+Smart Edge Open also supports a reference application of using telemetry to take actions using Kubernetes APIs. This reference is provided to the Telemetry Aware Scheduler project. 
 
 ### Edge Services 
 
@@ -211,7 +211,7 @@ These building blocks are included as part of System pods.
 
 ### Software Development Kits 
 
-OpenNESS supports leading SDKs for edge services (applications) and network function development. As part of the development of OpenNESS, applications developed using these SDKs are optimized to provide optimal performance. This ensures that when customers develop applications using these SDKs, they can achieve optimal performance. 
+Smart Edge Open supports leading SDKs for edge services (applications) and network function development. As part of the development of Smart Edge Open, applications developed using these SDKs are optimized to provide optimal performance. This ensures that when customers develop applications using these SDKs, they can achieve optimal performance. 
 
 - <b> OpenVINO™ SDK </b>: The OpenVINO™ toolkit is composed of a variety of tools from Intel that work together to provide a complete computer vision pipeline solution that is optimized on Intel® architecture. This article will focus on the Intel® Media SDK component of the toolkit. The Intel Media SDK is a high-level API for specific video processing operations: decode, process, and encode. It supports H.265, H.264, MPEG-2, and more codecs. Video processing can be used to resize, scale, de-interlace, color conversion, de-noise, sharpen, and more. The Intel Media SDK works in the background to leverage hardware acceleration on Intel® architecture with optimized software fallback for each hardware platform. Thus, developers do not need to change the code from platform to platform and can focus more on the application itself rather than on hardware optimization.
 - <b> Intel Media SDK </b>: SDK used for developing video applications with state-of-the-art libraries, tools, and samples. They are all accessible via a single API that enables hardware acceleration for fast video transcoding, image processing, and media workflows. The two main paths for application developers to access GPU media processing capabilities are Intel® Media SDK and Intel® SDK for OpenCL™ applications.
@@ -223,65 +223,65 @@ OpenNESS supports leading SDKs for edge services (applications) and network func
 
 ## Converged Edge Reference Architecture 
 
-Converged Edge Reference Architecture (CERA) is a set of pre-integrated & readily deployable HW/SW Reference Architectures powered by OpenNESS to significantly accelerate Edge Platform development. 
+Converged Edge Reference Architecture (Smart Edge Open Experience Kit) is a set of pre-integrated & readily deployable HW/SW Reference Architectures powered by Smart Edge Open to significantly accelerate Edge Platform development. 
 
-OpenNESS includes an Ansible\* playbook that acts as a single interface for users to deploy various types of CERAs. The playbook organizes all of the above microservices, Kubernetes extensions, enhancements, and optimizations under easy to deploy node types called <b>flavors</b>, implemented as Ansible roles.
+Smart Edge Open includes an Ansible\* playbook that acts as a single interface for users to deploy various types of Smart Edge Open Experience Kits. The playbook organizes all of the above microservices, Kubernetes extensions, enhancements, and optimizations under easy to deploy node types called <b>flavors</b>, implemented as Ansible roles.
 
 For example, a user deploying a network edge at a cell site can choose the Access Edge flavor to deploy a node with all the microservices, Kubernetes extensions, enhancements, and optimizations required for a RAN node. 
 
-### CERA Minimal Flavor  
+### Smart Edge Open Experience Kit Minimal Flavor  
 
-This flavor supports the installation of the minimal set of components from OpenNESS and, it is typically used as a starting point for creating a custom node. 
+This flavor supports the installation of the minimal set of components from Smart Edge Open and, it is typically used as a starting point for creating a custom node. 
 
-### CERA Access Edge Flavor 
+### Smart Edge Open Experience Kit Access Edge Flavor 
 
 This flavor typically refers to RAN Distributed Unit (DU) and Centralized Unit (CU) 4G/5G nodes deployed on the access edge. In some cases, DU may be integrated into the radio. The example RAN deployment flavor uses FlexRAN as a reference DU. 
 
-Link: [CERA Access Edge Overview](reference-architectures/ran/openness_ran.md)
+Link: [Smart Edge Open Experience Kit Access Edge Overview](reference-architectures/ran/smartedge-open_ran.md)
 
-### CERA Near Edge Flavor
+### Smart Edge Open Experience Kit Near Edge Flavor
 
-Available in Intel Distribution of OpenNESS
+Available in Intel Distribution of Smart Edge Open
 
-### CERA SD-WAN Edge Flavor
+### Smart Edge Open Experience Kit SD-WAN Edge Flavor
 
-Available in Intel Distribution of OpenNESS
+Available in Intel Distribution of Smart Edge Open
 
-### CERA SD-WAN Hub Flavor
+### Smart Edge Open Experience Kit SD-WAN Hub Flavor
 
-Available in Intel Distribution of OpenNESS
+Available in Intel Distribution of Smart Edge Open
 
-### CERA Media Analytics Flavor with VCAC-A
+### Smart Edge Open Experience Kit Media Analytics Flavor with VCAC-A
 
-CERA Media Analytics Flavor provides Kubernetes enhancements for High performance compute, VPU and GPU offload device plugins for Intel VCAC-A card. This flavor can be tested using the Smart City reference app available in OpenNESS. 
+Smart Edge Open Experience Kit Media Analytics Flavor provides Kubernetes enhancements for High performance compute, VPU and GPU offload device plugins for Intel VCAC-A card. This flavor can be tested using the Smart City reference app available in Smart Edge Open. 
 
-### CERA Media Analytics Flavor
+### Smart Edge Open Experience Kit Media Analytics Flavor
 
-CERA Media Analytics Flavor is similar to the CERA Media Analytics Flavor with VCAC-A except the Analytics pipeline runs on the Intel CPU rather than the Intel VCAC-A card. This flavor can be tested using the Smart City reference app available in OpenNESS. 
+Smart Edge Open Experience Kit Media Analytics Flavor is similar to the Smart Edge Open Experience Kit Media Analytics Flavor with VCAC-A except the Analytics pipeline runs on the Intel CPU rather than the Intel VCAC-A card. This flavor can be tested using the Smart City reference app available in Smart Edge Open. 
 
-### CERA CDN Transcode Flavor
+### Smart Edge Open Experience Kit CDN Transcode Flavor
 
-CERA for CDN transcode flavor provides key OpenNESS Kubernetes enhancements for high performance compute. The flavor can be tested using the CDN Transcode Sample which is an Open Visual Cloud software stack with all required open source ingredients well integrated to provide out-of-box CDN media transcode service, including live streaming and video on demand. It also provides Docker-based media delivery software development environment upon which developer can easily build their specific applications.
+Smart Edge Open Experience Kit for CDN transcode flavor provides key Smart Edge Open Kubernetes enhancements for high performance compute. The flavor can be tested using the CDN Transcode Sample which is an Open Visual Cloud software stack with all required open source ingredients well integrated to provide out-of-box CDN media transcode service, including live streaming and video on demand. It also provides Docker-based media delivery software development environment upon which developer can easily build their specific applications.
 
-### CERA CDN Caching Flavor
+### Smart Edge Open Experience Kit CDN Caching Flavor
 
-CERA for CDN transcode flavor provides key OpenNESS Kubernetes enhancements for high performance Networking using SR-IOV, NVMe and SSD device support. The flavor can be tested using the CDN Caching sample application in OpenNESS. 
+Smart Edge Open Experience Kit for CDN transcode flavor provides key Smart Edge Open Kubernetes enhancements for high performance Networking using SR-IOV, NVMe and SSD device support. The flavor can be tested using the CDN Caching sample application in Smart Edge Open. 
 
-### CERA Core Control Plane Flavor
+### Smart Edge Open Experience Kit Core Control Plane Flavor
 
-Available in Intel Distribution of OpenNESS
+Available in Intel Distribution of Smart Edge Open
 
-### CERA Core User Plane Flavor 
+### Smart Edge Open Experience Kit Core User Plane Flavor 
 
-Available in Intel Distribution of OpenNESS
+Available in Intel Distribution of Smart Edge Open
 
-### CERA for Untrusted Non-3GPP Access Flavor 
+### Smart Edge Open Experience Kit for Untrusted Non-3GPP Access Flavor 
 
-Available in Intel Distribution of OpenNESS
+Available in Intel Distribution of Smart Edge Open
 
 ## Reference Edge Apps and Network Functions  
 
-OpenNESS supports a rich set of reference and commercial real-world edge services (applications) and network functions. These applications and network functions are a vehicle for validating functionality and performance KPIs for Edge. 
+Smart Edge Open supports a rich set of reference and commercial real-world edge services (applications) and network functions. These applications and network functions are a vehicle for validating functionality and performance KPIs for Edge. 
 
 The following is a subset of supported edge applications: 
 
@@ -293,14 +293,14 @@ The following is a subset of supported reference network functions:
 
 - <b>gNodeB or eNodeB</b>: 5G or 4G base station implementation on Intel architecture based on Intel’s FlexRAN.
 
-Link: [Documents covering OpenNESS supported Reference Architectures](https://github.com/open-ness/specs/tree/master/doc/reference-architectures)
-## OpenNESS Optimized Commercial Applications 
+Link: [Documents covering Smart Edge Open supported Reference Architectures](https://github.com/smart-edge-open/specs/tree/master/doc/reference-architectures)
+## Smart Edge Open Optimized Commercial Applications 
 
-OpenNESS Optimized Commercial applications are available at [Intel® Network Builders](https://networkbuilders.intel.com/commercial-applications)
+Smart Edge Open Optimized Commercial applications are available at [Intel® Network Builders](https://networkbuilders.intel.com/commercial-applications)
 
-### OpenNESS DevKit for Microsoft Azure 
+### Smart Edge Open DevKit for Microsoft Azure 
 
-This devkit supports the installation of an OpenNESS Kubernetes cluster on a Microsoft* Azure* VM. This is typically used by a customer who want to develop applications and services for the edge using OpenNESS building blocks.
+This devkit supports the installation of an Smart Edge Open Kubernetes cluster on a Microsoft* Azure* VM. This is typically used by a customer who want to develop applications and services for the edge using Smart Edge Open building blocks.
 
 ## Other References
 
@@ -366,4 +366,4 @@ This devkit supports the installation of an OpenNESS Kubernetes cluster on a Mic
 | UE       | User Equipment (in the context of LTE)          |
 | UPF      | User Plane Function                             |
 | UUID     | Universally Unique IDentifier                   |
-| VIM      | Virtual Infrastructure Manager                  |
+| VIM      | Virtual Infrastructure Manager                  |
\ No newline at end of file
diff --git a/doc/building-blocks/dataplane/index.html b/doc/building-blocks/dataplane/index.html
index 4d855fd9..4d973d2c 100644
--- a/doc/building-blocks/dataplane/index.html
+++ b/doc/building-blocks/dataplane/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
-window.location = "openness-interapp"
+window.location = "smartedge-open-interapp"
 </script>
diff --git a/doc/building-blocks/dataplane/ovn_images/openness_ovn.png b/doc/building-blocks/dataplane/ovn_images/smartedge-open_ovn.png
similarity index 100%
rename from doc/building-blocks/dataplane/ovn_images/openness_ovn.png
rename to doc/building-blocks/dataplane/ovn_images/smartedge-open_ovn.png
diff --git a/doc/building-blocks/dataplane/ovn_images/openness_ovnovs.png b/doc/building-blocks/dataplane/ovn_images/smartedge-open_ovnovs.png
similarity index 100%
rename from doc/building-blocks/dataplane/ovn_images/openness_ovnovs.png
rename to doc/building-blocks/dataplane/ovn_images/smartedge-open_ovnovs.png
diff --git a/doc/building-blocks/dataplane/openness-interapp.md b/doc/building-blocks/dataplane/smartedge-open-interapp.md
similarity index 62%
rename from doc/building-blocks/dataplane/openness-interapp.md
rename to doc/building-blocks/dataplane/smartedge-open-interapp.md
index 4f16371a..0d1eeb82 100644
--- a/doc/building-blocks/dataplane/openness-interapp.md
+++ b/doc/building-blocks/dataplane/smartedge-open-interapp.md
@@ -3,19 +3,19 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019 Intel Corporation
 ```
 <!-- omit in toc -->
-# InterApp Communication Support in OpenNESS
+# InterApp Communication Support in Smart Edge Open
 - [Overview](#overview)
-- [InterApp Communication support in OpenNESS Network Edge](#interapp-communication-support-in-openness-network-edge)
+- [InterApp Communication support in Smart Edge Open Network Edge](#interapp-communication-support-in-smart-edge-open-network-edge)
 
 ## Overview
 
-Multi-core edge cloud platforms typically host multiple containers or virtual machines as PODs. These applications sometimes need to communicate with each other as part of a service or consuming services from another application instance. This means that an edge cloud platform should provide not just the data plane interface (to enable user data transfer to and from clients) but also the infrastructure to enable applications to communicate with each other whether they are on the same platform or spanning across multiple platforms. OpenNESS provides the infrastructure for both in the network edge mode.
+Multi-core edge cloud platforms typically host multiple containers or virtual machines as PODs. These applications sometimes need to communicate with each other as part of a service or consuming services from another application instance. This means that an edge cloud platform should provide not just the data plane interface (to enable user data transfer to and from clients) but also the infrastructure to enable applications to communicate with each other whether they are on the same platform or spanning across multiple platforms. Smart Edge Open provides the infrastructure for both in the network edge mode.
 
 >**NOTE**: The InterApps Communication mentioned here is not just for applications but it is also applicable for Network functions (Core Network User plane, Base station, etc.).
 
-## InterApp Communication support in OpenNESS Network Edge
+## InterApp Communication support in Smart Edge Open Network Edge
 
-InterApp communication on the OpenNESS Network Edge is supported using Open Virtual Network for Open vSwitch [OVN/OVS](https://github.com/open-ness/specs/blob/master/doc/building-blocks/dataplane/openness-ovn.md) as the infrastructure. OVN/OVS in the network edge is supported through the Kubernetes kube-OVN Container Network Interface (CNI).
+InterApp communication on the Smart Edge Open Network Edge is supported using Open Virtual Network for Open vSwitch [OVN/OVS](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/dataplane/smartedge-open-ovn.md) as the infrastructure. OVN/OVS in the network edge is supported through the Kubernetes kube-OVN Container Network Interface (CNI).
 
 >**NOTE**: The InterApps Communication also works with Calico cni. Calico is supported as a default cni in Openness from 21.03 release.
 
@@ -25,6 +25,6 @@ OVN/OVS is used as a default networking infrastructure for:
 - Default interface: Interface for managing the application POD (e.g., SSH to application POD)
 - Cloud/Internet interface: Interface for edge applications to communicate with the cloud/Internet
 
-![Data Plane Interfaces in OpenNESS Network Edge](iap-images/iap2.png)
+![Data Plane Interfaces in Smart Edge Open Network Edge](iap-images/iap2.png)
 
- _Figure - OpenNESS Network Edge Interfaces_
+ _Figure - Smart Edge Open Network Edge Interfaces_
diff --git a/doc/building-blocks/dataplane/openness-ovn.md b/doc/building-blocks/dataplane/smartedge-open-ovn.md
similarity index 56%
rename from doc/building-blocks/dataplane/openness-ovn.md
rename to doc/building-blocks/dataplane/smartedge-open-ovn.md
index cafe7d15..516fa12f 100644
--- a/doc/building-blocks/dataplane/openness-ovn.md
+++ b/doc/building-blocks/dataplane/smartedge-open-ovn.md
@@ -3,22 +3,22 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019-2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# OpenNESS Support for OVS as dataplane with OVN
+# Smart Edge Open Support for OVS as dataplane with OVN
 - [OVN Introduction](#ovn-introduction)
-- [OVN/OVS support in OpenNESS Network Edge](#ovnovs-support-in-openness-network-edge)
+- [OVN/OVS support in Smart Edge Open Network Edge](#ovnovs-support-in-smart-edge-open-network-edge)
 - [Summary](#summary)
 
 ## OVN Introduction
 Open Virtual Network (OVN) is an open-source solution based on the Open vSwitch-based (OVS) software-defined networking (SDN) solution for providing network services to instances. OVN adds to the capabilities of OVS to provide native support for virtual network abstractions, such as virtual L2 and L3 overlays and security groups. Further information about the OVN architecture can be found [here](http://www.openvswitch.org/support/dist-docs-2.5/ovn-architecture.7.html)
 
-## OVN/OVS support in OpenNESS Network Edge
-The primary objective of supporting OVN/OVS in OpenNESS is to demonstrate the capability of using a standard dataplane such as OVS for an Edge Compute platform. Using OVN/OVS further provides standard SDN-based flow configuration for the edge Dataplane.
+## OVN/OVS support in Smart Edge Open Network Edge
+The primary objective of supporting OVN/OVS in Smart Edge Open is to demonstrate the capability of using a standard dataplane such as OVS for an Edge Compute platform. Using OVN/OVS further provides standard SDN-based flow configuration for the edge Dataplane.
 
 The diagram below shows OVS as a dataplane and OVN overlay. This mode of deployment is recommended when the Edge node terminates IP traffic (Wireline, Wireless, LTE CUPS, SGi)
 
-![OpenNESS with NTS as dataplane overview](ovn_images/openness_ovn.png)
+![Smart Edge Open with NTS as dataplane overview](ovn_images/smartedge-open_ovn.png)
 
-[Kube-OVN](https://github.com/alauda/kube-ovn) can be chosen as the CNI implementation for OVN/OVS in OpenNESS. Additionally, in the following configuration, OpenNESS applications on Edge Nodes are deployed as DaemonSet Pods (in separate "openness" namespace) and exposed to client applications by k8s services.
+[Kube-OVN](https://github.com/alauda/kube-ovn) can be chosen as the CNI implementation for OVN/OVS in Smart Edge Open. Additionally, in the following configuration, Smart Edge Open applications on Edge Nodes are deployed as DaemonSet Pods (in separate "openness" namespace) and exposed to client applications by k8s services.
 
 OVN/OVS is used as the default networking infrastructure for:
 - Dataplane Interface: UE's to edge applications
@@ -29,4 +29,4 @@ OVN/OVS is used as the default networking infrastructure for:
 The platform supports OVS-DPDK as a dataplane. OVS-DPDK can be used for high-performance data transmission scenarios in the userspace. More about OVS-DPDK can be found [here](http://docs.openvswitch.org/en/latest/howto/dpdk/).
 
 ## Summary
-OpenNESS is built with a microservices architecture. Depending on the deployment, there may be a requirement to service pure IP traffic and configure the dataplane using standard SDN-based tools. OpenNESS demonstrates such a requirement by providing OVS as a dataplane in the place of NTS without changing the APIs from an end-user perspective.
+Smart Edge Open is built with a microservices architecture. Depending on the deployment, there may be a requirement to service pure IP traffic and configure the dataplane using standard SDN-based tools. Smart Edge Open demonstrates such a requirement by providing OVS as a dataplane in the place of NTS without changing the APIs from an end-user perspective.
diff --git a/doc/building-blocks/dataplane/openness-userspace-cni.md b/doc/building-blocks/dataplane/smartedge-open-userspace-cni.md
similarity index 88%
rename from doc/building-blocks/dataplane/openness-userspace-cni.md
rename to doc/building-blocks/dataplane/smartedge-open-userspace-cni.md
index b0094dd0..36f857ba 100644
--- a/doc/building-blocks/dataplane/openness-userspace-cni.md
+++ b/doc/building-blocks/dataplane/smartedge-open-userspace-cni.md
@@ -12,11 +12,11 @@ Copyright (c) 2019 Intel Corporation
 
 ## Overview
 
-Userspace CNI is a Container Network Interface (CNI) Kubernetes\* plugin that was designed to simplify the process of deployment of DPDK-based applications in Kubernetes pods. The plugin uses Kubernetes and Multus CNI CRDs to provide pods with a virtual DPDK-enabled Ethernet port. In this document, you can find details about how to install OpenNESS with Userspace CNI support and how to use its main features.
+Userspace CNI is a Container Network Interface (CNI) Kubernetes\* plugin that was designed to simplify the process of deployment of DPDK-based applications in Kubernetes pods. The plugin uses Kubernetes and Multus CNI CRDs to provide pods with a virtual DPDK-enabled Ethernet port. In this document, you can find details about how to install Smart Edge Open with Userspace CNI support and how to use its main features.
 
 ## Setup Userspace CNI
 
-OpenNESS for Network Edge has been integrated with Userspace CNI to allow users to easily run DPDK- based applications inside Kubernetes pods. To install OpenNESS Network Edge with Userspace CNI support, add the value `userspace` to variable `kubernetes_cnis` in `inventory/default/group_vars/all/10-default.yml` and set value of the variable `kubeovn_dpdk` in `inventory/default/group_vars/all/10-default.yml` to `true`:
+Smart Edge Open for Network Edge has been integrated with Userspace CNI to allow users to easily run DPDK- based applications inside Kubernetes pods. To install Smart Edge Open Network Edge with Userspace CNI support, add the value `userspace` to variable `kubernetes_cnis` in `inventory/default/group_vars/all/10-default.yml` and set value of the variable `kubeovn_dpdk` in `inventory/default/group_vars/all/10-default.yml` to `true`:
 
 ```yaml
 # inventory/default/group_vars/all/10-default.yml
diff --git a/doc/building-blocks/emco/index.html b/doc/building-blocks/emco/index.html
index 0d4fe09d..48965a1c 100644
--- a/doc/building-blocks/emco/index.html
+++ b/doc/building-blocks/emco/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
-window.location = "openness-emco"
+window.location = "smartedge-open-emco"
 </script>
diff --git a/doc/building-blocks/emco/openness-emco-images/emco-dig-create.png b/doc/building-blocks/emco/smartedge-open-emco-images/emco-dig-create.png
similarity index 100%
rename from doc/building-blocks/emco/openness-emco-images/emco-dig-create.png
rename to doc/building-blocks/emco/smartedge-open-emco-images/emco-dig-create.png
diff --git a/doc/building-blocks/emco/openness-emco-images/emco-dig-instantiate.png b/doc/building-blocks/emco/smartedge-open-emco-images/emco-dig-instantiate.png
similarity index 100%
rename from doc/building-blocks/emco/openness-emco-images/emco-dig-instantiate.png
rename to doc/building-blocks/emco/smartedge-open-emco-images/emco-dig-instantiate.png
diff --git a/doc/building-blocks/emco/openness-emco-images/emco-geo-distributed.png b/doc/building-blocks/emco/smartedge-open-emco-images/emco-geo-distributed.png
similarity index 100%
rename from doc/building-blocks/emco/openness-emco-images/emco-geo-distributed.png
rename to doc/building-blocks/emco/smartedge-open-emco-images/emco-geo-distributed.png
diff --git a/doc/building-blocks/emco/openness-emco-images/emco-istio-arch.png b/doc/building-blocks/emco/smartedge-open-emco-images/emco-istio-arch.png
similarity index 100%
rename from doc/building-blocks/emco/openness-emco-images/emco-istio-arch.png
rename to doc/building-blocks/emco/smartedge-open-emco-images/emco-istio-arch.png
diff --git a/doc/building-blocks/emco/openness-emco-images/emco-istio-auth.png b/doc/building-blocks/emco/smartedge-open-emco-images/emco-istio-auth.png
similarity index 100%
rename from doc/building-blocks/emco/openness-emco-images/emco-istio-auth.png
rename to doc/building-blocks/emco/smartedge-open-emco-images/emco-istio-auth.png
diff --git a/doc/building-blocks/emco/openness-emco-images/emco-register-controllers.png b/doc/building-blocks/emco/smartedge-open-emco-images/emco-register-controllers.png
similarity index 100%
rename from doc/building-blocks/emco/openness-emco-images/emco-register-controllers.png
rename to doc/building-blocks/emco/smartedge-open-emco-images/emco-register-controllers.png
diff --git a/doc/building-blocks/emco/openness-emco-images/emco-status-monitoring.png b/doc/building-blocks/emco/smartedge-open-emco-images/emco-status-monitoring.png
similarity index 100%
rename from doc/building-blocks/emco/openness-emco-images/emco-status-monitoring.png
rename to doc/building-blocks/emco/smartedge-open-emco-images/emco-status-monitoring.png
diff --git a/doc/building-blocks/emco/openness-emco-images/openness-emco-arch.png b/doc/building-blocks/emco/smartedge-open-emco-images/smartedge-open-emco-arch.png
similarity index 100%
rename from doc/building-blocks/emco/openness-emco-images/openness-emco-arch.png
rename to doc/building-blocks/emco/smartedge-open-emco-images/smartedge-open-emco-arch.png
diff --git a/doc/building-blocks/emco/openness-emco-images/openness-emco-lccl.png b/doc/building-blocks/emco/smartedge-open-emco-images/smartedge-open-emco-lccl.png
similarity index 100%
rename from doc/building-blocks/emco/openness-emco-images/openness-emco-lccl.png
rename to doc/building-blocks/emco/smartedge-open-emco-images/smartedge-open-emco-lccl.png
diff --git a/doc/building-blocks/emco/openness-emco-images/openness-emco-smtc.png b/doc/building-blocks/emco/smartedge-open-emco-images/smartedge-open-emco-smtc.png
similarity index 100%
rename from doc/building-blocks/emco/openness-emco-images/openness-emco-smtc.png
rename to doc/building-blocks/emco/smartedge-open-emco-images/smartedge-open-emco-smtc.png
diff --git a/doc/building-blocks/emco/openness-emco-images/openness-emco-smtcui.png b/doc/building-blocks/emco/smartedge-open-emco-images/smartedge-open-emco-smtcui.png
similarity index 100%
rename from doc/building-blocks/emco/openness-emco-images/openness-emco-smtcui.png
rename to doc/building-blocks/emco/smartedge-open-emco-images/smartedge-open-emco-smtcui.png
diff --git a/doc/building-blocks/emco/openness-emco-images/openness-emco-topology.png b/doc/building-blocks/emco/smartedge-open-emco-images/smartedge-open-emco-topology.png
similarity index 100%
rename from doc/building-blocks/emco/openness-emco-images/openness-emco-topology.png
rename to doc/building-blocks/emco/smartedge-open-emco-images/smartedge-open-emco-topology.png
diff --git a/doc/building-blocks/emco/openness-emco.md b/doc/building-blocks/emco/smartedge-open-emco.md
similarity index 89%
rename from doc/building-blocks/emco/openness-emco.md
rename to doc/building-blocks/emco/smartedge-open-emco.md
index 6ae27580..be57cd3a 100644
--- a/doc/building-blocks/emco/openness-emco.md
+++ b/doc/building-blocks/emco/smartedge-open-emco.md
@@ -27,7 +27,7 @@ Copyright (c) 2020-2021 Intel Corporation
   - [EMCO Terminology](#emco-terminology-1)
   - [EMCO API](#emco-api)
   - [EMCO Authentication and Authorization](#emco-authentication-and-authorization)
-  - [EMCO Installation With OpenNESS Flavor](#emco-installation-with-openness-flavor)
+  - [EMCO Installation With Smart Edge Open Flavor](#emco-installation-with-smart-edge-open-flavor)
 - [EMCO Example: SmartCity Deployment](#emco-example-smartcity-deployment)
   - [Cluster Setup](#cluster-setup)
   - [Project Setup](#project-setup)
@@ -36,7 +36,7 @@ Copyright (c) 2020-2021 Intel Corporation
   - [SmartCity Termination](#smartcity-termination)
 
 ## Background
-Edge Multi-Cluster Orchestration(EMCO), an OpenNESS Building Block, is a Geo-distributed application orchestrator for Kubernetes\*. EMCO operates at a higher level than Kubernetes\* and interacts with multiple of edges and clouds running Kubernetes. The main objective of EMCO is automation of the deployment of applications and services across multiple clusters. It acts as a central orchestrator that can manage edge services and network functions across geographically distributed edge clusters from different third parties. 
+Edge Multi-Cluster Orchestration(EMCO), an Smart Edge Open Building Block, is a Geo-distributed application orchestrator for Kubernetes\*. EMCO operates at a higher level than Kubernetes\* and interacts with multiple of edges and clouds running Kubernetes. The main objective of EMCO is automation of the deployment of applications and services across multiple clusters. It acts as a central orchestrator that can manage edge services and network functions across geographically distributed edge clusters from different third parties. 
 
 Increasingly we see a requirement of deploying 'composite applications' in multiple geographical locations. Some of the catalysts for this change are:
 
@@ -45,7 +45,7 @@ Increasingly we see a requirement of deploying 'composite applications' in multi
 -  Context/Promixity - running some part of the applications on edges near the user that require local context 
 -  Privacy/Legal - some data can have legal requirements to not leave a geographic location
 
-![OpenNESS EMCO](openness-emco-images/emco-geo-distributed.png)
+![Smart Edge Open EMCO](smartedge-open-emco-images/emco-geo-distributed.png)
 _Figure 1 - Orchestrate GeoDitributed Edge Applications_
 
 > **NOTE**: A 'composite application' is a combination of multiple applications with each application packaged as a Helm chart. Based on the deployment intent, various applications of the composite application get deployed at various locations, and get replicated in multiple locations.
@@ -55,7 +55,7 @@ Life cycle management of composite applications is complex. Instantiation and te
 Number of K8s clusters (Edges or clouds) could be in tens of thousands, number of complex applications that need to be managed could be in hundreds, number of applications in a complex application could be in tens and number of micro-services in each application of the complex application can be in tens. Moreover, there can be multiple deployments of the same complex applications for different purposes. To reduce the complexity, all these operations are to be automated. There shall be one-click deployment of the complex applications and one simple dashboard to know the status of the complex application deployment at any time. Hence, there is a need for Multi-Edge and Multi-Cloud distributed application orchestrator.
  
 Compared with other multiple-clusters orchestration, EMCO focuses on the following functionalities:
-- Enrolling multiple geographically distributed OpenNESS clusters and third party cloud clusters.
+- Enrolling multiple geographically distributed Smart Edge Open clusters and third party cloud clusters.
 - Orchestrating composite applications (composed of multiple individual applications) across different clusters.
 - Deploying edge services and network functions on to different nodes spread across different clusters.
 - Monitoring the health of the deployed edge services/network functions across different clusters.
@@ -63,20 +63,20 @@ Compared with other multiple-clusters orchestration, EMCO focuses on the followi
 - Supporting multiple tenants from different enterprises while ensuring confidentiality and full isolation between the tenants.
 
 
-The following figure shows the topology overview for the OpenNESS EMCO orchestration with edge and multiple clusters. It also shows an example of deploying SmartCity with EMCO. 
-![OpenNESS EMCO](openness-emco-images/openness-emco-topology.png)
+The following figure shows the topology overview for the Smart Edge Open EMCO orchestration with edge and multiple clusters. It also shows an example of deploying SmartCity with EMCO. 
+![Smart Edge Open EMCO](smartedge-open-emco-images/smartedge-open-emco-topology.png)
 
-_Figure 2 - Topology Overview with OpenNESS EMCO_
+_Figure 2 - Topology Overview with Smart Edge Open EMCO_
 
 All the managed edge clusters and cloud clusters are connected with the EMCO cluster through the WAN network. 
-- The central orchestration (EMCO) cluster can be installed and provisioned by using the [OpenNESS Central Orchestrator Flavor](../../flavors.md). 
-- The edge clusters and the cloud cluster can be installed and provisioned by using the [OpenNESS Flavor](../../flavors.md). 
+- The central orchestration (EMCO) cluster can be installed and provisioned by using the [Smart Edge Open Central Orchestrator Flavor](../../flavors.md). 
+- The edge clusters and the cloud cluster can be installed and provisioned by using the [Smart Edge Open Flavor](../../flavors.md). 
 - The composite application - [SmartCity](https://github.com/OpenVisualCloud/Smart-City-Sample) is composed of two parts: edge application and cloud (web) application. 
   - The edge application executes media processing and analytics on multiple edge clusters to reduce latency.
   - The cloud application is like a web application for additional post-processing, such as calculating statistics and display/visualization on the cloud cluster side.
   - The EMCO user can deploy the SmartCity applications across the clusters. Besides that, EMCO allows the operator to override configurations and profiles to satisfy deployment needs.
 
-This document aims to familiarize the user with EMCO and [OpenNESS deployment flavor](../../flavors.md) for EMCO installation and provision, and provide instructions accordingly.
+This document aims to familiarize the user with EMCO and [Smart Edge Open deployment flavor](../../flavors.md) for EMCO installation and provision, and provide instructions accordingly.
 
 ## EMCO Introduction
 
@@ -94,7 +94,7 @@ This document aims to familiarize the user with EMCO and [OpenNESS deployment fl
 
 ### EMCO Architecture
 The following diagram depicts a high level overview of the EMCO architecture.
-![OpenNESS EMCO](openness-emco-images/openness-emco-arch.png)
+![Smart Edge Open EMCO](smartedge-open-emco-images/smartedge-open-emco-arch.png)
 
 _Figure 3 - EMCO Architecture_
 
@@ -133,7 +133,7 @@ The Distributed Application Scheduler supports operations on a deployment intent
 - status: (may be invoked at any step) provides information on the status of the deployment intent group.
 - terminate: terminates the application resources of an instantiated application from all of the clusters to which it was deployed. In some cases, if a remote cluster is intermittently unreachable, the instantiate operation may still retry the instantiate operation for that cluster. The terminate operation will cause the instantiate operation to complete (i.e. fail), before the termination operation is performed.
 - stop: In some cases, if the remote cluster is intermittently unreachable, the Resource Synchronizer will continue retrying an instantiate or terminate operation. The stop operation can be used to force the retry operation to stop, and the instantiate or terminate  operation will complete (with a failed status). In the case of terminate, this allows the deployment intent group resource to be deleted via the API, since deletion is prevented until a deployment intent group resource has reached a completed terminate operation status.
-Refer to [EMCO Resource Lifecycle Operations](https://github.com/open-ness/EMCO/tree/main/docs/user/Resource_Lifecycle.md) for more details.
+Refer to [EMCO Resource Lifecycle Operations](https://github.com/smart-edge-open/EMCO/tree/main/docs/user/Resource_Lifecycle.md) for more details.
 
 #### Network Configuration Management
 The network configuration management (NCM) microservice:
@@ -157,7 +157,7 @@ A Logical Cloud is the overall target of a Deployment Intent Group and is a mand
 
 Due to the close relationship with Clusters, which are provided by Cluster Registration (clm) above, it is important to understand the mapping between the two. A Logical Cloud groups many Clusters together but a Cluster may also be grouped by multiple Logical Clouds, effectively turning the cluster multi-tenant. The partitioning/multi-tenancy of a particular Cluster, via the different Logical Clouds, is done today at the namespace level (different Logical Clouds access different namespace names, and the name is consistent across the multiple clusters of the Logical Cloud).
 
-![Mapping between Logical Clouds and Clusters](openness-emco-images/openness-emco-lccl.png)
+![Mapping between Logical Clouds and Clusters](smartedge-open-emco-images/smartedge-open-emco-lccl.png)
 
 _Figure 4 - Mapping between Logical Clouds and Clusters_
 
@@ -218,28 +218,28 @@ This microservice is the one which deploys the resources in edge/cloud clusters.
 #### Placement and Action Controllers in EMCO
 This section illustrates some key aspects of the EMCO controller architecture.  Depending on the needs of a composite application, intents that handle specific operations for application resources (e.g. addition, modification, etc.) can be created via the APIs provided by the corresponding controller API.  The following diagram shows the sequence of interactions to register controllers with EMCO.
 
-![OpenNESS EMCO](openness-emco-images/emco-register-controllers.png)
+![Smart Edge Open EMCO](smartedge-open-emco-images/emco-register-controllers.png)
 
 _Figure 5 - Register placement and action controllers with EMCO_
 
 This diagram illustrates the sequence of operations taken to prepare a Deployment Intent Group that utilizes some intents supported by controllers.  The desired set of controllers and associated intents are included in the definition of a Deployment Intent Group to satisfy the requirements of a specific deployed instance of a composite application.
 
-![OpenNESS EMCO](openness-emco-images/emco-dig-create.png)
+![Smart Edge Open EMCO](smartedge-open-emco-images/emco-dig-create.png)
 
 _Figure 6 - Create a Deployment Intent Group_
 
 When the Deployment Intent Group is instantiated, the identified set of controllers are invoked in order to perform their specific operations.
 
-![OpenNESS EMCO](openness-emco-images/emco-dig-instantiate.png)
+![Smart Edge Open EMCO](smartedge-open-emco-images/emco-dig-instantiate.png)
 
 _Figure 7 - Instantiate a Deployment Intent Group_
 
 In this initial release of EMCO, a built-in generic placement controller is provided in the `orchestrator`.  As described above, the three provided action controllers are the OVN Action, Traffic and Generic Action controllers.
 
 #### Status Monitoring and Queries in EMCO
-When a resource like a Deployment Intent Group is instantiated, status information about both the deployment and the deployed resources in the cluster are collected and made available for query by the API. The following diagram illustrates the key components involved.  For more information about status queries see [EMCO Resource Lifecycle Operations](https://github.com/open-ness/EMCO/tree/main/docs/user/Resource_Lifecycle.md).
+When a resource like a Deployment Intent Group is instantiated, status information about both the deployment and the deployed resources in the cluster are collected and made available for query by the API. The following diagram illustrates the key components involved.  For more information about status queries see [EMCO Resource Lifecycle Operations](https://github.com/smart-edge-open/EMCO/tree/main/docs/user/Resource_Lifecycle.md).
 
-![OpenNESS EMCO](openness-emco-images/emco-status-monitoring.png)
+![Smart Edge Open EMCO](smartedge-open-emco-images/emco-status-monitoring.png)
 
 _Figure 8 - Status Monitoring and Query Sequence_
 
@@ -262,7 +262,7 @@ _Figure 8 - Status Monitoring and Query Sequence_
 
 
 ### EMCO API
-For user interaction, EMCO provides [RESTful API](https://github.com/open-ness/EMCO/blob/main/docs/emco_apis.yaml). Apart from that, EMCO also provides CLI. For the detailed usage, refer to [EMCO CLI](https://github.com/open-ness/EMCO/tree/main/src/tools/emcoctl)
+For user interaction, EMCO provides [RESTful API](https://github.com/smart-edge-open/EMCO/blob/main/docs/emco_apis.yaml). Apart from that, EMCO also provides CLI. For the detailed usage, refer to [EMCO CLI](https://github.com/smart-edge-open/EMCO/tree/main/src/tools/emcoctl)
 > **NOTE**: The EMCO RESTful API is the foundation for the other interaction facilities like the EMCO CLI, EMCO GUI (available in the future) and other orchestrators.
 
 ### EMCO Authentication and Authorization
@@ -277,17 +277,17 @@ EMCO uses Istio and other open source solutions to provide Multi-tenancy solutio
 
 The following figure shows various EMCO services running in a cluster with Istio.
 
-![OpenNESS EMCO](openness-emco-images/emco-istio-arch.png)
+![Smart Edge Open EMCO](smartedge-open-emco-images/emco-istio-arch.png)
 
 _Figure 9 - EMCO setup with Istio and Authservice_
 
 The following figure shows the authentication flow with EMCO, Istio and Authservice
 
-![OpenNESS EMCO](openness-emco-images/emco-istio-auth.png)
+![Smart Edge Open EMCO](smartedge-open-emco-images/emco-istio-auth.png)
 
 _Figure 10 - EMCO Authenication with external OATH2 Server_
 
-Detailed steps for configuring EMCO with Istio can be found in [EMCO Integrity and Access Management](https://github.com/open-ness/EMCO/tree/main/docs/user/Emco_Integrity_Access_Management.md) document.
+Detailed steps for configuring EMCO with Istio can be found in [EMCO Integrity and Access Management](https://github.com/smart-edge-open/EMCO/tree/main/docs/user/Emco_Integrity_Access_Management.md) document.
 
 Steps for EMCO Authentication and Authorization Setup:
 - Install and Configure Keycloak Server to be used in the setup. This server runs outside the EMCO cluster
@@ -300,9 +300,9 @@ Steps for EMCO Authentication and Authorization Setup:
 - Apply EnvoyFilter for Authservice
 - Apply Authentication and Authorization Policies
 
-### EMCO Installation With OpenNESS Flavor
-EMCO supports [multiple deployment options](https://github.com/open-ness/EMCO/tree/main/deployments). [Converged Edge Experience Kits](../../getting-started/converged-edge-experience-kits.md) offers the `central_orchestrator` flavor to automate EMCO build and deployment as mentioned below.
-- The first step is to prepare one server environment which needs to fulfill the [preconditions](../../getting-started/openness-cluster-setup.md#preconditions).
+### EMCO Installation With Smart Edge Open Flavor
+EMCO supports [multiple deployment options](https://github.com/smart-edge-open/EMCO/tree/main/deployments). [Converged Edge Experience Kits](../../getting-started/converged-edge-experience-kits.md) offers the `central_orchestrator` flavor to automate EMCO build and deployment as mentioned below.
+- The first step is to prepare one server environment which needs to fulfill the [preconditions](../../getting-started/smartedge-open-cluster-setup.md#preconditions).
 - Place the EMCO server hostname in `controller_group/hosts/ctrl.openness.org:` dictionary in `inventory.yml` file of converged-edge-experience-kit.
 - Update the `inventory.yaml` file by setting the deployment flavor as `central_orchestrator`
     ```yaml
@@ -348,19 +348,19 @@ emco      ovnaction-5d8d4447f9-nn7l6     1/1     Running  0        14m
 emco      rsync-99b85b4x88-ashmc         1/1     Running  0        14m
 ```
 
-Besides that, OpenNESS EMCO also provides Azure templates and supports deployment automation for EMCO cluster on Azure public cloud. More details refer to [OpenNESS Development Kit for Microsoft Azure](https://github.com/open-ness/ido-specs/blob/master/doc/devkits/openness-azure-devkit.md).
+Besides that, Smart Edge Open EMCO also provides Azure templates and supports deployment automation for EMCO cluster on Azure public cloud. More details refer to [Smart Edge Open Development Kit for Microsoft Azure](https://github.com/smart-edge-open/ido-specs/blob/master/doc/devkits/smartedge-open-azure-devkit.md).
 
 ## EMCO Example: SmartCity Deployment
 - The [SmartCity application](https://github.com/OpenVisualCloud/Smart-City-Sample) is a sample application that is built on top of the OpenVINO™ and Open Visual Cloud software stacks for media processing and analytics. The composite application is composed of two parts: EdgeApp + WebApp (cloud application for additional post-processing such as calculating statistics and display/visualization) 
 - The edge cluster (representing regional office), the cloud cluster and the EMCO are connected with each other.
 - The whole deployment architecture diagram is shown as below:
-![OpenNESS EMCO](openness-emco-images/openness-emco-smtc.png)
+![Smart Edge Open EMCO](smartedge-open-emco-images/smartedge-open-emco-smtc.png)
 
 _Figure 11 - SmartCity Deployment Architecture Overview_
 
 The example steps are shown as follows:
 - Prerequisites
-  - Make one edge cluster and one cloud cluster ready by using OpenNESS Flavor.
+  - Make one edge cluster and one cloud cluster ready by using Smart Edge Open Flavor.
     - If testing with HPA intent, need to prepare two edge clusters.
   - Prepare one server with a vanilla CentOS\* 7.9.2009 for EMCO installation.
 - EMCO installation
@@ -370,14 +370,14 @@ The example steps are shown as follows:
 - Deploy SmartCity application
 
 ### EMCO installation
-Follow the guidance as [EMCO Installation With OpenNESS Flavor](#emco-installation-with-openness-flavor), logon to the EMCO host server and maker sure that Harbor and EMCO microservices are in running status.
+Follow the guidance as [EMCO Installation With Smart Edge Open Flavor](#emco-installation-with-smart-edge-open-flavor), logon to the EMCO host server and maker sure that Harbor and EMCO microservices are in running status.
  
 ### Cluster Setup
 The step includes:
 - Prepare edge and cloud clusters kubeconfig files, SmartCity helm charts and relevant artifacts.
-- Register clusters provider by [EMCO CLI](https://github.com/open-ness/EMCO/tree/main/src/tools/emcoctl).
-- Register provider's clusters by [EMCO CLI](https://github.com/open-ness/EMCO/tree/main/src/tools/emcoctl).
-- Register EMCO controllers and resource synchroizer by [EMCO CLI](https://github.com/open-ness/EMCO/tree/main/src/tools/emcoctl).
+- Register clusters provider by [EMCO CLI](https://github.com/smart-edge-open/EMCO/tree/main/src/tools/emcoctl).
+- Register provider's clusters by [EMCO CLI](https://github.com/smart-edge-open/EMCO/tree/main/src/tools/emcoctl).
+- Register EMCO controllers and resource synchroizer by [EMCO CLI](https://github.com/smart-edge-open/EMCO/tree/main/src/tools/emcoctl).
 
 1. On the edge and cloud cluster, run the following command to make Docker logon to the Harbor deployed on the EMCO server, thus the clusters can pull SmartCity images from the Harbor:
     ```shell
@@ -393,7 +393,7 @@ The step includes:
 
     > **NOTE**: <harbor_registry_host> should be `<EMCO Server IP Address>:30003`.
 
-2. On the EMCO server, download the [scripts,profiles and configmap JSON files](https://github.com/open-ness/edgeapps/tree/master/applications/smart-city-app/emco).
+2. On the EMCO server, download the [scripts,profiles and configmap JSON files](https://github.com/smart-edge-open/edgeapps/tree/master/applications/smart-city-app/emco).
 
 3. Artifacts Preparation for clusters's kubeconfig, smartcity helm charts and other relevant artifacts
    Run the command for the environment setup with success return as below:
@@ -470,7 +470,7 @@ The setup includes:
     URL: projects/project_smtc/composite-apps/composite_smtc/v1/deployment-intent-groups/smtc-deployment-intent-group/instantiate Response Code: 202 Response:
     ```
 
-    > **NOTE**: EMCO supports generic K8S resource configuration including configmap, secret,etc. The example offers the usage about [configmap configuration](https://github.com/open-ness/edgeapps/blob/master/applications/smart-city-app/emco/cli-scripts/04_apps_template.yaml) to the clusters. 
+    > **NOTE**: EMCO supports generic K8S resource configuration including configmap, secret,etc. The example offers the usage about [configmap configuration](https://github.com/smart-edge-open/edgeapps/blob/master/applications/smart-city-app/emco/cli-scripts/04_apps_template.yaml) to the clusters. 
 
     > **NOTE**: The `04_apply.sh` script invokes EMCO CLI tool - `emcoctl` and applies resource template file - `04_apps_template.yaml` which contains the application related resources to create in EMCO, for example deployment-intent, application helm chart entries, override profiles, configmap...etc. The placement intent for the use case is cluster label name and provider name.
     
@@ -502,7 +502,7 @@ The pods on the edge cluster are in the running status as shown as below:
 
 3. Verify Smart City GUI 
 From a web browser, launch the Smart City web UI at URL `https://<cloudcluster-controller-node-ip>`. The GUI shows like:      
-![OpenNESS EMCO](openness-emco-images/openness-emco-smtcui.png)
+![Smart Edge Open EMCO](smartedge-open-emco-images/smartedge-open-emco-smtcui.png)
 
 _Figure 12 - SmartCity UI_
 
diff --git a/doc/building-blocks/enhanced-platform-awareness/biosfw-images/openness_biosfw.png b/doc/building-blocks/enhanced-platform-awareness/biosfw-images/smartedge-open_biosfw.png
similarity index 100%
rename from doc/building-blocks/enhanced-platform-awareness/biosfw-images/openness_biosfw.png
rename to doc/building-blocks/enhanced-platform-awareness/biosfw-images/smartedge-open_biosfw.png
diff --git a/doc/building-blocks/enhanced-platform-awareness/fpga-images/openness-fpga1.png b/doc/building-blocks/enhanced-platform-awareness/fpga-images/smartedge-open-fpga1.png
similarity index 100%
rename from doc/building-blocks/enhanced-platform-awareness/fpga-images/openness-fpga1.png
rename to doc/building-blocks/enhanced-platform-awareness/fpga-images/smartedge-open-fpga1.png
diff --git a/doc/building-blocks/enhanced-platform-awareness/fpga-images/openness-fpga2.png b/doc/building-blocks/enhanced-platform-awareness/fpga-images/smartedge-open-fpga2.png
similarity index 100%
rename from doc/building-blocks/enhanced-platform-awareness/fpga-images/openness-fpga2.png
rename to doc/building-blocks/enhanced-platform-awareness/fpga-images/smartedge-open-fpga2.png
diff --git a/doc/building-blocks/enhanced-platform-awareness/fpga-images/openness-fpga3.png b/doc/building-blocks/enhanced-platform-awareness/fpga-images/smartedge-open-fpga3.png
similarity index 100%
rename from doc/building-blocks/enhanced-platform-awareness/fpga-images/openness-fpga3.png
rename to doc/building-blocks/enhanced-platform-awareness/fpga-images/smartedge-open-fpga3.png
diff --git a/doc/building-blocks/enhanced-platform-awareness/fpga-images/openness-fpga4.png b/doc/building-blocks/enhanced-platform-awareness/fpga-images/smartedge-open-fpga4.png
similarity index 100%
rename from doc/building-blocks/enhanced-platform-awareness/fpga-images/openness-fpga4.png
rename to doc/building-blocks/enhanced-platform-awareness/fpga-images/smartedge-open-fpga4.png
diff --git a/doc/building-blocks/enhanced-platform-awareness/hddl-images/openness_HDDL.png b/doc/building-blocks/enhanced-platform-awareness/hddl-images/smartedge-open_HDDL.png
similarity index 100%
rename from doc/building-blocks/enhanced-platform-awareness/hddl-images/openness_HDDL.png
rename to doc/building-blocks/enhanced-platform-awareness/hddl-images/smartedge-open_HDDL.png
diff --git a/doc/building-blocks/enhanced-platform-awareness/hddl-images/openness_dynamic.png b/doc/building-blocks/enhanced-platform-awareness/hddl-images/smartedge-open_dynamic.png
similarity index 100%
rename from doc/building-blocks/enhanced-platform-awareness/hddl-images/openness_dynamic.png
rename to doc/building-blocks/enhanced-platform-awareness/hddl-images/smartedge-open_dynamic.png
diff --git a/doc/building-blocks/enhanced-platform-awareness/index.html b/doc/building-blocks/enhanced-platform-awareness/index.html
index 4289955e..bec89ba3 100644
--- a/doc/building-blocks/enhanced-platform-awareness/index.html
+++ b/doc/building-blocks/enhanced-platform-awareness/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
-window.location = "openness-hugepage"
+window.location = "smartedge-open-hugepage"
 </script>
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-acc100.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-acc100.md
similarity index 87%
rename from doc/building-blocks/enhanced-platform-awareness/openness-acc100.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-acc100.md
index 5506fce4..53ee9751 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-acc100.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-acc100.md
@@ -3,16 +3,16 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# Using ACC100 eASIC in OpenNESS: Resource Allocation, and Configuration
+# Using ACC100 eASIC in Smart Edge Open: Resource Allocation, and Configuration
 - [Overview](#overview)
 - [Intel vRAN Dedicated Accelerator ACC100 FlexRAN Host Interface Overview](#intel-vran-dedicated-accelerator-acc100-flexran-host-interface-overview)
 - [Intel vRAN Dedicated Accelerator ACC100 Orchestration and Deployment with Kubernetes\* for FlexRAN](#intel-vran-dedicated-accelerator-acc100-orchestration-and-deployment-with-kubernetes-for-flexran)
-- [Using the Intel vRAN Dedicated Accelerator ACC100 on OpenNESS](#using-the-intel-vran-dedicated-accelerator-acc100-on-openness)
-  - [ACC100 (FEC) Ansible Installation for OpenNESS Network Edge](#acc100-fec-ansible-installation-for-openness-network-edge)
+- [Using the Intel vRAN Dedicated Accelerator ACC100 on Smart Edge Open](#using-the-intel-vran-dedicated-accelerator-acc100-on-smart-edge-open)
+  - [ACC100 (FEC) Ansible Installation for Smart Edge Open Network Edge](#acc100-fec-ansible-installation-for-smart-edge-open-network-edge)
     - [Converged Edge Experience Kits](#converged-edge-experience-kits)
-  - [FEC VF configuration for OpenNESS Network Edge](#fec-vf-configuration-for-openness-network-edge)
-  - [Requesting Resources and Running Pods for OpenNESS Network Edge](#requesting-resources-and-running-pods-for-openness-network-edge)
-  - [Verifying Application POD Access and Usage of FPGA on OpenNESS Network Edge](#verifying-application-pod-access-and-usage-of-fpga-on-openness-network-edge)
+  - [FEC VF configuration for Smart Edge Open Network Edge](#fec-vf-configuration-for-smart-edge-open-network-edge)
+  - [Requesting Resources and Running Pods for Smart Edge Open Network Edge](#requesting-resources-and-running-pods-for-smart-edge-open-network-edge)
+  - [Verifying Application POD Access and Usage of FPGA on Smart Edge Open Network Edge](#verifying-application-pod-access-and-usage-of-fpga-on-smart-edge-open-network-edge)
 - [Reference](#reference)
 
 ## Overview
@@ -47,7 +47,7 @@ MIMO networks
 
 For more information, see product brief in [Intel® vRAN Dedicated Accelerator ACC100](https://builders.intel.com/docs/networkbuilders/intel-vran-dedicated-accelerator-acc100-product-brief.pdf).
 
-This document explains how the ACC100 resource can be used on the Open Network Edge Services Software (OpenNESS) platform for accelerating network functions and edge application workloads. We use the Intel® vRAN Dedicated Accelerator ACC100 to accelerate the LTE/5G Forward Error Correction (FEC) in the 5G or 4G L1 base station network function such as FlexRAN.
+This document explains how the ACC100 resource can be used on the Open Network Edge Services Software (Smart Edge Open) platform for accelerating network functions and edge application workloads. We use the Intel® vRAN Dedicated Accelerator ACC100 to accelerate the LTE/5G Forward Error Correction (FEC) in the 5G or 4G L1 base station network function such as FlexRAN.
 
 FlexRAN is a reference layer 1 pipeline of 4G eNb and 5G gNb on Intel® architecture. The FlexRAN reference pipeline consists of an L1 pipeline, optimized L1 processing modules, BBU pooling framework, cloud and cloud-native deployment support, and accelerator support for hardware offload. Intel® vRAN Dedicated Accelerator ACC100 card is used by FlexRAN to offload FEC (Forward Error Correction) for 4G and 5G.
 
@@ -62,12 +62,12 @@ Intel® vRAN Dedicated Accelerator ACC100 card used in the FlexRAN solution expo
 ## Intel vRAN Dedicated Accelerator ACC100 Orchestration and Deployment with Kubernetes\* for FlexRAN
 FlexRAN is a low-latency network function that implements the FEC. FlexRAN uses the FEC resources from the ACC100 using POD resource allocation and the Kubernetes\* device plugin framework. Kubernetes* provides a device plugin framework that is used to advertise system hardware resources to the Kubelet. Instead of customizing the code for Kubernetes* (K8s) itself, vendors can implement a device plugin that can be deployed either manually or as a DaemonSet. The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand\* adapters, and other similar computing resources that may require vendor-specific initialization and setup.
 
-![Intel® vRAN Dedicated Accelerator ACC100 Orchestration and deployment with OpenNESS Network Edge for FlexRAN](acc100-images/acc100-k8s.png)
+![Intel® vRAN Dedicated Accelerator ACC100 Orchestration and deployment with Smart Edge Open Network Edge for FlexRAN](acc100-images/acc100-k8s.png)
 
-_Figure - Intel® vRAN Dedicated Accelerator ACC100 Orchestration and deployment with OpenNESS Network Edge for FlexRAN_
+_Figure - Intel® vRAN Dedicated Accelerator ACC100 Orchestration and deployment with Smart Edge Open Network Edge for FlexRAN_
 
-## Using the Intel vRAN Dedicated Accelerator ACC100 on OpenNESS
-Further sections provide instructions on how to use the ACC100 eASIC features: configuration and accessing from an application on the OpenNESS Network Edge.
+## Using the Intel vRAN Dedicated Accelerator ACC100 on Smart Edge Open
+Further sections provide instructions on how to use the ACC100 eASIC features: configuration and accessing from an application on the Smart Edge Open Network Edge.
 
 When the Intel® vRAN Dedicated Accelerator ACC100 is available on the Edge Node platform it exposes the Single Root I/O Virtualization (SRIOV) Virtual Function (VF) devices which can be used to accelerate the FEC in the vRAN workload. To take advantage of this functionality for a cloud-native deployment, the PF (Physical Function) of the device must be bound to the DPDK IGB_UIO userspace driver to create several VFs (Virtual Functions). Once the VFs are created, they must also be bound to a DPDK userspace driver to allocate them to specific K8s pods running the vRAN workload.
 
@@ -78,11 +78,11 @@ The full pipeline of preparing the device for workload deployment and deploying
 - Enabling orchestration and allocation of the devices (VFs) to non-root pods requesting the devices: leveraging the support of "accelerator" SRIOV VFs from K8s SRIOV Device Plugin. K8s plugin deployment is delivered as part of the Edge Controller's Ansible automation.
 - Simple sample BBDEV application to validate the pipeline (i.e., SRIOV creation - Queue configuration - Device orchestration - Pod deployment): Script delivery and instructions to build Docker image for sample application delivered as part of Edge Apps package.
 
-### ACC100 (FEC) Ansible Installation for OpenNESS Network Edge
-To run the OpenNESS package with ACC100 (FEC) functionality, the feature needs to be enabled on both Edge Controller and Edge Node.
+### ACC100 (FEC) Ansible Installation for Smart Edge Open Network Edge
+To run the Smart Edge Open package with ACC100 (FEC) functionality, the feature needs to be enabled on both Edge Controller and Edge Node.
 
 #### Converged Edge Experience Kits
-To enable ACC100 support from CEEK, SRIOV must be enabled in OpenNESS:
+To enable ACC100 support from CEEK, SRIOV must be enabled in Smart Edge Open:
 ```yaml
 # flavors/flexran/all.yml
 kubernetes_cnis:
@@ -140,7 +140,7 @@ openness      syslog-master-9x8hc                       1/1     Running   0
 openness      syslog-ng-br92z                           1/1     Running   0          3d18h
 ```
 
-### FEC VF configuration for OpenNESS Network Edge
+### FEC VF configuration for Smart Edge Open Network Edge
 To configure the VFs with the necessary number of queues for the vRAN workload, the BBDEV configuration utility is going to run as a job within a privileged container. The configuration utility is available to run as a Helm chart available from `/opt/openness/helm-charts/bb_config`.
 
 Sample configMap, which can be configured by changing values, if other than typical config is required, with a profile for the queue configuration is provided as part of Helm chart template `/opt/openness/helm-charts/bb_config/templates/acc100-config.yaml` populated with values from `/opt/openness/helm-charts/bb_config/values.yaml`. Helm chart installation requires a provision of hostname for the target node during job deployment. Additionally, the default values in Helm chart will deploy FPGA config, a flag needs to be provided to invoke ACC100 config.
@@ -169,8 +169,8 @@ To uninstall the job, run:
 helm uninstall intel-acc100-cfg
 ```
 
-### Requesting Resources and Running Pods for OpenNESS Network Edge
-As part of the OpenNESS Ansible automation, a K8s SRIOV device plugin to orchestrate the ACC100 VFs (bound to the userspace driver) is running. This enables the scheduling of pods requesting this device. To check the number of devices available on the Edge Node from Edge Controller, run:
+### Requesting Resources and Running Pods for Smart Edge Open Network Edge
+As part of the Smart Edge Open Ansible automation, a K8s SRIOV device plugin to orchestrate the ACC100 VFs (bound to the userspace driver) is running. This enables the scheduling of pods requesting this device. To check the number of devices available on the Edge Node from Edge Controller, run:
 
 ```shell
 kubectl get node <node_name> -o json | jq '.status.allocatable'
@@ -179,7 +179,7 @@ kubectl get node <node_name> -o json | jq '.status.allocatable'
 ```
 
 To request the device as a resource in the pod, add the request for the resource into the pod specification file by specifying its name and the amount of resources required. If the resource is not available or the amount of resources requested is greater than the number of resources available, the pod status will be “Pending” until the resource is available.
-**NOTE**: The name of the resource must match the name specified in the configMap for the K8s devices plugin [configMap.yml](https://github.com/open-ness/converged-edge-experience-kits/blob/master/roles/kubernetes/cni/sriov/controlplane/templates/configMap.yml.j2).
+**NOTE**: The name of the resource must match the name specified in the configMap for the K8s devices plugin [configMap.yml](https://github.com/smart-edge-open/converged-edge-experience-kits/blob/master/roles/kubernetes/cni/sriov/controlplane/templates/configMap.yml.j2).
 
 A sample pod requesting the ACC100 (FEC) VF may look like this:
 
@@ -218,7 +218,7 @@ To check the number of devices currently allocated to pods, run (and search for
 kubectl describe node <node_host_name>
 ```
 
-### Verifying Application POD Access and Usage of FPGA on OpenNESS Network Edge
+### Verifying Application POD Access and Usage of FPGA on Smart Edge Open Network Edge
 To verify the functionality of all the features are working together (SRIOV binding - K8s device plugin - BBDEV config) and functionality of the ACC100 (FEC) VF inside a non-root pod, build a Docker image and run a simple validation application for the device.
 
 The automation of the Docker image build is available from the Edge Apps package. The image must be built on the same node that it is meant to be deployed or a server with the same configuration as the node that will run the workload. This is due to the Kernel dependencies of DPDK during the application build.
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-bios.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-bios.md
similarity index 71%
rename from doc/building-blocks/enhanced-platform-awareness/openness-bios.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-bios.md
index 17e91dff..89a17bfd 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-bios.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-bios.md
@@ -3,10 +3,10 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019 Intel Corporation
 ```
 <!-- omit in toc -->
-# BIOS and Firmware Configuration on the OpenNESS Platform
+# BIOS and Firmware Configuration on the Smart Edge Open Platform
 - [Overview](#overview)
 - [Use case for edge](#use-case-for-edge)
-- [Details: BIOS and firmware configuration on OpenNESS Network Edge](#details-bios-and-firmware-configuration-on-openness-network-edge)
+- [Details: BIOS and firmware configuration on Smart Edge Open Network Edge](#details-bios-and-firmware-configuration-on-smart-edge-open-network-edge)
   - [Setup](#setup)
   - [Usage](#usage)
 - [Reference](#reference)
@@ -20,19 +20,19 @@ BIOS and firmware are the fundamental platform configurations of a typical comme
 Example: an AI Inference application that uses an accelerator such as an FPGA. 
 To get optimal performance, when this application is deployed by the Resource Orchestrator, it is recommended to place the application on the same node and CPU Socket to which the accelerator is attached. To ensure this, NUMA, PCIe memory-mapped IO, and cache configurations need to be optimally configured. Similarly, for a network function like a base station or core network instruction set, cache and hyperthreading play an important role in the performance and density.
 
-OpenNESS provides a reference implementation demonstrating how to configure low-level platform settings such as BIOS and firmware, and it provides the capability to check if they are configured as per a required profile. To implement this feature, OpenNESS uses the Intel® System Configuration Utility. The Intel® System Configuration Utility (Syscfg) is a command-line utility that can be used to save and restore BIOS and firmware settings to a file or to set and display individual settings.
+Smart Edge Open provides a reference implementation demonstrating how to configure low-level platform settings such as BIOS and firmware, and it provides the capability to check if they are configured as per a required profile. To implement this feature, Smart Edge Open uses the Intel® System Configuration Utility. The Intel® System Configuration Utility (Syscfg) is a command-line utility that can be used to save and restore BIOS and firmware settings to a file or to set and display individual settings.
 
 >**NOTE**: The Intel® System Configuration Utility is only supported on certain server platforms from Intel. Refer to the [Intel® System Configuration Utility user guide](https://www.intel.com/content/dam/support/us/en/documents/server-products/server-boards/intel-syscfg-userguide-v1-03.pdf) for the supported server products.
 
 >**NOTE**: The Intel® System Configuration Utility is not intended for and should not be used on any non-Intel server products.
 
-The OpenNESS Network Edge implementation goes a step further and provides an automated process using Kubernetes\* to save and restore BIOS and firmware settings. To do this, the Intel® System Configuration Utility is packaged as a pod and deployed as a Kubernetes job that uses ConfigMap. This ConfigMap provides a mount point that has the BIOS and firmware profile that needs to be used for the node. A platform reboot is required for the BIOS and firmware configuration to be applied. To enable this, the BIOS and firmware job is deployed as a privileged pod.
+The Smart Edge Open Network Edge implementation goes a step further and provides an automated process using Kubernetes\* to save and restore BIOS and firmware settings. To do this, the Intel® System Configuration Utility is packaged as a pod and deployed as a Kubernetes job that uses ConfigMap. This ConfigMap provides a mount point that has the BIOS and firmware profile that needs to be used for the node. A platform reboot is required for the BIOS and firmware configuration to be applied. To enable this, the BIOS and firmware job is deployed as a privileged pod.
 
- ![BIOS and Firmware configuration on OpenNESS](biosfw-images/openness_biosfw.png)
+ ![BIOS and Firmware configuration on Smart Edge Open](biosfw-images/smartedge-open_biosfw.png)
 
- _Figure - BIOS and Firmware configuration on OpenNESS_
+ _Figure - BIOS and Firmware configuration on Smart Edge Open_
 
-## Details: BIOS and firmware configuration on OpenNESS Network Edge
+## Details: BIOS and firmware configuration on Smart Edge Open Network Edge
 
 BIOS and firmware configuration features are wrapped in a kubectl plugin.
 Knowledge of Intel SYSCFG utility is required for usage.
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-dedicated-core-cmk-deprecated.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-dedicated-core-cmk-deprecated.md
similarity index 92%
rename from doc/building-blocks/enhanced-platform-awareness/openness-dedicated-core-cmk-deprecated.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-dedicated-core-cmk-deprecated.md
index cf12441a..fcfce4bf 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-dedicated-core-cmk-deprecated.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-dedicated-core-cmk-deprecated.md
@@ -3,11 +3,11 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019-2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# Dedicated CPU core for workload support in OpenNESS
+# Dedicated CPU core for workload support in Smart Edge Open
 **CMK support was deprecated in Openess release 21.03 and replaced with Kubernetes native CPU Manager***
 
 - [Overview](#overview)
-- [Details - CPU Manager support in OpenNESS](#details---cpu-manager-support-in-openness)
+- [Details - CPU Manager support in Smart Edge Open](#details---cpu-manager-support-in-smart-edge-open)
   - [Setup](#setup)
   - [Usage](#usage)
 - [Reference](#reference)
@@ -23,9 +23,9 @@ The following are typical usages of this feature.
 
 - Consider an edge application that uses an AI library such as OpenVINO™ for inference. This library uses a special instruction set on the CPU to get a higher performance for the AI algorithm. To achieve a deterministic inference rate, the application thread executing the algorithm needs a dedicated CPU core so that there is no interference from other threads or other application pods (noisy neighbor).
 
-![CPU Manager support on OpenNESS ](cmk-images/cmk2.png)
+![CPU Manager support on Smart Edge Open ](cmk-images/cmk2.png)
 
-_Figure - CPU Manager support on OpenNESS_
+_Figure - CPU Manager support on Smart Edge Open_
 
 >**NOTE**: With Linux CPU isolation and CPU Manager for Kubernetes\* (CMK), a certain amount of isolation can be achieved but not all the kernel threads can be moved away.
 
@@ -41,7 +41,7 @@ The following section outlines some considerations for using CMK:
 
 CMK accomplishes core isolation by controlling what logical CPUs each container may use for execution by wrapping target application commands with the CMK command-line program. The CMK wrapper program maintains state in a directory hierarchy on disk that describes pools from which user containers can acquire available CPU lists. These pools can be exclusive (only one container per CPU list) or non-exclusive (multiple containers can share a CPU list.) Each CPU list directory contains a task file that tracks process IDs of the container subcommand(s) that acquired the CPU list. When the child process exits, the CMK wrapper program clears its PID from the tasks file. If the wrapper program is killed before it can perform this cleanup step, a separate periodic reconciliation program detects this condition and cleans the tasks file accordingly. A file system lock guards against conflicting concurrent modifications.
 
-## Details - CPU Manager support in OpenNESS
+## Details - CPU Manager support in Smart Edge Open
 
 [CPU Manager for Kubernetes (CMK)](https://github.com/intel/CPU-Manager-for-Kubernetes) is a Kubernetes plugin that provides core affinity for applications deployed as Kubernetes pods. It is advised to use “isolcpus” for core isolation when using CMK (otherwise full isolation cannot be guaranteed).
 
@@ -52,7 +52,7 @@ CMK documentation available on GitHub\* includes:
 - [operator manual](https://github.com/intel/CPU-Manager-for-Kubernetes/blob/master/docs/operator.md)
 - [user manual](https://github.com/intel/CPU-Manager-for-Kubernetes/blob/master/docs/user.md)
 
-CMK can be deployed using a [Helm chart](https://helm.sh/). The CMK Helm chart used in OpenNESS deployment is available on the following GitHub repository: [container-experience-kits](https://github.com/intel/container-experience-kits/tree/master/roles/cmk_install).
+CMK can be deployed using a [Helm chart](https://helm.sh/). The CMK Helm chart used in Smart Edge Open deployment is available on the following GitHub repository: [container-experience-kits](https://github.com/intel/container-experience-kits/tree/master/roles/cmk_install).
 
 ### Setup
 
@@ -79,7 +79,7 @@ CMK can be deployed using a [Helm chart](https://helm.sh/). The CMK Helm chart u
 The environment setup can be validated using steps from the [CMK operator manual](https://github.com/intel/CPU-Manager-for-Kubernetes/blob/master/docs/operator.md#validating-the-environment).
 
 **Note:**
-Up to version 20.12 choosing flavor was optional. Since version 21.03 and moving forward this parameter is no longer optional. To learn more about [flavors go to this page](https://github.com/open-ness/specs/blob/master/doc/flavors.md).
+Up to version 20.12 choosing flavor was optional. Since version 21.03 and moving forward this parameter is no longer optional. To learn more about [flavors go to this page](https://github.com/smart-edge-open/specs/blob/master/doc/flavors.md).
 
 ### Usage
 
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-dedicated-core.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-dedicated-core.md
similarity index 97%
rename from doc/building-blocks/enhanced-platform-awareness/openness-dedicated-core.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-dedicated-core.md
index a33a04d5..2d77ac7a 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-dedicated-core.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-dedicated-core.md
@@ -3,10 +3,10 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019-2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# Dedicated CPU core for workload support in OpenNESS
+# Dedicated CPU core for workload support in Smart Edge Open
 - [Overview](#overview)
   - [What is Kubernetes Native CPU management?](#what-is-kubernetes-native-cpu-management)
-- [Details - CPU Manager support in OpenNESS](#details---cpu-manager-support-in-openness)
+- [Details - CPU Manager support in Smart Edge Open](#details---cpu-manager-support-in-smart-edge-open)
   - [Setup](#setup)
   - [CPU Manager QoS classes](#cpu-manager-qos-classes)
   - [POD definitions](#pod-definitions)
@@ -35,7 +35,7 @@ Default kubelet configuration uses [CFS quota](https://en.wikipedia.org/wiki/Com
 Another, default for Openness, solution supported by Kubernetes is CPU manager. CPU manager uses [Linux CPUSET](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt) mechanism to schedule PODS to invividual CPUs. Kubernetes defines shared pool of CPUs which initially contains all the system CPUs without CPUs reverved for system and kubelet itself. CPU selection is configurable with kubelet options. Kubernetes uses shared CPU pool to schedule PODs with three QoS classes `BestEffort`, `Burstable` and `Guaranteed`.
 When POD is qualified as `Guaranteed` QoS class then kubelet removes requested CPUs amount from shared pool and assigns the POD exclusively to the CPUs.
 
-## Details - CPU Manager support in OpenNESS
+## Details - CPU Manager support in Smart Edge Open
 
 ### Setup
 
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-fpga.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-fpga.md
similarity index 81%
rename from doc/building-blocks/enhanced-platform-awareness/openness-fpga.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-fpga.md
index 3e071e93..efd9322f 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-fpga.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-fpga.md
@@ -3,19 +3,19 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019-2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# Using FPGA in OpenNESS: Programming, Resource Allocation, and Configuration
+# Using FPGA in Smart Edge Open: Programming, Resource Allocation, and Configuration
 - [Overview](#overview)
 - [Intel(R) FPGA PAC N3000 FlexRAN host interface overview](#intelr-fpga-pac-n3000-flexran-host-interface-overview)
 - [Intel(R) FPGA PAC N3000 orchestration and deployment with Kubernetes\* for FlexRAN](#intelr-fpga-pac-n3000-orchestration-and-deployment-with-kubernetes-for-flexran)
-- [Intel(R) FPGA PAC N3000 remote system update flow in OpenNESS Network edge Kubernetes](#intelr-fpga-pac-n3000-remote-system-update-flow-in-openness-network-edge-kubernetes)
-- [Using an FPGA on OpenNESS](#using-an-fpga-on-openness)
-  - [FPGA (FEC) Ansible installation for OpenNESS Network Edge](#fpga-fec-ansible-installation-for-openness-network-edge)
+- [Intel(R) FPGA PAC N3000 remote system update flow in Smart Edge Open Network edge Kubernetes](#intelr-fpga-pac-n3000-remote-system-update-flow-in-smart-edge-open-network-edge-kubernetes)
+- [Using an FPGA on Smart Edge Open](#using-an-fpga-on-smart-edge-open)
+  - [FPGA (FEC) Ansible installation for Smart Edge Open Network Edge](#fpga-fec-ansible-installation-for-smart-edge-open-network-edge)
     - [Converged Edge Experience Kits](#converged-edge-experience-kits)
-  - [FPGA programming and telemetry on OpenNESS Network Edge](#fpga-programming-and-telemetry-on-openness-network-edge)
+  - [FPGA programming and telemetry on Smart Edge Open Network Edge](#fpga-programming-and-telemetry-on-smart-edge-open-network-edge)
     - [Telemetry monitoring](#telemetry-monitoring)
-  - [FEC VF configuration for OpenNESS Network Edge](#fec-vf-configuration-for-openness-network-edge)
-  - [Requesting resources and running pods for OpenNESS Network Edge](#requesting-resources-and-running-pods-for-openness-network-edge)
-  - [Verifying Application POD access and usage of FPGA on OpenNESS Network Edge](#verifying-application-pod-access-and-usage-of-fpga-on-openness-network-edge)
+  - [FEC VF configuration for Smart Edge Open Network Edge](#fec-vf-configuration-for-smart-edge-open-network-edge)
+  - [Requesting resources and running pods for Smart Edge Open Network Edge](#requesting-resources-and-running-pods-for-smart-edge-open-network-edge)
+  - [Verifying Application POD access and usage of FPGA on Smart Edge Open Network Edge](#verifying-application-pod-access-and-usage-of-fpga-on-smart-edge-open-network-edge)
 - [Reference](#reference)
 
 ## Overview
@@ -28,7 +28,7 @@ The Intel® FPGA Programmable Acceleration Card (Intel® FPGA PAC) plays a key r
 
 The deployment of AI and machine learning (ML) applications at the edge is increasing the adoption of FPGA acceleration. This trend of devices performing machine learning at the edge locally versus relying solely on the cloud is driven by the need to lower latency, persistent availability, lower costs, and address privacy concerns.
 
-This document explains how the FPGA resource can be used on the Open Network Edge Services Software (OpenNESS) platform for accelerating network functions and edge application workloads. We use the Intel® FPGA PAC N3000 as a reference FPGA and use LTE/5G Forward Error Correction (FEC) as an example workload that accelerates the 5G or 4G L1 base station network function. The same concept and mechanism is applicable for application acceleration workloads like AI and ML on FPGA for Inference applications.
+This document explains how the FPGA resource can be used on the Open Network Edge Services Software (Smart Edge Open) platform for accelerating network functions and edge application workloads. We use the Intel® FPGA PAC N3000 as a reference FPGA and use LTE/5G Forward Error Correction (FEC) as an example workload that accelerates the 5G or 4G L1 base station network function. The same concept and mechanism is applicable for application acceleration workloads like AI and ML on FPGA for Inference applications.
 
 The Intel® FPGA PAC N3000 is a full-duplex, 100 Gbps in-system, re-programmable acceleration card for multi-workload networking application acceleration. It has an optimal memory mixture designed for network functions, with an integrated network interface card (NIC) in a small form factor that enables high throughput, low latency, and low power per bit for a custom networking pipeline.
 
@@ -42,25 +42,25 @@ The Intel® FPGA PAC N3000 card used in the FlexRAN solution exposes the followi
   - The 5GNR FEC IP components have low-density parity-check (LDPC) Encoder / LDPC Decoder, rate matching/de-matching, and UL HARQ combining
 - Interface for managing and updating the FPGA Image – Remote System Update (RSU).
 
-![PAC N3000 Host interface overview](fpga-images/openness-fpga1.png)
+![PAC N3000 Host interface overview](fpga-images/smartedge-open-fpga1.png)
 
 _Figure - PAC N3000 Host interface_
 ## Intel(R) FPGA PAC N3000 orchestration and deployment with Kubernetes\* for FlexRAN
 FlexRAN is a low-latency network function that implements the FEC. FlexRAN uses both FEC and Ethernet resources from the FPGA using POD resource allocation and the Kubernetes\* device plugin framework. Kubernetes provides a device plugin framework that is used to advertise system hardware resources to the Kubelet. Instead of customizing the code for Kubernetes (K8s) itself, vendors can implement a device plugin that can be deployed either manually or as a DaemonSet. The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand\* adapters, and other similar computing resources that may require vendor-specific initialization and setup.
 
-![Intel PAC N3000 Orchestration and deployment with OpenNESS Network Edge for FlexRAN](fpga-images/openness-fpga2.png)
+![Intel PAC N3000 Orchestration and deployment with Smart Edge Open Network Edge for FlexRAN](fpga-images/smartedge-open-fpga2.png)
 
-_Figure - Intel PAC N3000 Orchestration and deployment with OpenNESS Network Edge for FlexRAN_
+_Figure - Intel PAC N3000 Orchestration and deployment with Smart Edge Open Network Edge for FlexRAN_
 
-## Intel(R) FPGA PAC N3000 remote system update flow in OpenNESS Network edge Kubernetes
-A Remote System Update (RSU) of the FPGA is enabled through the Open Programmable Acceleration Engine (OPAE). The OPAE package consists of a kernel driver and a userspace FPGA utils package that enables programming of the FPGA. OpenNESS automates the process of deploying the OPAE stack as a Kubernetes POD, which detects the FPGA and programs it. There is a separate FPGA Configuration POD deployed as a Kubernetes job that configures FPGA resources such as virtual functions and queues.
+## Intel(R) FPGA PAC N3000 remote system update flow in Smart Edge Open Network edge Kubernetes
+A Remote System Update (RSU) of the FPGA is enabled through the Open Programmable Acceleration Engine (OPAE). The OPAE package consists of a kernel driver and a userspace FPGA utils package that enables programming of the FPGA. Smart Edge Open automates the process of deploying the OPAE stack as a Kubernetes POD, which detects the FPGA and programs it. There is a separate FPGA Configuration POD deployed as a Kubernetes job that configures FPGA resources such as virtual functions and queues.
 
-![OpenNESS Network Edge Intel PAC N3000 RSU and resource allocation](fpga-images/openness-fpga3.png)
+![Smart Edge Open Network Edge Intel PAC N3000 RSU and resource allocation](fpga-images/smartedge-open-fpga3.png)
 
-_Figure - OpenNESS Network Edge Intel® FPGA PAC N3000 RSU and resource allocation_
+_Figure - Smart Edge Open Network Edge Intel® FPGA PAC N3000 RSU and resource allocation_
 
-## Using an FPGA on OpenNESS
-Further sections provide instructions on how to use all three FPGA features: programming, configuration, and accessing from an application on the OpenNESS Network Edge.
+## Using an FPGA on Smart Edge Open
+Further sections provide instructions on how to use all three FPGA features: programming, configuration, and accessing from an application on the Smart Edge Open Network Edge.
 
 When the Intel® FPGA PAC N3000 is programmed with a vRAN 5G image, it exposes the Single Root I/O Virtualization (SRIOV) Virtual Function (VF) devices which can be used to accelerate the FEC in the vRAN workload. To take advantage of this functionality for a cloud-native deployment, the PF (Physical Function) of the device must be bound to the DPDK IGB_UIO userspace driver to create several VFs (Virtual Functions). Once the VFs are created, they must also be bound to a DPDK userspace driver to allocate them to specific K8s pods running the vRAN workload.
 
@@ -72,17 +72,17 @@ The full pipeline of preparing the device for workload deployment and deploying
 - Enabling orchestration and allocation of the devices (VFs) to non-root pods requesting the devices: leveraging the support of FPGA SRIOV VFs from K8s SRIOV Device Plugin. K8s plugin deployment is delivered as part of the Edge Controller's Ansible automation.
 - Simple sample DPDK BBDEV application to validate the pipeline (i.e., SRIOV creation - Queue configuration - Device orchestration - Pod deployment): Script delivery and instructions to build Docker image for sample application delivered as part of Edge Apps package.
 
-It is assumed that the FPGA is always used with the OpenNESS Network Edge, paired with the Multus\* plugin to enable the workload pod with a default K8s network interface. The Multus CNI is a container network interface (CNI) plugin for Kubernetes that enables attaching multiple network interfaces to pods.
+It is assumed that the FPGA is always used with the Smart Edge Open Network Edge, paired with the Multus\* plugin to enable the workload pod with a default K8s network interface. The Multus CNI is a container network interface (CNI) plugin for Kubernetes that enables attaching multiple network interfaces to pods.
 
-It is also assumed that the Intel® FPGA PAC N3000 MAX10 build version of the card used for OpenNESS setup is at least version 2.0.x and has RoT capability, ie:
+It is also assumed that the Intel® FPGA PAC N3000 MAX10 build version of the card used for Smart Edge Open setup is at least version 2.0.x and has RoT capability, ie:
 ```shell
 Board Management Controller, MAX10 NIOS FW version D.2.0.19
 Board Management Controller, MAX10 Build version D.2.0.6
 ```
 For information on how to update and flash the MAX10 to supported version see [Intel® FPGA PAC N3000 documentation](https://www.intel.com/content/www/us/en/programmable/documentation/xgz1560360700260.html#wzl1570122399760).
 
-### FPGA (FEC) Ansible installation for OpenNESS Network Edge
-To run the OpenNESS package with FPGA (FEC) functionality, the feature needs to be enabled on both Edge Controller and Edge Node.
+### FPGA (FEC) Ansible installation for Smart Edge Open Network Edge
+To run the Smart Edge Open package with FPGA (FEC) functionality, the feature needs to be enabled on both Edge Controller and Edge Node.
 
 #### Converged Edge Experience Kits
 To enable FPGA support from CEEK, change the variable `ne_opae_fpga_enable` in `inventory/default/group_vars/all/10-default.yml` (or flavor alternative file) to `true`:
@@ -91,7 +91,7 @@ To enable FPGA support from CEEK, change the variable `ne_opae_fpga_enable` in `
 ne_opae_fpga_enable: true
 ```
 
-Additionally, SRIOV must be enabled in OpenNESS:
+Additionally, SRIOV must be enabled in Smart Edge Open:
 ```yaml
 # inventory/default/group_vars/all/10-default.yml
 kubernetes_cnis:
@@ -153,7 +153,7 @@ openness      syslog-master-9x8hc                       1/1     Running   0
 openness      syslog-ng-br92z                           1/1     Running   0          3d18h
 ```
 
-### FPGA programming and telemetry on OpenNESS Network Edge
+### FPGA programming and telemetry on Smart Edge Open Network Edge
 It is expected the the factory image of the Intel® FPGA PAC N3000 is of version 2.0.x. To program the user image (5GN FEC vRAN) of the Intel® FPGA PAC N3000 via OPAE a `kubectl` plugin for K8s is provided - it is expected that the provided user image is signed or un-signed (development purposes) by the user, see the [documentation](https://www.intel.com/content/www/us/en/programmable/documentation/pei1570494724826.html) for more information on how to sign/un-sign the image file. The plugin also allows for obtaining basic FPGA telemetry. This plugin will deploy K8s jobs that run to completion on the desired host and display the logs/output of the command.
 
 The following are the operations supported by the `kubectl rsu` K8s plugin. They are run from the Edge Controller (the user who runs the commands needs to be a privileged user):
@@ -220,11 +220,11 @@ To run vRAN workloads on the Intel® FPGA PAC N3000, the FPGA must be programmed
 
 #### Telemetry monitoring
 
-  Support for monitoring temperature and power telemetry of the Intel® FPGA PAC N3000 is also provided from OpenNESS with a CollectD collector that is configured for the `flexran` flavor. Intel® FPGA PAC N3000 telemetry monitoring is provided to CollectD as a plugin. It collects the temperature and power metrics from the card and exposes them to Prometheus\* from which the user can easily access the metrics. For more information on how to enable telemetry for FPGA in OpenNESS, see the [telemetry whitepaper](../../building-blocks/enhanced-platform-awareness/openness-telemetry.md#collectd).
+  Support for monitoring temperature and power telemetry of the Intel® FPGA PAC N3000 is also provided from Smart Edge Open with a CollectD collector that is configured for the `flexran` flavor. Intel® FPGA PAC N3000 telemetry monitoring is provided to CollectD as a plugin. It collects the temperature and power metrics from the card and exposes them to Prometheus\* from which the user can easily access the metrics. For more information on how to enable telemetry for FPGA in Smart Edge Open, see the [telemetry whitepaper](../../building-blocks/enhanced-platform-awareness/smartedge-open-telemetry.md#collectd).
 
-  ![PACN3000 telemetry](fpga-images/openness-fpga4.png)
+  ![PACN3000 telemetry](fpga-images/smartedge-open-fpga4.png)
 
-### FEC VF configuration for OpenNESS Network Edge
+### FEC VF configuration for Smart Edge Open Network Edge
 To configure the VFs with the necessary number of queues for the vRAN workload the BBDEV configuration utility is run as a job within a privileged container. The configuration utility is available to run as a Helm chart available from `/opt/openness/helm-charts/bb_config`.
 
 Sample configMap, which can be configured by changing values if other than typical configuration is required, with a profile for the queue configuration, is provided as part of Helm chart template `/opt/openness/helm-charts/bb_config/templates/fpga-config.yaml` populated with values from `/opt/openness/helm-charts/bb_config/values.yaml`. Helm chart installation requires a provision of hostname for the target node during job deployment.
@@ -253,8 +253,8 @@ To uninstall the job, run:
 helm uninstall intel-fpga-cfg
 ```
 
-### Requesting resources and running pods for OpenNESS Network Edge
-As part of the OpenNESS Ansible automation, a K8s SRIOV device plugin to orchestrate the FPGA VFs (bound to the userspace driver) is running. This enables the scheduling of pods requesting this device. To check the number of devices available on the Edge Node from Edge Controller, run:
+### Requesting resources and running pods for Smart Edge Open Network Edge
+As part of the Smart Edge Open Ansible automation, a K8s SRIOV device plugin to orchestrate the FPGA VFs (bound to the userspace driver) is running. This enables the scheduling of pods requesting this device. To check the number of devices available on the Edge Node from Edge Controller, run:
 
 ```shell
 kubectl get node <node_name> -o json | jq '.status.allocatable'
@@ -263,7 +263,7 @@ kubectl get node <node_name> -o json | jq '.status.allocatable'
 ```
 
 To request the device as a resource in the pod, add the request for the resource into the pod specification file by specifying its name and amount of resources required. If the resource is not available or the amount of resources requested is greater than the number of resources available, the pod status will be “Pending” until the resource is available.
-**NOTE**: The name of the resource must match the name specified in the configMap for the K8s devices plugin [configMap.yml](https://github.com/open-ness/converged-edge-experience-kits/blob/master/roles/kubernetes/cni/sriov/controlplane/templates/configMap.yml.j2).
+**NOTE**: The name of the resource must match the name specified in the configMap for the K8s devices plugin [configMap.yml](https://github.com/smart-edge-open/converged-edge-experience-kits/blob/master/roles/kubernetes/cni/sriov/controlplane/templates/configMap.yml.j2).
 
 A sample pod requesting the FPGA (FEC) VF may look like this:
 
@@ -302,7 +302,7 @@ To check the number of devices currently allocated to pods, run (and search for
 kubectl describe node <node_host_name>
 ```
 
-### Verifying Application POD access and usage of FPGA on OpenNESS Network Edge
+### Verifying Application POD access and usage of FPGA on Smart Edge Open Network Edge
 To verify the functionality of all the sub-features are working together (SRIOV binding - K8s device plugin - BBDEV config) and functionality of the FPGA (FEC) VF inside a non-root pod, build a Docker image and run a simple validation application for the device.
 
 The automation of the Docker image build is available from the Edge Apps package. The image must be built on the same node that it is meant to be deployed or a server with the same configuration as the node that will run the workload. This is due to the Kernel dependencies of DPDK during the application build.
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-hugepage.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-hugepage.md
similarity index 95%
rename from doc/building-blocks/enhanced-platform-awareness/openness-hugepage.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-hugepage.md
index 60bf2a27..d8bdd9df 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-hugepage.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-hugepage.md
@@ -3,9 +3,9 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019-2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# HugePage support in OpenNESS
+# HugePage support in Smart Edge Open
 - [Overview](#overview)
-- [Details of HugePage support on OpenNESS](#details-of-hugepage-support-on-openness)
+- [Details of HugePage support on Smart Edge Open](#details-of-hugepage-support-on-smart-edge-open)
   - [Examples](#examples)
     - [Changing size and amount of the hugepages for both controller and nodes](#changing-size-and-amount-of-the-hugepages-for-both-controller-and-nodes)
     - [Customizing hugepages for specific machine](#customizing-hugepages-for-specific-machine)
@@ -17,9 +17,9 @@ Memory is allocated to application processes in terms of pages and by default, 4
 
 Both applications and network functions can improve performance using HugePages. Huge page support, added to Kubernetes\* v1.8, enables the discovery, scheduling, and allocation of huge pages as a native, first-class resource. This support addresses low latency and deterministic memory access requirements.
 
-## Details of HugePage support on OpenNESS
+## Details of HugePage support on Smart Edge Open
 
-Deployment of OpenNESS' minimal flavor does not enable the hugepages.
+Deployment of Smart Edge Open' minimal flavor does not enable the hugepages.
 To enable hugepages either use flavor that supports hugepages (e.g. flexran) or enable hugepages by editing `default_grub_params` variable in `group_vars` and/or `host_vars`. Suggested value for hugepage enablement is `default_hugepagesz={{ hugepage_size }} hugepagesz={{ hugepage_size }} hugepages={{ hugepage_amount }}`.
 
 Next, following parameters can be used for tuning hugepages:
@@ -32,7 +32,7 @@ Previously default values were:
 | Controller   | `1024`            | `2M`            |
 | Node         | `1024`            | `2M`            |
 
-Find below a guide on changing these values. Customizations must be made before OpenNESS deployment.
+Find below a guide on changing these values. Customizations must be made before Smart Edge Open deployment.
 
 Variables for hugepage customization can be placed in several files:
 * `inventory/default/group_vars/controller_group/10-default.yml` and `inventory/default/group_vars/edgenode_group/10-default.yml` will affect Edge Controller and Edge Nodes
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-node-feature-discovery.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-node-feature-discovery.md
similarity index 82%
rename from doc/building-blocks/enhanced-platform-awareness/openness-node-feature-discovery.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-node-feature-discovery.md
index fe648d1b..906ec492 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-node-feature-discovery.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-node-feature-discovery.md
@@ -3,10 +3,10 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019 Intel Corporation
 ```
 <!-- omit in toc -->
-# Node Feature Discovery support in OpenNESS
+# Node Feature Discovery support in Smart Edge Open
 - [Overview of NFD and Edge usecase](#overview-of-nfd-and-edge-usecase)
 - [Details](#details)
-  - [Node Feature Discovery support in OpenNESS Network Edge](#node-feature-discovery-support-in-openness-network-edge)
+  - [Node Feature Discovery support in Smart Edge Open Network Edge](#node-feature-discovery-support-in-smart-edge-open-network-edge)
     - [Usage](#usage)
 - [Reference](#reference)
 
@@ -18,7 +18,7 @@ Consider an edge application such as CDN that needs to be deployed in the cloud-
 
 Next, consider a Container Network Function (CNF) such as 5G gNb that implements L1 5G NR base station. It is favorable for the container orchestrator like Kubernetes to detect nodes that have hardware and software features—FPGA acceleration for Forward Error Correction (FEC), advanced vector instructions to implement math functions, real-time kernel, etc.
 
-OpenNESS supports the discovery of such features using Node Feature Discovery (NFD). NFD is a Kubernetes add-on that detects and advertises hardware and software capabilities of a platform that can, in turn, be used to facilitate intelligent scheduling of a workload. NFD is one of the technologies from Intel that supports targeting of intelligent configuration and capacity consumption of platform capabilities. NFD runs as a separate container on each node of the cluster, discovers the capabilities of the node, and finally, publishes these as node labels using the Kubernetes API. NFD only handles non-allocatable features.
+Smart Edge Open supports the discovery of such features using Node Feature Discovery (NFD). NFD is a Kubernetes add-on that detects and advertises hardware and software capabilities of a platform that can, in turn, be used to facilitate intelligent scheduling of a workload. NFD is one of the technologies from Intel that supports targeting of intelligent configuration and capacity consumption of platform capabilities. NFD runs as a separate container on each node of the cluster, discovers the capabilities of the node, and finally, publishes these as node labels using the Kubernetes API. NFD only handles non-allocatable features.
 
 Some of the Node features that NFD can detect include:
 
@@ -46,13 +46,13 @@ _Figure - CDN app deployment with NFD Features_
 
 ## Details
 
-### Node Feature Discovery support in OpenNESS Network Edge
+### Node Feature Discovery support in Smart Edge Open Network Edge
 
-Node Feature Discovery is enabled by default. It does not require any configuration or user input. It can be disabled by changing the `ne_nfd_enable` variable to `false` in the `inventory/default/group_vars/all/10-default.yml` before the OpenNESS installation.
+Node Feature Discovery is enabled by default. It does not require any configuration or user input. It can be disabled by changing the `ne_nfd_enable` variable to `false` in the `inventory/default/group_vars/all/10-default.yml` before the Smart Edge Open installation.
 
 The connection between `nfd-nodes` and `nfd-control-plane` is secured by certificates generated before running NFD pods.
 
-Node Feature Discovery is deployed in OpenNESS using a Helm chart downloaded from [container-experience-kits](https://github.com/intel/container-experience-kits/tree/master/roles/nfd_install/charts/node-feature-discovery) repository.
+Node Feature Discovery is deployed in Smart Edge Open using a Helm chart downloaded from [container-experience-kits](https://github.com/intel/container-experience-kits/tree/master/roles/nfd_install/charts/node-feature-discovery) repository.
 
 #### Usage
 
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-qat.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-qat.md
similarity index 85%
rename from doc/building-blocks/enhanced-platform-awareness/openness-qat.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-qat.md
index b89bd89b..82199970 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-qat.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-qat.md
@@ -3,14 +3,14 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2021 Intel Corporation
 ```
 <!-- omit in toc -->
-# Using Intel® QuickAssist Adapter in OpenNESS: Resource Allocation, and Configuration
+# Using Intel® QuickAssist Adapter in Smart Edge Open: Resource Allocation, and Configuration
 - [Overview](#overview)
 - [Intel QuickAssist Adapter CU/DU Host Interface Overview](#intel-quickassist-adapter-cudu-host-interface-overview)
 - [Intel QuickAssist Adapter Device Plugin Deployment with Kubernetes\* for CU/DU](#intel-quickassist-adapter-device-plugin-deployment-with-kubernetes-for-cudu)
-- [Using the Intel QuickAssist Adapter on OpenNESS](#using-the-intel-quickassist-adapter-on-openness)
-  - [Intel QuickAssist Adapter for OpenNESS Network Edge](#intel-quickassist-adapter-for-openness-network-edge)
+- [Using the Intel QuickAssist Adapter on Smart Edge Open](#using-the-intel-quickassist-adapter-on-smart-edge-open)
+  - [Intel QuickAssist Adapter for Smart Edge Open Network Edge](#intel-quickassist-adapter-for-smart-edge-open-network-edge)
     - [Converged Edge Experience Kits (CEEK)](#converged-edge-experience-kits-ceek)
-  - [Requesting Resources and Running Pods for OpenNESS Network Edge](#requesting-resources-and-running-pods-for-openness-network-edge)
+  - [Requesting Resources and Running Pods for Smart Edge Open Network Edge](#requesting-resources-and-running-pods-for-smart-edge-open-network-edge)
   - [Verification of the QAT and the Device Plugin](#verification-of-the-qat-and-the-device-plugin)
 - [Reference](#reference)
 
@@ -38,7 +38,7 @@ Intel® QuickAssist Adapter benefits include:
 
 For more information, see product brief in [Intel® QuickAssist Adapter](https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/quickassist-adapter-8960-8970-brief.pdf).
 
-This document explains how the Intel® QuickAssist (QAT) device plugin is enabled and used on the Open Network Edge Services Software (OpenNESS) platform for accelerating network functions and edge application workloads. The Intel® QuickAssist Adapter is used to accelerate the LTE/5G encryption tasks in the CU/DU.
+This document explains how the Intel® QuickAssist (QAT) device plugin is enabled and used on the Open Network Edge Services Software (Smart Edge Open) platform for accelerating network functions and edge application workloads. The Intel® QuickAssist Adapter is used to accelerate the LTE/5G encryption tasks in the CU/DU.
 
 ## Intel QuickAssist Adapter CU/DU Host Interface Overview
 Intel® QuickAssist Adapter used in the CU/DU solution exposes the following Physical Functions (PF) to the CPU host:
@@ -47,8 +47,8 @@ Intel® QuickAssist Adapter used in the CU/DU solution exposes the following Phy
 ## Intel QuickAssist Adapter Device Plugin Deployment with Kubernetes\* for CU/DU
 CU/DU applications use the `qat.intel.com/generic` resources from the Intel® QuickAssist Adapter using POD resource allocation and the Kubernetes\* device plugin framework. Kubernetes* provides a device plugin framework that is used to advertise system hardware resources to the Kubelet. Instead of customizing the code for Kubernetes* (K8s) itself, vendors can implement a device plugin that can be deployed either manually or as a DaemonSet. The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand\* adapters, and other similar computing resources that may require vendor-specific initialization and setup.
 
-## Using the Intel QuickAssist Adapter on OpenNESS
-Further sections provide instructions on how to use the Intel® QuickAssist Adapter features: configuration and accessing from an application on the OpenNESS Network Edge.
+## Using the Intel QuickAssist Adapter on Smart Edge Open
+Further sections provide instructions on how to use the Intel® QuickAssist Adapter features: configuration and accessing from an application on the Smart Edge Open Network Edge.
 
 When the Intel® QuickAssist Adapter is available on the Edge Node platform it exposes three Root I/O Virtualization (SRIOV) Physical Functions (PF) devices which can be used to create Virtual Functions. To take advantage of this functionality for a cloud-native deployment, the PF (Physical Function) of the device must be bound to the DPDK IGB_UIO userspace driver to create several VFs (Virtual Functions). Once the VFs are created, they must also be bound to a DPDK userspace driver to allocate them to specific K8s pods running the vRAN workload.
 
@@ -59,14 +59,14 @@ The full pipeline of preparing the device for workload deployment and deploying
 - Queue configuration of QAT's PFs/VFs.
 - Binding QAT's PFs/VFs to igb_uio driver.
 
-### Intel QuickAssist Adapter for OpenNESS Network Edge
-To run the OpenNESS package with Intel® QuickAssist Adapter Device Plugin functionality, the feature needs to be enabled on both Edge Controller and Edge Node. It can be deployed by setting the following variable in the flavor or *group_vars/all* file in Converged Edge Experience Kits:
+### Intel QuickAssist Adapter for Smart Edge Open Network Edge
+To run the Smart Edge Open package with Intel® QuickAssist Adapter Device Plugin functionality, the feature needs to be enabled on both Edge Controller and Edge Node. It can be deployed by setting the following variable in the flavor or *group_vars/all* file in Converged Edge Experience Kits:
 ```yaml
 qat_device_plugin_enable: true
 ```
 
 #### Converged Edge Experience Kits (CEEK)
-To enable Intel® QuickAssist Adapter Device Plugin support from CEEK, SRIOV must be enabled in OpenNESS:
+To enable Intel® QuickAssist Adapter Device Plugin support from CEEK, SRIOV must be enabled in Smart Edge Open:
 ```yaml
 kubernetes_cnis:
 - <primary CNI>
@@ -85,8 +85,8 @@ NAME                        READY   STATUS    RESTARTS   AGE
 intel-qat-plugin-dl42c      1/1     Running   0          7d9h
 ```
 
-### Requesting Resources and Running Pods for OpenNESS Network Edge
-As part of the OpenNESS Ansible automation, a K8s SRIOV device plugin to orchestrate the Intel® QuickAssist Adapter VFs (bound to the userspace driver) is deployed and running. This enables the scheduling of pods requesting this device. To check the number of devices available on the Edge Node from Edge Controller, run:
+### Requesting Resources and Running Pods for Smart Edge Open Network Edge
+As part of the Smart Edge Open Ansible automation, a K8s SRIOV device plugin to orchestrate the Intel® QuickAssist Adapter VFs (bound to the userspace driver) is deployed and running. This enables the scheduling of pods requesting this device. To check the number of devices available on the Edge Node from Edge Controller, run:
 
 ```shell
 kubectl get node $(hostname) -o json | jq '.status.allocatable'
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-rmd.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-rmd.md
similarity index 96%
rename from doc/building-blocks/enhanced-platform-awareness/openness-rmd.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-rmd.md
index a0b40463..408887d4 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-rmd.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-rmd.md
@@ -12,7 +12,7 @@ Copyright (c) 2020 Intel Corporation
   - [Code and Data Prioritization (CDP)](#code-and-data-prioritization-cdp)
   - [Memory Bandwidth Monitoring (MBM)](#memory-bandwidth-monitoring-mbm)
   - [Memory Bandwidth Allocation (MBA)](#memory-bandwidth-allocation-mba)
-- [OpenNESS RDT support](#openness-rdt-support)
+- [Smart Edge Open RDT support](#smart-edge-open-rdt-support)
 - [Usage](#usage)
 - [Example setup for running the benchmarks](#example-setup-for-running-the-benchmarks)
   - [Pod1 on coreA](#pod1-on-corea)
@@ -44,16 +44,16 @@ Multiple VMs or applications can be tracked independently via Memory Bandwidth M
 ### Memory Bandwidth Allocation (MBA)
 MBA enables approximate and indirect control over memory bandwidth available to workloads, enabling new levels of interference mitigation and bandwidth shaping for “noisy neighbors” present on the system.
 
-## OpenNESS RDT support
-> OpenNESS supports Cache Allocation and Cache Monitoring in the current release.
+## Smart Edge Open RDT support
+> Smart Edge Open supports Cache Allocation and Cache Monitoring in the current release.
 >  
 This feature allows you to allocate a guaranteed number of cache ways for a container. This is useful when you need consistent performance or need to meet real-time requirements.
 This feature depends on the [RMD Daemon](https://github.com/intel/rmd/) and the Kubernetes [RMD Operator](https://github.com/intel/rmd-operator) to control it.
 For more information about cache allocation and available cache pools, refer to the [RMD cache pools](https://github.com/intel/rmd/#cache-poolsgroups)
-This feature is for the OpenNESS Network Edge deployment mode.
+This feature is for the Smart Edge Open Network Edge deployment mode.
 
 ## Usage
-Enable the RMD feature in *inventory/default/group_vars/all/10-default.yml* when installing OpenNESS (Under the Network Edge section):
+Enable the RMD feature in *inventory/default/group_vars/all/10-default.yml* when installing Smart Edge Open (Under the Network Edge section):
 > rmd_operator_enable: True
 > 
 This will install the underlying infrastructure. Please note you need to use the FlexRAN flavor for RMD to work.
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-sriov-multiple-interfaces.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-sriov-multiple-interfaces.md
similarity index 77%
rename from doc/building-blocks/enhanced-platform-awareness/openness-sriov-multiple-interfaces.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-sriov-multiple-interfaces.md
index 01454063..6db1eb9f 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-sriov-multiple-interfaces.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-sriov-multiple-interfaces.md
@@ -3,12 +3,12 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019-2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# Multiple Interface and PCIe\* SR-IOV Support in OpenNESS
+# Multiple Interface and PCIe\* SR-IOV Support in Smart Edge Open
 - [Overview](#overview)
   - [Overview of Multus](#overview-of-multus)
   - [Overview of SR-IOV CNI](#overview-of-sr-iov-cni)
   - [Overview of SR-IOV Device Plugin](#overview-of-sr-iov-device-plugin)
-- [Details - Multiple Interface and PCIe\* SRIOV support in OpenNESS](#details---multiple-interface-and-pcie-sriov-support-in-openness)
+- [Details - Multiple Interface and PCIe\* SRIOV support in Smart Edge Open](#details---multiple-interface-and-pcie-sriov-support-in-smart-edge-open)
   - [Multus usage](#multus-usage)
   - [SR-IOV configuration and usage](#sr-iov-configuration-and-usage)
     - [Edge Node SR-IOV interfaces configuration](#edge-node-sr-iov-interfaces-configuration)
@@ -25,7 +25,7 @@ To address this, two key networking features must be enabled:
 
 ### Overview of Multus
 
-To enable multiple interface support in pods, OpenNESS Network Edge uses the Multus\* container network interface. Multus CNI is a container network interface (CNI) plugin for Kubernetes that enables the attachment of multiple network interfaces to pods. Typically, in Kubernetes, each pod only has one network interface (apart from a loopback). With Multus, you can create a multi-homed pod that has multiple interfaces. To accomplish this, Multus acts as a “meta-plugin”, a CNI plugin that can call multiple other CNI plugins. The Multus CNI follows the Kubernetes Network Custom Resource Definition De-facto Standard to provide a standardized method by which to specify the configurations for additional network interfaces. This standard is put forward by the Kubernetes Network Plumbing Working Group.
+To enable multiple interface support in pods, Smart Edge Open Network Edge uses the Multus\* container network interface. Multus CNI is a container network interface (CNI) plugin for Kubernetes that enables the attachment of multiple network interfaces to pods. Typically, in Kubernetes, each pod only has one network interface (apart from a loopback). With Multus, you can create a multi-homed pod that has multiple interfaces. To accomplish this, Multus acts as a “meta-plugin”, a CNI plugin that can call multiple other CNI plugins. The Multus CNI follows the Kubernetes Network Custom Resource Definition De-facto Standard to provide a standardized method by which to specify the configurations for additional network interfaces. This standard is put forward by the Kubernetes Network Plumbing Working Group.
 
 The figure below illustrates the network interfaces attached to a pod, as provisioned by the Multus CNI. The diagram shows the pod with three interfaces: eth0, net0, and net1. eth0 connects to the Kubernetes cluster network to connect with the Kubernetes server/services (kubernetes api-server, kubelet, etc.). net0 and net1 are additional network attachments and they connect to other networks by using other CNI plugins (e.g., vlan/vxlan/ptp).
 
@@ -35,7 +35,7 @@ _Figure - Multus Overview_
 
 ### Overview of SR-IOV CNI
 
-The Single Root I/O Virtualization (SR-IOV) feature provides the ability to partition a single physical PCI resource into virtual PCI functions that can be allocated to application and network function pods. To enable SR-IOV device resource allocation and CNI, OpenNESS Network Edge uses the SR-IOV CNI and SR-IOV Device Plugin. The SR-IOV CNI plugin enables the Kubernetes pod to be attached directly to an SR-IOV virtual function (VF) using the standard SR-IOV VF driver in the container host’s kernel.
+The Single Root I/O Virtualization (SR-IOV) feature provides the ability to partition a single physical PCI resource into virtual PCI functions that can be allocated to application and network function pods. To enable SR-IOV device resource allocation and CNI, Smart Edge Open Network Edge uses the SR-IOV CNI and SR-IOV Device Plugin. The SR-IOV CNI plugin enables the Kubernetes pod to be attached directly to an SR-IOV virtual function (VF) using the standard SR-IOV VF driver in the container host’s kernel.
 
 ![SR-IOV CNI](multussriov-images/sriov-cni.png)
 
@@ -50,7 +50,7 @@ The Intel SR-IOV Network device plugin discovers and exposes SR-IOV network reso
 
 _Figure - SR-IOV Device plugin_
 
-## Details - Multiple Interface and PCIe\* SRIOV support in OpenNESS
+## Details - Multiple Interface and PCIe\* SRIOV support in Smart Edge Open
 
 In Network Edge mode, the Multus CNI, which provides the possibility for attaching multiple interfaces to the pod, is deployed automatically when the `kubernetes_cnis` variable list (in the `inventory/default/group_vars/all/10-default.yml` file) contains at least two elements, e.g.,:
 ```yaml
@@ -61,7 +61,7 @@ kubernetes_cnis:
 
 ### Multus usage
 
-Multus CNI is deployed in OpenNESS using a Helm chart. The Helm chart is available in [converged-edge-experience-kits](https://github.com/open-ness/converged-edge-experience-kits/tree/master/roles/kubernetes/cni/multus/controlplane/files/multus-cni). The Multus image is pulled by Ansible\* Multus role and pushed to a local Docker\* registry on Edge Controller.
+Multus CNI is deployed in Smart Edge Open using a Helm chart. The Helm chart is available in [converged-edge-experience-kits](https://github.com/smart-edge-open/converged-edge-experience-kits/tree/master/roles/kubernetes/cni/multus/controlplane/files/multus-cni). The Multus image is pulled by Ansible\* Multus role and pushed to a local Docker\* registry on Edge Controller.
 
 [Custom resource definition](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) (CRD) is used to define an additional network that can be used by Multus.
 
@@ -123,14 +123,14 @@ EOF
 
 ### SR-IOV configuration and usage
 
-To deploy the OpenNESS' Network Edge with SR-IOV, `sriov` must be added to the `kubernetes_cnis` list in `inventory/default/group_vars/all/10-default.yml`:
+To deploy the Smart Edge Open' Network Edge with SR-IOV, `sriov` must be added to the `kubernetes_cnis` list in `inventory/default/group_vars/all/10-default.yml`:
 ```yaml
 kubernetes_cnis:
 - calico
 - sriov
 ```
 
-SR-IOV CNI and device plugin are deployed in OpenNESS using Helm chart. The Helm chart is available in [converged-edge-experience-kits](https://github.com/open-ness/converged-edge-experience-kits/tree/master/roles/kubernetes/cni/sriov/controlplane/files/sriov). Additional chart templates for SR-IOV device plugin can be downloaded from [container-experience-kits repository](https://github.com/intel/container-experience-kits/tree/master/roles/sriov_dp_install/charts/sriov-net-dp/templates). SR-IOV images are built from source by the Ansible SR-IOV role and pushed to a local Harbor registry on Edge Controller.
+SR-IOV CNI and device plugin are deployed in Smart Edge Open using Helm chart. The Helm chart is available in [converged-edge-experience-kits](https://github.com/smart-edge-open/converged-edge-experience-kits/tree/master/roles/kubernetes/cni/sriov/controlplane/files/sriov). Additional chart templates for SR-IOV device plugin can be downloaded from [container-experience-kits repository](https://github.com/intel/container-experience-kits/tree/master/roles/sriov_dp_install/charts/sriov-net-dp/templates). SR-IOV images are built from source by the Ansible SR-IOV role and pushed to a local Harbor registry on Edge Controller.
 
 #### Edge Node SR-IOV interfaces configuration
 
@@ -148,7 +148,7 @@ sriov:
 
 
 #### Usage
-SRIOV plugins use [Multus](#multus-plugin), and the usage is very similar to the one described above. By default, OpenNESS will create network `sriov-openness`, which can be used to attach VFs. Find the `sriov-openness` network's CRD below:
+SRIOV plugins use [Multus](#multus-plugin), and the usage is very similar to the one described above. By default, Smart Edge Open will create network `sriov-openness`, which can be used to attach VFs. Find the `sriov-openness` network's CRD below:
 
 ```yaml
 apiVersion: "k8s.cni.cncf.io/v1"
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-telemetry.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-telemetry.md
similarity index 76%
rename from doc/building-blocks/enhanced-platform-awareness/openness-telemetry.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-telemetry.md
index 80368545..485356c1 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-telemetry.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-telemetry.md
@@ -3,7 +3,7 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# Telemetry Support in OpenNESS
+# Telemetry Support in Smart Edge Open
 - [Overview](#overview)
 - [Architecture](#architecture)
 - [Flavors and configuration](#flavors-and-configuration)
@@ -29,13 +29,13 @@ Copyright (c) 2020 Intel Corporation
 - [Summary](#summary)
 
 ## Overview
-OpenNESS supports platform and application telemetry with the aid of multiple telemetry projects. This support allows users to retrieve information about the platform, the underlying hardware, cluster, and applications deployed. The data gathered by telemetry can be used to visualize metrics and resource consumption, set up alerts for certain events, and aid in making scheduling decisions based on the received telemetry. With the telemetry data at a user's disposal, a mechanism is also provided to schedule workloads based on the data available.
+Smart Edge Open supports platform and application telemetry with the aid of multiple telemetry projects. This support allows users to retrieve information about the platform, the underlying hardware, cluster, and applications deployed. The data gathered by telemetry can be used to visualize metrics and resource consumption, set up alerts for certain events, and aid in making scheduling decisions based on the received telemetry. With the telemetry data at a user's disposal, a mechanism is also provided to schedule workloads based on the data available.
 
 Currently, the support for telemetry is focused on metrics; support for application tracing telemetry is planned in the future.
 
 ## Architecture
 
-The telemetry components used in OpenNESS are deployed from the Edge Controller as Kubernetes\* (K8s) pods. Components for telemetry support include: 
+The telemetry components used in Smart Edge Open are deployed from the Edge Controller as Kubernetes\* (K8s) pods. Components for telemetry support include: 
 - collectors
 - metric aggregators
 - schedulers
@@ -47,7 +47,7 @@ Depending on the role of the component, it is deployed as either a `Deployment`
 
 ## Flavors and configuration
 
-The deployment of telemetry components in OpenNESS is easily configurable from the Converged Edge Experience Kits (CEEK). The deployment of the Grafana dashboard and PCM (Performance Counter Monitoring) collector is optional (`telemetry_grafana_enable` enabled by default, `telemetry_pcm_enable` disabled by default). There are four distinctive flavors for the deployment of the CollectD collector, enabling the respective set of plugins (`telemetry_flavor`):
+The deployment of telemetry components in Smart Edge Open is easily configurable from the Converged Edge Experience Kits (CEEK). The deployment of the Grafana dashboard and PCM (Performance Counter Monitoring) collector is optional (`telemetry_grafana_enable` enabled by default, `telemetry_pcm_enable` disabled by default). There are four distinctive flavors for the deployment of the CollectD collector, enabling the respective set of plugins (`telemetry_flavor`):
 
 - common (default)
 - flexran
@@ -58,7 +58,7 @@ Further information on what plugins each flavor enables can be found in the [Col
 
 ## Telemetry features
 
-This section provides an overview of each of the components supported within OpenNESS and a description of how to use these features.
+This section provides an overview of each of the components supported within Smart Edge Open and a description of how to use these features.
 
 ### Prometheus
 
@@ -69,11 +69,11 @@ Prometheus is an open-source, community-driven toolkit for systems monitoring an
 
 The main idea behind Prometheus is that it defines a unified metrics data format that can be hosted as part of any application that incorporates a simple web server. The data can be then scraped (downloaded) and processed by Prometheus using a simple HTTP/HTTPS connection.
 
-In OpenNESS, Prometheus is deployed as a K8s Deployment with a single pod/replica on the Edge Controller node. It is configured out of the box to scrape all other telemetry endpoints/collectors enabled in OpenNESS and gather data from them. Prometheus is enabled in the CEEK by default with the `telemetry/prometheus` role.
+In Smart Edge Open, Prometheus is deployed as a K8s Deployment with a single pod/replica on the Edge Controller node. It is configured out of the box to scrape all other telemetry endpoints/collectors enabled in Smart Edge Open and gather data from them. Prometheus is enabled in the CEEK by default with the `telemetry/prometheus` role.
 
 #### Usage
 
-1. To connect to a Prometheus dashboard, start a browser on the same network as the OpenNESS cluster and enter the address of the dashboard (where the IP address is the address of the Edge Controller)
+1. To connect to a Prometheus dashboard, start a browser on the same network as the Smart Edge Open cluster and enter the address of the dashboard (where the IP address is the address of the Edge Controller)
 
     ```shell
     From browser:
@@ -89,11 +89,11 @@ In OpenNESS, Prometheus is deployed as a K8s Deployment with a single pod/replic
 
 ### Grafana
 
-Grafana is an open-source visualization and analytics software. It takes the data provided from external sources and displays relevant data to the user via dashboards. It enables the user to create customized dashboards based on the information the user wants to monitor and allows for the provision of additional data sources. In OpenNESS, the Grafana pod is deployed on a control plane as a K8s `Deployment` type and is by default provisioned with data from Prometheus. It is enabled by default in CEEK and can be enabled/disabled by changing the `telemetry_grafana_enable` flag.
+Grafana is an open-source visualization and analytics software. It takes the data provided from external sources and displays relevant data to the user via dashboards. It enables the user to create customized dashboards based on the information the user wants to monitor and allows for the provision of additional data sources. In Smart Edge Open, the Grafana pod is deployed on a control plane as a K8s `Deployment` type and is by default provisioned with data from Prometheus. It is enabled by default in CEEK and can be enabled/disabled by changing the `telemetry_grafana_enable` flag.
 
 #### Usage
 
-1. To connect to the Grafana dashboard, start a browser on the same network as the OpenNESS cluster and enter the address of the dashboard (where the IP address is the address of the Edge Controller)
+1. To connect to the Grafana dashboard, start a browser on the same network as the Smart Edge Open cluster and enter the address of the dashboard (where the IP address is the address of the Edge Controller)
 
     ```shell
     From browser:
@@ -135,11 +135,11 @@ Grafana is an open-source visualization and analytics software. It takes the dat
 10. To save the dashboard, click save in the upper right corner.
    ![Grafana dash](telemetry-images/grafana-save.png)
 
-> OpenNESS will deploy Grafana with a  simple `Example dashboard`. You can use this dashboard to learn how to use Grafana and create your own dashboards.
+> Smart Edge Open will deploy Grafana with a  simple `Example dashboard`. You can use this dashboard to learn how to use Grafana and create your own dashboards.
 
 ### Node Exporter
 
-Node Exporter is a Prometheus exporter that exposes hardware and OS metrics of *NIX kernels. The metrics are gathered within the kernel and exposed on a web server so they can be scraped by Prometheus. In OpenNESS, the Node Exporter pod is deployed as a K8s `Daemonset`; it is a privileged pod that runs on every Edge Node in the cluster. It is enabled by default by CEEK.
+Node Exporter is a Prometheus exporter that exposes hardware and OS metrics of *NIX kernels. The metrics are gathered within the kernel and exposed on a web server so they can be scraped by Prometheus. In Smart Edge Open, the Node Exporter pod is deployed as a K8s `Daemonset`; it is a privileged pod that runs on every Edge Node in the cluster. It is enabled by default by CEEK.
 
 #### Usage
 
@@ -149,12 +149,12 @@ Node Exporter is a Prometheus exporter that exposes hardware and OS metrics of *
 
 #### VCAC-A
 
-Node Exporter also enables exposure of telemetry from Intel's VCAC-A card to Prometheus. The telemetry from the VCAC-A card is saved into a text file; this text file is used as an input to the Node Exporter. More information on VCAC-A usage in OpenNESS is available [here](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-vcac-a.md).
+Node Exporter also enables exposure of telemetry from Intel's VCAC-A card to Prometheus. The telemetry from the VCAC-A card is saved into a text file; this text file is used as an input to the Node Exporter. More information on VCAC-A usage in Smart Edge Open is available [here](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-vcac-a.md).
 
 ### cAdvisor
 
 The cAdvisor is a running daemon that provides information about containers running in the cluster.
-It collects and aggregates data about running containers such as resource usage, isolation parameters, and network statistics. Once the data is processed, it is exported. The data can be easily obtained by metrics monitoring tools such as Prometheus. In OpenNESS, cAdvisor is deployed as a K8s `daemonset` on every Edge Node and scraped by Prometheus.
+It collects and aggregates data about running containers such as resource usage, isolation parameters, and network statistics. Once the data is processed, it is exported. The data can be easily obtained by metrics monitoring tools such as Prometheus. In Smart Edge Open, cAdvisor is deployed as a K8s `daemonset` on every Edge Node and scraped by Prometheus.
 
 #### Usage
 
@@ -164,11 +164,11 @@ It collects and aggregates data about running containers such as resource usage,
 
 ### CollectD
 
-CollectD is a daemon/collector enabling the collection of hardware metrics from computers and network equipment. It provides support for CollectD plugins, which extends its functionality for specific metrics collection such as Intel® RDT, Intel PMU, and ovs-dpdk. The metrics collected are easily exposed to the Prometheus monitoring tool via the usage of the `write_prometheus` plugin. In OpenNESS, CollectD is supported with the help of the [OPNFV Barometer project](https://wiki.opnfv.org/display/fastpath/Barometer+Home) - using its Docker image and available plugins. As part of the OpenNESS release, a CollectD plugin for Intel® FPGA Programmable Acceleration Card (Intel® FPGA PAC) N3000 telemetry is now available from OpenNESS (power and temperature telemetry). In OpenNESS, the CollectD pod is deployed as a K8s `Daemonset` on every available Edge Node, and it is deployed as a privileged container.
+CollectD is a daemon/collector enabling the collection of hardware metrics from computers and network equipment. It provides support for CollectD plugins, which extends its functionality for specific metrics collection such as Intel® RDT, Intel PMU, and ovs-dpdk. The metrics collected are easily exposed to the Prometheus monitoring tool via the usage of the `write_prometheus` plugin. In Smart Edge Open, CollectD is supported with the help of the [OPNFV Barometer project](https://wiki.opnfv.org/display/fastpath/Barometer+Home) - using its Docker image and available plugins. As part of the Smart Edge Open release, a CollectD plugin for Intel® FPGA Programmable Acceleration Card (Intel® FPGA PAC) N3000 telemetry is now available from Smart Edge Open (power and temperature telemetry). In Smart Edge Open, the CollectD pod is deployed as a K8s `Daemonset` on every available Edge Node, and it is deployed as a privileged container.
 
 #### Plugins
 
-There are four distinct sets of plugins (flavors) enabled for CollectD deployment that can be used depending on the use-case/workload being deployed on OpenNESS. `Common` is the default flavor in OpenNESS. The flavors available are: `common`, `corenetwork`, `flexran`, and `smartcity`. Below is a table specifying which CollectD plugins are enabled for each flavor.
+There are four distinct sets of plugins (flavors) enabled for CollectD deployment that can be used depending on the use-case/workload being deployed on Smart Edge Open. `Common` is the default flavor in Smart Edge Open. The flavors available are: `common`, `corenetwork`, `flexran`, and `smartcity`. Below is a table specifying which CollectD plugins are enabled for each flavor.
 The various CEEK flavors are enabled for CollectD deployment as follows:
 
 
@@ -187,9 +187,9 @@ The various CEEK flavors are enabled for CollectD deployment as follows:
 
 #### Usage
 
-1. Select the flavor for the deployment of CollectD from the CEEK during OpenNESS deployment; the flavor is to be selected with `telemetry_flavor: <flavor name>`.
+1. Select the flavor for the deployment of CollectD from the CEEK during Smart Edge Open deployment; the flavor is to be selected with `telemetry_flavor: <flavor name>`.
 
-   In the event of using the `flexran` profile, `OPAE_SDK_1.3.7-5_el7.zip` needs to be available in `./converged-edge-experience-kits/opae_fpga` directory; for details about the packages, see [FPGA support in OpenNESS](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-fpga.md#edge-controller)
+   In the event of using the `flexran` profile, `OPAE_SDK_1.3.7-5_el7.zip` needs to be available in `./converged-edge-experience-kits/opae_fpga` directory; for details about the packages, see [FPGA support in Smart Edge Open](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-fpga.md#edge-controller)
 2. To access metrics available from CollectD, connect to the Prometheus [dashboard](#prometheus).
 3. Look up an example the CollectD metric by specifying the metric name (ie. `collectd_cpufreq`) and pressing `execute` under the `graph` tab.
    ![CollectD Metric](telemetry-images/collectd_metric.png)
@@ -198,13 +198,13 @@ The various CEEK flavors are enabled for CollectD deployment as follows:
 
 OpenTelemetry is a project providing APIs and libraries that enable the collection of telemetry from edge services and network functions. This project provides a mechanism to capture application metrics and traces within applications with support for multiple programming languages. The captured metrics are exposed to OpenTelemetry agents and collectors responsible for the handling of data and forwarding it to the desired back-end application(s) for processing and analysis. Among the supported back-ends are popular projects such as Prometheus (metrics), Jaeger, and Zipkin (traces). A concept of receiver and exporter exists within the Open Telemetry agent and collector. The receiver provides a mechanism to receive the data into the agent or collector. Multiple receivers are supported and at least one or more must be configured. On the opposite end, an exporter provides a mechanism to export data to the receiver, similarly multiple exporters are supported and one or more must be set up.
 
-As part of the OpenNESS release, only the support for collecting metrics and exposing them to Prometheus is enabled. The deployment model chosen for Open Telemetry is to deploy a global collector pod receiving data from multiple agents, the agents are to be deployed as side-car containers for each instance of the application pod.
+As part of the Smart Edge Open release, only the support for collecting metrics and exposing them to Prometheus is enabled. The deployment model chosen for Open Telemetry is to deploy a global collector pod receiving data from multiple agents, the agents are to be deployed as side-car containers for each instance of the application pod.
 
 -	The application exports data to the agent locally.
 -	The agent receives the data and exports it to the collector by specifying the collector’s K8s service name and port via TLS secured connection.
 -	The collector exposes all the available data received from multiple agents on an endpoint which is being scraped by Prometheus.
 
-OpenCensus exporter/receiver is used in the default OpenNESS configuration for agent and collector to collect metrics from an application. A sample application pod generating random numbers, aggregating those numbers and exposing the metrics, and containing a reference side-car OpenTelemetry agent is available in the Edge Apps repository.
+OpenCensus exporter/receiver is used in the default Smart Edge Open configuration for agent and collector to collect metrics from an application. A sample application pod generating random numbers, aggregating those numbers and exposing the metrics, and containing a reference side-car OpenTelemetry agent is available in the Edge Apps repository.
 
 #### Usage
 
@@ -245,9 +245,9 @@ OpenCensus exporter/receiver is used in the default OpenNESS configuration for a
 
 ### PCM
 
-Processor Counter Monitor (PCM) is an application programming interface (API) and a set of tools based on the API to monitor performance and energy metrics of Intel® Core™, Xeon®, Atom™ and Xeon Phi™ processors. In OpenNESS, the PCM pod is deployed as a K8s `Daemonset` on every available node. PCM metrics are exposed to Prometheus via the Host's NodePort on each EdgeNode. 
->**NOTE**: The PCM feature is intended to run on physical hardware (i.e., no support for VM virtualized Edge Nodes in OpenNESS). Therefore, this feature is disabled by default. The feature can be enabled by setting the `telemetry_pcm_enable` flag in CEEK. Additionally, a preset dashboard is created for PCM in Grafana visualizing the most crucial metrics.
->**NOTE**: There is currently a limitation in OpenNESS where a conflict between deployment of CollectD and PCM prevents PCM server from starting successfully, it is advised to run PCM with CollectD disabled at this time.
+Processor Counter Monitor (PCM) is an application programming interface (API) and a set of tools based on the API to monitor performance and energy metrics of Intel® Core™, Xeon®, Atom™ and Xeon Phi™ processors. In Smart Edge Open, the PCM pod is deployed as a K8s `Daemonset` on every available node. PCM metrics are exposed to Prometheus via the Host's NodePort on each EdgeNode. 
+>**NOTE**: The PCM feature is intended to run on physical hardware (i.e., no support for VM virtualized Edge Nodes in Smart Edge Open). Therefore, this feature is disabled by default. The feature can be enabled by setting the `telemetry_pcm_enable` flag in CEEK. Additionally, a preset dashboard is created for PCM in Grafana visualizing the most crucial metrics.
+>**NOTE**: There is currently a limitation in Smart Edge Open where a conflict between deployment of CollectD and PCM prevents PCM server from starting successfully, it is advised to run PCM with CollectD disabled at this time.
 
 #### Usage
 
@@ -262,11 +262,11 @@ Processor Counter Monitor (PCM) is an application programming interface (API) an
 
 ### TAS
 
-[Telemetry Aware Scheduler](https://github.com/intel/telemetry-aware-scheduling) enables the user to make K8s scheduling decisions based on the metrics available from telemetry. This is crucial for a variety of Edge use-cases and workloads where it is critical that the workloads are balanced and deployed on the best suitable node based on hardware ability and performance. The user can create a set of policies defining the rules to which pod placement must adhere. Functionality to de-schedule pods from given nodes if a rule is violated is also provided. TAS consists of a TAS Extender which is an extension to the K8s scheduler. It correlates the scheduling policies with deployment strategies and returns decisions to the K8s Scheduler. It also consists of a TAS Controller that consumes TAS policies and makes them locally available to TAS components. A metrics pipeline that exposes metrics to a K8s API must be established for TAS to be able to read in the metrics. In OpenNESS, the metrics pipeline consists of:
+[Telemetry Aware Scheduler](https://github.com/intel/telemetry-aware-scheduling) enables the user to make K8s scheduling decisions based on the metrics available from telemetry. This is crucial for a variety of Edge use-cases and workloads where it is critical that the workloads are balanced and deployed on the best suitable node based on hardware ability and performance. The user can create a set of policies defining the rules to which pod placement must adhere. Functionality to de-schedule pods from given nodes if a rule is violated is also provided. TAS consists of a TAS Extender which is an extension to the K8s scheduler. It correlates the scheduling policies with deployment strategies and returns decisions to the K8s Scheduler. It also consists of a TAS Controller that consumes TAS policies and makes them locally available to TAS components. A metrics pipeline that exposes metrics to a K8s API must be established for TAS to be able to read in the metrics. In Smart Edge Open, the metrics pipeline consists of:
 
 - Prometheus: responsible for collecting and providing metrics.
 - Prometheus Adapter: exposes the metrics from Prometheus to a K8s API and is configured to provide metrics from Node Exporter and CollectD collectors.
-TAS is enabled by default in CEEK, a sample scheduling policy for TAS is provided for [VCAC-A node deployment](https://github.com/open-ness/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/openness-vcac-a.md#telemetry-support).
+TAS is enabled by default in CEEK, a sample scheduling policy for TAS is provided for [VCAC-A node deployment](https://github.com/smart-edge-open/specs/blob/master/doc/building-blocks/enhanced-platform-awareness/smartedge-open-vcac-a.md#telemetry-support).
 
 #### Usage
 
@@ -354,7 +354,7 @@ TAS is enabled by default in CEEK, a sample scheduling policy for TAS is provide
 
 ## Summary
 
-The OpenNESS platform provides a comprehensive set of features and components that enable users to collect, monitor, and visualize a variety of platform metrics with a strong focus on telemetry from Intel® architecture (hardware such as CPU, VCAC-A, and FPGA).
+The Smart Edge Open platform provides a comprehensive set of features and components that enable users to collect, monitor, and visualize a variety of platform metrics with a strong focus on telemetry from Intel® architecture (hardware such as CPU, VCAC-A, and FPGA).
 It also provides the means to make intelligent scheduling decisions for performance-sensitive Edge workloads based on the performance and abilities of the hardware.
 The support for collecting and visualizing metrics from within applications is also provided.
 
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-topology-manager.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-topology-manager.md
similarity index 92%
rename from doc/building-blocks/enhanced-platform-awareness/openness-topology-manager.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-topology-manager.md
index fdb5aef5..3a2eaa10 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-topology-manager.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-topology-manager.md
@@ -3,13 +3,13 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019 Intel Corporation
 ```
 <!-- omit in toc -->
-# Resource Locality Awareness Support Through Topology Manager in OpenNESS
+# Resource Locality Awareness Support Through Topology Manager in Smart Edge Open
 - [Overview](#overview)
   - [Edge use case](#edge-use-case)
-- [Details - Topology manager support in OpenNESS](#details---topology-manager-support-in-openness)
+- [Details - Topology manager support in Smart Edge Open](#details---topology-manager-support-in-smart-edge-open)
   - [Usage](#usage)
-- [OpenNESS NUMA and DPDK Cheat Sheet](#OpenNESS-NUMA-and-DPDK-Cheat-Sheet)
-  - [DPDK in OpenNESS](#DPDK-in-OpenNESS)
+- [Smart Edge Open NUMA and DPDK Cheat Sheet](#Smart Edge Open-NUMA-and-DPDK-Cheat-Sheet)
+  - [DPDK in Smart Edge Open](#DPDK-in-Smart Edge Open)
   - [What is NUMA and Why You Care](#What-is-NUMA-and-Why-You-Care)
   - [Determine NIC NUMA placement](#Determine-NIC-NUMA-placement)
   - [CPU Mask Calculations](#CPU-Mask-Calculations)
@@ -22,7 +22,7 @@ Copyright (c) 2019 Intel Corporation
 
 Multi-core and Multi-Socket commercial, off-the-shelf (COTS) systems are widely used for the deployment of application and network functions. COTS systems provide a variety of IO and memory features. In order to achieve determinism and high performance, mechanisms like CPU isolation, IO device locality, and socket memory allocation are critical. Cloud-native stacks such as Kubernetes\* are beginning to leverage resources such as CPU, hugepages, and I/O, but are agnostic to the Non-Uniform Memory Access (NUMA) alignment of these. Non-optimal, topology-aware NUMA resource allocation can severely impact the performance of latency-sensitive workloads.
 
-To address this requirement, OpenNESS uses the Topology manager. The topology manager is now supported by Kubernetes. Topology Manager is a solution that permits k8s components (e.g., CPU Manager and Device Manager) to coordinate the resources allocated to a workload.
+To address this requirement, Smart Edge Open uses the Topology manager. The topology manager is now supported by Kubernetes. Topology Manager is a solution that permits k8s components (e.g., CPU Manager and Device Manager) to coordinate the resources allocated to a workload.
 
 ### Edge use case
 
@@ -38,9 +38,9 @@ _Figure - Pod deployment with Topology Manager_
 
 Topology Manager is a Kubelet component that aims to co-ordinate the set of components that are responsible for these optimizations.
 
-## Details - Topology manager support in OpenNESS
+## Details - Topology manager support in Smart Edge Open
 
-Topology Manager is enabled by default with a `best-effort` policy. You can change the settings before OpenNESS installation by editing the `inventory/default/group_vars/all/10-default.yml` file:
+Topology Manager is enabled by default with a `best-effort` policy. You can change the settings before Smart Edge Open installation by editing the `inventory/default/group_vars/all/10-default.yml` file:
 
 ```yaml
 ### Kubernetes Topology Manager configuration (for a node)
@@ -94,18 +94,18 @@ Nov 05 09:22:52 tmanager kubelet[64340]: I1105 09:22:52.550216   64340 topology_
 
 ```
 
-# OpenNESS NUMA and DPDK Cheat Sheet
+# Smart Edge Open NUMA and DPDK Cheat Sheet
 
-_Disclaimer: this document is not intended to serve as a comprehensive guide to DPDK, optimizing DPDK deployments, or as a replacement for the extensive DPDK documentation.  This guide is intended as a supplement to the OpenNESS/CERA experience kits in order to adapt them to a platform that is different than those used in the OpenNESS development and validation labs._
+_Disclaimer: this document is not intended to serve as a comprehensive guide to DPDK, optimizing DPDK deployments, or as a replacement for the extensive DPDK documentation.  This guide is intended as a supplement to the Smart Edge Open/Smart Edge Open Experience Kit experience kits in order to adapt them to a platform that is different than those used in the Smart Edge Open development and validation labs._
 
 _The examples in this document are taken from a DELL R740 server, which happens to enumerate CPUs very differently than the Intel WolfPass S2600WFQ reference platform commonly utilized within Intel labs._
 
 [TOC]
 
 
-# DPDK in OpenNESS
+# DPDK in Smart Edge Open
 
-When the OpenNESS is deployed with the KubeOVN CNI we include the DPDK optimizations, this is managed through the _flavor_ group_vars via the flag:
+When the Smart Edge Open is deployed with the KubeOVN CNI we include the DPDK optimizations, this is managed through the _flavor_ group_vars via the flag:
 
 ```bash
 kubeovn_dpdk: true
@@ -134,7 +134,7 @@ So in summary, each physical CPU core has memory that is _more_ local than other
 
 Intel publishes various resources for [optimizing applications for NUMA](https://software.intel.com/content/www/us/en/develop/articles/optimizing-applications-for-numa.html) including a guide on assessing the effect of NUMA using [Intel® VTune™ Amplifier](https://software.intel.com/content/www/us/en/develop/videos/how-numa-affects-your-workloads-intel-vtune-amplifier.html).
 
-Within OpenNESS we implement [CPU management extensions](https://www.openness.org/docs/doc/building-blocks/enhanced-platform-awareness/openness-dedicated-core#details---cpu-manager-support-in-openness) to Kubernetes to allow scheduling workloads with NUMA awareness. In the context of DPDK, we bind the descriptors for dataplane to the NUMA node of the network interface(s).
+Within Smart Edge Open we implement [CPU management extensions](https://www.openness.org/docs/doc/building-blocks/enhanced-platform-awareness/openness-dedicated-core#details---cpu-manager-support-in-openness) to Kubernetes to allow scheduling workloads with NUMA awareness. In the context of DPDK, we bind the descriptors for dataplane to the NUMA node of the network interface(s).
 
 ## Determine NIC NUMA placement
 
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness-vcac-a.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-vcac-a.md
similarity index 76%
rename from doc/building-blocks/enhanced-platform-awareness/openness-vcac-a.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open-vcac-a.md
index 9b4be173..30c25855 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness-vcac-a.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open-vcac-a.md
@@ -3,7 +3,7 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2020-2021 Intel Corporation
 ```
 <!-- omit in toc -->
-# Using Visual Compute Accelerator Card - Analytics (VCAC-A) in OpenNESS
+# Using Visual Compute Accelerator Card - Analytics (VCAC-A) in Smart Edge Open
 - [Overview](#overview)
 - [Architecture](#architecture)
   - [VCA Zone](#vca-zone)
@@ -23,23 +23,23 @@ Equipped with a CPU, the VCAC-A card is installed with a standalone operating sy
 
 > **Terminology** 
 > * *Edge node* and *VCA host* are used interchangeably throughout this document to represent the physical node where the VCAC-A cards are connected to.
-> * *VCA node* represents the  node in the OpenNESS cluster. The VCAC-A card is the incarnation of the VCA node.
+> * *VCA node* represents the  node in the Smart Edge Open cluster. The VCAC-A card is the incarnation of the VCA node.
 > * The full acronym *VCAC-A* is loosely used when talking about the PCIe card.
 
 The VCAC-A installation involves a [two-stage build](https://github.com/OpenVisualCloud/VCAC-SW-Analytics/):
 1. VCA host kernel build and configuration: this stage patches the CentOS\* 7.9 kernel and builds the necessary modules and dependencies.
 2. VCAC-A system image (VCAD) generation: this stage builds an Ubuntu\*-based (VCAD) image that is loaded on the VCAC-A card.
 
-The CEEK automates the overall build and installation process of the VCAC-A card by joining it as a standalone logical node to the OpenNESS cluster. The CEEK supports force build VCAC-A system image (VCAD) via flag (force\_build\_enable: true (default value)), it also allows the customer to disable the flag to re-use last system image built. When successful, the OpenNESS controller is capable of selectively scheduling workloads on the "VCA node" for proximity to the hardware acceleration.
+The CEEK automates the overall build and installation process of the VCAC-A card by joining it as a standalone logical node to the Smart Edge Open cluster. The CEEK supports force build VCAC-A system image (VCAD) via flag (force\_build\_enable: true (default value)), it also allows the customer to disable the flag to re-use last system image built. When successful, the Smart Edge Open controller is capable of selectively scheduling workloads on the "VCA node" for proximity to the hardware acceleration.
 
-When onboarding applications such as [Open Visual Cloud Smart City Sample](https://github.com/open-ness/edgeapps/tree/master/applications/smart-city-app) with the existence of VCAC-A, the OpenNESS controller schedules all the application pods onto the edge node except the *video analytics* processing that is scheduled on the VCA node as shown in the figure below.
+When onboarding applications such as [Open Visual Cloud Smart City Sample](https://github.com/smart-edge-open/edgeapps/tree/master/applications/smart-city-app) with the existence of VCAC-A, the Smart Edge Open controller schedules all the application pods onto the edge node except the *video analytics* processing that is scheduled on the VCA node as shown in the figure below.
 
 ![Smart City Setup](vcaca-images/smart-city-app-vcac-a.png)
 
-_Figure - VCAC-A accelerating Smart City Application with OpenNESS_
+_Figure - VCAC-A accelerating Smart City Application with Smart Edge Open_
 
 ### VCA Zone
-During the VCAC-A installation, the VCA nodes are labeled with `vcac-zone=yes`. Therefore, to direct the OpenNESS controller to schedule particular workloads on the VCA node, the `nodeAffinity` field should be used in its Pod specs as shown below:
+During the VCAC-A installation, the VCA nodes are labeled with `vcac-zone=yes`. Therefore, to direct the Smart Edge Open controller to schedule particular workloads on the VCA node, the `nodeAffinity` field should be used in its Pod specs as shown below:
 
 ```yaml
 ...
@@ -55,7 +55,7 @@ affinity:
 ```
 
 ### VCA Pools
-Another construct used when deploying OpenNESS is the `VCA pool`, which is a similar concept to the *Node pools* that are supported by [Azure\* Kubernetes\* Service](https://docs.microsoft.com/en-us/azure/aks/use-multiple-node-pools) and [Google\* Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/concepts/node-pools). The VCA pool is a unique label assigned to the group of VCA nodes that are plugged into one node. This enables the scheduler to execute related workloads within the same VCA pool (i.e., within the same edge node physical space). The VCA pool is assigned the label `vcac-pool=<vca-host-name>`, which reflects the hostname of the VCA host that all the VCAC-A cards are connected to.
+Another construct used when deploying Smart Edge Open is the `VCA pool`, which is a similar concept to the *Node pools* that are supported by [Azure\* Kubernetes\* Service](https://docs.microsoft.com/en-us/azure/aks/use-multiple-node-pools) and [Google\* Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/concepts/node-pools). The VCA pool is a unique label assigned to the group of VCA nodes that are plugged into one node. This enables the scheduler to execute related workloads within the same VCA pool (i.e., within the same edge node physical space). The VCA pool is assigned the label `vcac-pool=<vca-host-name>`, which reflects the hostname of the VCA host that all the VCAC-A cards are connected to.
 
 Also, the VCA nodes follow a special naming convention. They are assigned the name of their host nodes appended with *vca* keyword and a number (`<vca-host-name>-vcaX`). The number is an incremental index to differentiate between multiple VCAC-A cards that are installed.
 
@@ -96,7 +96,7 @@ $ kubectl get no -o json | jq '.items[].metadata.labels'
 ## VPU, GPU Device Plugins, and HDDL Daemonset
 Kubernetes provides the [Device Plugins framework](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) that is used to advertise system hardware resources. The device plugins of interest for VCAC-A are: [VPU](https://github.com/intel/intel-device-plugins-for-kubernetes/blob/master/cmd/vpu_plugin/README.md) and [GPU](https://github.com/intel/intel-device-plugins-for-kubernetes/blob/master/cmd/gpu_plugin/README.md). They are installed as part of the VCAC-A install sequence that is performed by the CEEK.
 
-Another ingredient involved in the inference execution through VCAC-A VPUs is the *HDDL-daemon* that is deployed as a [Kubernetes Daemonset](https://github.com/OpenVisualCloud/Dockerfiles/blob/master/VCAC-A/script/setup_hddl_daemonset.yaml). It acts as an arbiter for the various applications/Pods trying to gain access to VPU resources. Therefore, the OpenNESS cluster is ready for onboarding applications and availing of VCAC-A acceleration without worrying about other dependencies.
+Another ingredient involved in the inference execution through VCAC-A VPUs is the *HDDL-daemon* that is deployed as a [Kubernetes Daemonset](https://github.com/OpenVisualCloud/Dockerfiles/blob/master/VCAC-A/script/setup_hddl_daemonset.yaml). It acts as an arbiter for the various applications/Pods trying to gain access to VPU resources. Therefore, the Smart Edge Open cluster is ready for onboarding applications and availing of VCAC-A acceleration without worrying about other dependencies.
 
 ```shell
 $ kubectl get daemonsets -A
@@ -106,10 +106,10 @@ default       intel-vpu-plugin   1         1         1       1            1
 kube-system   intel-vpu-hddl     1         1         1       1            1           vcac-zone=yes   31h
 ...
 ```
-> VPU and GPU device plugins as well as HDDL Daemonset are deployed in the OpenNESS cluster as part of the VCAC-A installation sequence that is performed by the CEEK.
+> VPU and GPU device plugins as well as HDDL Daemonset are deployed in the Smart Edge Open cluster as part of the VCAC-A installation sequence that is performed by the CEEK.
 
 ## Telemetry Support
-VCAC-A telemetry is an integral part of the OpenNESS telemetry suite that enables the Kubernetes scheduler to perform telemetry-aware scheduling decisions. The following metrics are exported:
+VCAC-A telemetry is an integral part of the Smart Edge Open telemetry suite that enables the Kubernetes scheduler to perform telemetry-aware scheduling decisions. The following metrics are exported:
 1. VPU device memory – the least memory usage among all the VPUs
 2. VPU device thermal – the highest among all the VPUs
 3. VPU device utilization – the average utilization of all the VPUs
@@ -120,9 +120,9 @@ $ /opt/intel/vcaa/vpu_metric/run.sh start
 ```
 > The VPU metrics exporter script is executed as part of the VCAC-A install sequence that is performed by the CEEK.
 
-![Exporting VCAC-A VPU Metrics to OpenNESS Telemetry](vcaca-images/vcac-a-vpu-metrics.png)
+![Exporting VCAC-A VPU Metrics to Smart Edge Open Telemetry](vcaca-images/vcac-a-vpu-metrics.png)
 
-_Figure - Exporting VCAC-A VPU Metrics to OpenNESS Telemetry_
+_Figure - Exporting VCAC-A VPU Metrics to Smart Edge Open Telemetry_
 
 Telemetry-Aware Scheduling (TAS) is the mechanism of defining policies that the controller aims to fulfill at run-time (based on the collected real-time metrics). A sample VCAC-A VPU telemetry policy is given below that is applied by default as part of the install sequence performed by the CEEK.
 
@@ -154,19 +154,19 @@ spec:
 ```
 > The above telemetry policy is applied by default as part of the VCAC-A install sequence performed by CEEK.
 
-The diagram below demonstrates an example use of the VCAC-A telemetry within the OpenNESS context:
+The diagram below demonstrates an example use of the VCAC-A telemetry within the Smart Edge Open context:
 
-![Using VCAC-A Telemetry with OpenNESS](vcaca-images/using-vcac-a-telemetry.png)
+![Using VCAC-A Telemetry with Smart Edge Open](vcaca-images/using-vcac-a-telemetry.png)
 
-_Figure - Using VCAC-A Telemetry with OpenNESS_
+_Figure - Using VCAC-A Telemetry with Smart Edge Open_
 
-1. The default VCAC-A VPU telemetry policy `TASPolicy` is defined and applied to the OpenNESS cluster at deployment time.
+1. The default VCAC-A VPU telemetry policy `TASPolicy` is defined and applied to the Smart Edge Open cluster at deployment time.
 2. `GStreamer pipeline` Pods get scheduled on VCA node (VCA pool A in the given example) based on the reported metrics.
 3. `Media Analytics Applications` get scheduled on VCA pool A according to their Pod specs and can consume the services produced by the `GStreamer pipeline` Pods.
 4. Now that the VPU device usage became 60, when the `OpenVINO` application turns up, it gets scheduled on VCA pool B in fulfillment of the policy.
 
 ## Media-Analytics-VCA Flavor
-The pre-defined OpenNESS flavor *media-analytics-vca* is provided to provision an optimized system configuration for media analytics workloads leveraging VCAC-A acceleration. This flavor is applied through the CEEK playbook as described in the [OpenNESS Flavors](../flavors.md#media-analytics-flavor-with-vcac-a) document and encompasses the VCAC-A installation.
+The pre-defined Smart Edge Open flavor *media-analytics-vca* is provided to provision an optimized system configuration for media analytics workloads leveraging VCAC-A acceleration. This flavor is applied through the CEEK playbook as described in the [Smart Edge Open Flavors](../flavors.md#media-analytics-flavor-with-vcac-a) document and encompasses the VCAC-A installation.
 
 The VCAC-A installation in CEEK performs the following tasks:
 - Pull the release package from [Open Visual Cloud VCAC-A card media analytics software](https://github.com/OpenVisualCloud/VCAC-SW-Analytics) and the required dependencies
@@ -174,7 +174,7 @@ The VCAC-A installation in CEEK performs the following tasks:
 - Apply module patches and build driver RPM
 - Build daemon utilities RPM
 - Install docker-ce and kubernetes on the VCA host
-- Join the VCA host to the OpenNESS cluster
+- Join the VCA host to the Smart Edge Open cluster
 - Pull Ubuntu docker image for building the VCAC-A system image
 - Download the required package from the website for the VCAC-A system image
 - Apply Ubuntu 18.04 kernel patches and build kernel deb for the VCAC-A system image
@@ -184,7 +184,7 @@ The VCAC-A installation in CEEK performs the following tasks:
 - Boot up the VCAC-A system image
 - Configure the firewall to allow VCAC-A NATting
 - Install docker-ce and kubernetes on the VCA node
-- Join the VCA node to the OpenNESS cluster
+- Join the VCA node to the Smart Edge Open cluster
 - Attach VCA NFD to kubernetes
 - Deploy VPU and GPU device plugins as well as HDDL Daemonset
 - Start VPU metrics exporter
diff --git a/doc/building-blocks/enhanced-platform-awareness/openness_hddl.md b/doc/building-blocks/enhanced-platform-awareness/smartedge-open_hddl.md
similarity index 70%
rename from doc/building-blocks/enhanced-platform-awareness/openness_hddl.md
rename to doc/building-blocks/enhanced-platform-awareness/smartedge-open_hddl.md
index ca16d0d5..4f42c9dd 100644
--- a/doc/building-blocks/enhanced-platform-awareness/openness_hddl.md
+++ b/doc/building-blocks/enhanced-platform-awareness/smartedge-open_hddl.md
@@ -3,10 +3,10 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019 Intel Corporation
 ```
 <!-- omit in toc -->
-# Using Intel® Movidius™ Myriad™ X High Density Deep Learning (HDDL) solution in OpenNESS
+# Using Intel® Movidius™ Myriad™ X High Density Deep Learning (HDDL) solution in Smart Edge Open
 - [Overview](#overview)
 - [HDDL Introduction](#hddl-introduction)
-- [HDDL OpenNESS Integration](#hddl-openness-integration)
+- [HDDL Smart Edge Open Integration](#hddl-smart-edge-open-integration)
 - [Summary](#summary)
 - [Reference](#reference)
 
@@ -16,7 +16,7 @@ The deployment of AI-based, machine-learning (ML) applications on the edge have
 ## HDDL Introduction
 Intel® Movidius™ Myriad™ X High Density Deep Learning (HDDL) solution integrates multiple Intel® Movidius™ Myriad™ X brand SoCs in a PCIe add-in card form factor or a module form factor to build a scalable, high-capacity, deep-learning solution. It provides hardware and software reference for customers. The following figure shows the HDDL-R concept.
 
-![HDDL-R Add-in Card](hddl-images/openness_HDDL.png)
+![HDDL-R Add-in Card](hddl-images/smartedge-open_HDDL.png)
 
 - <b>HDDL-R</b>: Raw video data to the PCIe card (decode on the host).
 - <b>Scalability</b>: Options available to put between 4 to 8 Intel® Movidius™ Myriad™ X brand SoC chips in one add-in-card.
@@ -26,26 +26,26 @@ The HDDL SW stack adopts OpenVINO™ brand IE APIs. These universal deep-learnin
 Each implementation for each hardware is an inference engine plugin.
 The plugin for the Intel® Movidius™ Myriad™ X HDDL solution, or IE HDDL plugin for short, supports the Intel® Movidius™ Myriad™ X HDDL Solution hardware PCIe card. It communicates with the Intel® Movidius™ Myriad™ X HDDL HAL API to manage multiple Intel® Movidius™ Myriad™ X devices in the card, and it schedules deep-learning neural networks and inference tasks to these devices.
 
-## HDDL OpenNESS Integration
-OpenNESS provides support for the deployment of OpenVINO™ applications and workloads accelerated through Intel® Vision Accelerator Design with the Intel® Movidius™ VPU HDDL-R add-in card. As a prerequisite for enabling the support, it is required for the HDDL add-in card to be inserted into the PCI slot of the Edge Node platform. The support is then enabled by setting the appropriate flag - 'ne_hddl_enable' in the 'inventory/default/group_vars/all/10-default.yml' before running CEEK playbooks.
+## HDDL Smart Edge Open Integration
+Smart Edge Open provides support for the deployment of OpenVINO™ applications and workloads accelerated through Intel® Vision Accelerator Design with the Intel® Movidius™ VPU HDDL-R add-in card. As a prerequisite for enabling the support, it is required for the HDDL add-in card to be inserted into the PCI slot of the Edge Node platform. The support is then enabled by setting the appropriate flag - 'ne_hddl_enable' in the 'inventory/default/group_vars/all/10-default.yml' before running CEEK playbooks.
 > **NOTE** No pre-defined flavor is provided for HDDL. If user wants to enable HDDL with flavor, can set flag - 'ne_hddl_enable' in the 'flavors/<flavor-name>/all.yml'. The node with HDDL card inserted will be labelled as 'hddl-zone=true'.
 
 The CEEK automation script for HDDL will involve the following steps:
-- Download the HDDL DaemonSet yaml file from [Open Visual Cloud dockerfiles software](https://github.com/OpenVisualCloud/Dockerfiles) and templates it with specific configuration to satifiy OpenNESS need such as OpenVINO version...etc.
+- Download the HDDL DaemonSet yaml file from [Open Visual Cloud dockerfiles software](https://github.com/OpenVisualCloud/Dockerfiles) and templates it with specific configuration to satifiy Smart Edge Open need such as OpenVINO version...etc.
 - Download the OpenVINO™, install kernel-devel and then install HDDL dependencies.
 - Build the HDDLDdaemon image.
 - Label the node with 'hddl-zone=true'.
 - HDDL Daemon automatically brings up on the node with label 'hddl-zone=true'.
 
 The HDDL Daemon provides the backend service to manage VPUs and dispatch inference tasks to VPUs. OpenVINO™-based applications that utilizes HDDL hardware need to access the device node '/dev/ion' and domain socket under '/var/tmp' to communicate with the kernel and HDDL service.
-> **NOTE** With the default kernel used by OpenNESS CEEK, the ion driver will not enabled by OpenVINO™ toolkits, and the shared memory - '/dev/shm' will be used as fallback.  More details refer to [installing_openvino_docker_linux](https://docs.openvinotoolkit.org/2020.2/_docs_install_guides_installing_openvino_docker_linux.html) 
+> **NOTE** With the default kernel used by Smart Edge Open CEEK, the ion driver will not enabled by OpenVINO™ toolkits, and the shared memory - '/dev/shm' will be used as fallback.  More details refer to [installing_openvino_docker_linux](https://docs.openvinotoolkit.org/2020.2/_docs_install_guides_installing_openvino_docker_linux.html) 
 
 
 ![HDDL-Block-Diagram](hddl-images/hddlservice.png)
 
 
 ## Summary
-The Intel® Movidius™ Myriad™ X HDDL solution integrates multiple Intel® Movidius™ Myriad™ X brand SoCs in a PCIe add-in card form factor or a module form factor to build a scalable, high-capacity, deep-learning solution. OpenNESS provides a toolkit for customers to put together deep-learning solutions at the edge. To take it further for efficient resource usage, OpenNESS provides a mechanism to use CPU or VPU depending on the load or any other criteria.
+The Intel® Movidius™ Myriad™ X HDDL solution integrates multiple Intel® Movidius™ Myriad™ X brand SoCs in a PCIe add-in card form factor or a module form factor to build a scalable, high-capacity, deep-learning solution. Smart Edge Open provides a toolkit for customers to put together deep-learning solutions at the edge. To take it further for efficient resource usage, Smart Edge Open provides a mechanism to use CPU or VPU depending on the load or any other criteria.
 
 ## Reference
 - [HDDL-R: Mouser Mustang-V100](https://www.mouser.ie/datasheet/2/763/Mustang-V100_brochure-1526472.pdf)
diff --git a/doc/building-blocks/index.html b/doc/building-blocks/index.html
index 4acbbda9..34a0567d 100644
--- a/doc/building-blocks/index.html
+++ b/doc/building-blocks/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
 window.location = "dataplane"
 </script>
diff --git a/doc/cloud-adapters/awsgg-images/openness_cloudadapter.png b/doc/cloud-adapters/awsgg-images/smartedge-open_cloudadapter.png
similarity index 100%
rename from doc/cloud-adapters/awsgg-images/openness_cloudadapter.png
rename to doc/cloud-adapters/awsgg-images/smartedge-open_cloudadapter.png
diff --git a/doc/cloud-adapters/awsgg-images/openness_overview.png b/doc/cloud-adapters/awsgg-images/smartedge-open_overview.png
similarity index 100%
rename from doc/cloud-adapters/awsgg-images/openness_overview.png
rename to doc/cloud-adapters/awsgg-images/smartedge-open_overview.png
diff --git a/doc/cloud-adapters/baidu-cloudadapter-images/openness_baiduedge_end2end_demosetup.png b/doc/cloud-adapters/baidu-cloudadapter-images/smartedge-open_baiduedge_end2end_demosetup.png
similarity index 100%
rename from doc/cloud-adapters/baidu-cloudadapter-images/openness_baiduedge_end2end_demosetup.png
rename to doc/cloud-adapters/baidu-cloudadapter-images/smartedge-open_baiduedge_end2end_demosetup.png
diff --git a/doc/cloud-adapters/baidu-cloudadapter-images/openness_baiduedge_integration_arch.png b/doc/cloud-adapters/baidu-cloudadapter-images/smartedge-open_baiduedge_integration_arch.png
similarity index 100%
rename from doc/cloud-adapters/baidu-cloudadapter-images/openness_baiduedge_integration_arch.png
rename to doc/cloud-adapters/baidu-cloudadapter-images/smartedge-open_baiduedge_integration_arch.png
diff --git a/doc/cloud-adapters/index.html b/doc/cloud-adapters/index.html
index 4f4e65b2..b659d99a 100644
--- a/doc/cloud-adapters/index.html
+++ b/doc/cloud-adapters/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
-window.location = "openness_awsgreengrass"
+window.location = "smartedge-open_awsgreengrass"
 </script>
diff --git a/doc/cloud-adapters/openness_awsgreengrass.md b/doc/cloud-adapters/smartedge-open_awsgreengrass.md
similarity index 62%
rename from doc/cloud-adapters/openness_awsgreengrass.md
rename to doc/cloud-adapters/smartedge-open_awsgreengrass.md
index a41a6380..4363b79c 100644
--- a/doc/cloud-adapters/openness_awsgreengrass.md
+++ b/doc/cloud-adapters/smartedge-open_awsgreengrass.md
@@ -3,9 +3,9 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019 Intel Corporation
 ```
 <!-- omit in toc -->
-# OpenNESS Integration with AWS Greengrass
+# Smart Edge Open Integration with AWS Greengrass
 - [Overview](#overview)
-- [Run Greengrass on OpenNESS](#run-greengrass-on-openness)
+- [Run Greengrass on Smart Edge Open](#run-greengrass-on-smart-edge-open)
   - [Running AWS IoT Greengrass in a Docker Container](#running-aws-iot-greengrass-in-a-docker-container)
     - [Download Dockerfile from AWS](#download-dockerfile-from-aws)
     - [AWS IoT Greengrass](#aws-iot-greengrass)
@@ -16,33 +16,33 @@ Copyright (c) 2019 Intel Corporation
 ## Overview
 This application note will provide guidelines and examples on:
 - Creating an AWS Greengrass\* Docker\* container
-- Deploying an AWS Greengrass on the OpenNESS platform.
+- Deploying an AWS Greengrass on the Smart Edge Open platform.
 
-OpenNESS is an open-source software platform that enables easy orchestration of edge services across diverse network platforms and access technologies in multi-cloud environments. It is inspired by the edge computing architecture defined by the ETSI Multi-access Edge Computing (MEC) standards (e.g., [ETSI_MEC 003]), as well as the 5G network architecture ([3GPP_23501]). Figure 1 depicts the high-level architecture of OpenNESS.
+Smart Edge Open is an open-source software platform that enables easy orchestration of edge services across diverse network platforms and access technologies in multi-cloud environments. It is inspired by the edge computing architecture defined by the ETSI Multi-access Edge Computing (MEC) standards (e.g., [ETSI_MEC 003]), as well as the 5G network architecture ([3GPP_23501]). Figure 1 depicts the high-level architecture of Smart Edge Open.
 
 Certain commercial cloud service providers (CSPs), such as Amazon\*, have the capability of running cloud applications on edge platforms external to their cloud. In the case of AWS, this capability is provided by the Greengrass product. In Greengrass, a cloud connector component called Greengrass Core is ported to the edge platform and interoperates with the AWS cloud to allow the cloud to deploy and provision cloud applications on the edge platform.
 
-The OpenNESS platform supports Amazon Greengrass. This application note describes how to deploy Greengrass on the OpenNESS platform.
+The Smart Edge Open platform supports Amazon Greengrass. This application note describes how to deploy Greengrass on the Smart Edge Open platform.
 
-![OpenNESS Architecture overview](awsgg-images/openness_overview.png)
+![Smart Edge Open Architecture overview](awsgg-images/smartedge-open_overview.png)
 
-Figure 1 - OpenNESS Architecture
-## Run Greengrass on OpenNESS
+Figure 1 - Smart Edge Open Architecture
+## Run Greengrass on Smart Edge Open
 
-Figure 2 shows a system consisting of AWS, AWS Greengrass, and an OpenNESS platform. In this architecture, the Greengrass Core runs as an edge application on the OpenNESS Edge Node. It is deployed as a Docker Container, and provides a network interface to the AWS Cloud. Greengrass Core uses edge node services to provision cloud applications, which run on the edge node as edge applications.
+Figure 2 shows a system consisting of AWS, AWS Greengrass, and an Smart Edge Open platform. In this architecture, the Greengrass Core runs as an edge application on the Smart Edge Open Edge Node. It is deployed as a Docker Container, and provides a network interface to the AWS Cloud. Greengrass Core uses edge node services to provision cloud applications, which run on the edge node as edge applications.
 
-For AWS Cloud, Greengrass Core and the applications appear to be components meeting the Greengrass specification and running on an external system. Greengrass Core can run Lambdas within Greengrass core as normal. Greengrass Core and the lambdas have ports from external devices to which traffic is steered by the OpenNESS data plane.
+For AWS Cloud, Greengrass Core and the applications appear to be components meeting the Greengrass specification and running on an external system. Greengrass Core can run Lambdas within Greengrass core as normal. Greengrass Core and the lambdas have ports from external devices to which traffic is steered by the Smart Edge Open data plane.
 
-For OpenNESS, Greengrass Core is an edge service managed by the edge platform.
+For Smart Edge Open, Greengrass Core is an edge service managed by the edge platform.
 
-![OpenNESS AWS Greengrass integration](awsgg-images/openness_cloudadapter.png)
+![Smart Edge Open AWS Greengrass integration](awsgg-images/smartedge-open_cloudadapter.png)
 
-Figure 2 - Amazon AWS Greengrass OpenNESS integrated solution 
+Figure 2 - Amazon AWS Greengrass Smart Edge Open integrated solution 
 
-This section describes how to set up and run AWS Greengrass on OpenNESS in a Docker container.
+This section describes how to set up and run AWS Greengrass on Smart Edge Open in a Docker container.
 ### Running AWS IoT Greengrass in a Docker Container
 
-OpenNESS was tested with Docker v1.9.2 of the AWS IoT Greengrass Core software version. 
+Smart Edge Open was tested with Docker v1.9.2 of the AWS IoT Greengrass Core software version. 
 
 #### Download Dockerfile from AWS
 
@@ -103,8 +103,8 @@ Then save the modified container image into the file:
 docker save aws-iot-greengrass > aws-iot-greengrass.tar.gz
 ```
 
-Now deploy the `aws-iot-greengrass.tar.gz` file in OpenNESS according to the Controller User Guide.
+Now deploy the `aws-iot-greengrass.tar.gz` file in Smart Edge Open according to the Controller User Guide.
 <!-- Provide a link to user guide referenced above. -->
 ### Greengrass Deployment on AWS IoT
 
-After the Greengrass container is run by the OpenNESS Controller, follow the Greengrass setup and deployment steps in the [AWS IoT Greengrass Developer Guide](https://docs.aws.amazon.com/greengrass/latest/developerguide).
+After the Greengrass container is run by the Smart Edge Open Controller, follow the Greengrass setup and deployment steps in the [AWS IoT Greengrass Developer Guide](https://docs.aws.amazon.com/greengrass/latest/developerguide).
diff --git a/doc/cloud-adapters/openness_baiducloud.md b/doc/cloud-adapters/smartedge-open_baiducloud.md
similarity index 83%
rename from doc/cloud-adapters/openness_baiducloud.md
rename to doc/cloud-adapters/smartedge-open_baiducloud.md
index 5083d4ab..cf5dd148 100644
--- a/doc/cloud-adapters/openness_baiducloud.md
+++ b/doc/cloud-adapters/smartedge-open_baiducloud.md
@@ -3,11 +3,11 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019-2021 Intel Corporation
 ```
 <!-- omit in toc -->
-# OpenNESS Integration with Baidu OpenEdge
+# Smart Edge Open Integration with Baidu OpenEdge
 - [Overview](#overview)
 - [Integration Architecture](#integration-architecture)
-- [Run OpenEdge on OpenNESS](#run-openedge-on-openness)
-  - [OpenNESS Setup](#openness-setup)
+- [Run OpenEdge on Smart Edge Open](#run-openedge-on-smart-edge-open)
+  - [Smart Edge Open Setup](#smart-edge-open-setup)
   - [OpenEdge Setup](#openedge-setup)
     - [Scripts overview](#scripts-overview)
     - [Prepare OpenEdge certs and configuration files](#prepare-openedge-certs-and-configuration-files)
@@ -22,44 +22,44 @@ Copyright (c) 2019-2021 Intel Corporation
 
 ## Overview
 
-OpenNESS is an open-source software toolkit to enable easy orchestration and management of edge services across diverse network platforms and access technologies in multi-cloud environments.
-OpenNESS can integrate with Baidu\* Cloud Connector, OpenEdge, which is Edge IoT Gateway. 
+Smart Edge Open is an open-source software toolkit to enable easy orchestration and management of edge services across diverse network platforms and access technologies in multi-cloud environments.
+Smart Edge Open can integrate with Baidu\* Cloud Connector, OpenEdge, which is Edge IoT Gateway. 
 Together with Baidu edge management dashboard, the whole Baidu Edge solution is called Baidu IntelliEdge\*. For more details, refer to Baidu's website: www.baidu.com
 
 This application note provides guidelines and examples on:
 
 - Integration architecture description
-- Run Baidu OpenEdge on the OpenNESS platform
+- Run Baidu OpenEdge on the Smart Edge Open platform
 - End-to-end example
 
 ## Integration Architecture
 
-Figure 1. Integration Architecture for OpenEdge on OpenNESS
+Figure 1. Integration Architecture for OpenEdge on Smart Edge Open
 
-![](baidu-cloudadapter-images//openness_baiduedge_integration_arch.png)
+![](baidu-cloudadapter-images//smartedge-open_baiduedge_integration_arch.png)
 
-- OpenNESS Edge platform supports cloud-native infrastructure. Baidu OpenEdge and other edge apps can run as a separate container.
-  OpenNESS NTS will send/receive data traffic to/from the apps according to traffic routing configuration.
+- Smart Edge Open Edge platform supports cloud-native infrastructure. Baidu OpenEdge and other edge apps can run as a separate container.
+  Smart Edge Open NTS will send/receive data traffic to/from the apps according to traffic routing configuration.
 
 - OpenEdge can play as two types of Apps
-  - **Producer**: provides a service to other apps on the Edge Platform (need a control path between OpenEdge and OpenNESS for EAA interaction).
-  - **Consumer**: consumes end-user traffic and optionally can get services from producer apps on the same edge platform. If the Consumer needs to get services from other edge apps, they need to use a control path to authenticate and register with OpenNESS.
+  - **Producer**: provides a service to other apps on the Edge Platform (need a control path between OpenEdge and Smart Edge Open for EAA interaction).
+  - **Consumer**: consumes end-user traffic and optionally can get services from producer apps on the same edge platform. If the Consumer needs to get services from other edge apps, they need to use a control path to authenticate and register with Smart Edge Open.
   
  >**NOTE**: In the application note, OpenEdge is treated as a pure consumer application and does not need to get service from other edge apps. Thus, in the integration architecture diagram, there is no control path.
 
-## Run OpenEdge on OpenNESS 
+## Run OpenEdge on Smart Edge Open 
 
-This section describes how to set up and run OpenEdge as a consumer application on OpenNESS based on cloud-native infrastructure.
+This section describes how to set up and run OpenEdge as a consumer application on Smart Edge Open based on cloud-native infrastructure.
 
-### OpenNESS Setup
+### Smart Edge Open Setup
 
-Follow the `OpenNESS user guide` to prepare a setup environment, deploy OpenNESS, and configure traffic routing rules.
+Follow the `Smart Edge Open user guide` to prepare a setup environment, deploy Smart Edge Open, and configure traffic routing rules.
 <!-- provide a link to the user guide referenced above. -->
 ### OpenEdge Setup
 
 #### Scripts overview
 
-In the OpenNESS release package, it provides example scripts to help users with the setup. 
+In the Smart Edge Open release package, it provides example scripts to help users with the setup. 
 The scripts are located in the release package with the folder name `setup_baidu_openedge` as shown in the structure below:
 
 ```docker
@@ -93,7 +93,7 @@ setup_baidu_openedge
 ```
 
 There are three main scripts: `01_setup.sh`, `02_build.sh`, and `03_deploy.sh`. The scripts need to be executed as the root user in the order
-from the local console on the OpenNESS server or remotely via SSH. The other scripts will be called by the three main scripts for the setup.
+from the local console on the Smart Edge Open server or remotely via SSH. The other scripts will be called by the three main scripts for the setup.
 - The folder - `mqtt` contains MQTT IOT device simulators for end-to-end testing so that they should be executed from device machines.
 - The folder - `democfg` is where you should put files downloaded from the Baidu\* cloud to bring up OpenEdge. For details, refer to the below chapter. 
 <!-- Provide a link to specific chapter referenced above. -->
@@ -258,7 +258,7 @@ To get more information about Baidu IotHub Cloud, go to cloud.baidu.com, and sea
 
 #### Running scripts -- build and run OpenEdge
 
-On the server that is running OpenNESS, execute the scripts as shown below:
+On the server that is running Smart Edge Open, execute the scripts as shown below:
 ```docker
 01_setup.sh
 02_build.sh
@@ -289,28 +289,28 @@ composefile_baidu_edge_1
 
 Figure 2. End to End Example Diagram.
 
-![](baidu-cloudadapter-images//openness_baiduedge_end2end_demosetup.png)
+![](baidu-cloudadapter-images//smartedge-open_baiduedge_end2end_demosetup.png)
 
 This is an end-to-end example demo for MQTT traffic. This could be an IoT industrial application. 
 It consists of the following elements and related IoT data processing:
 
 - Two MQTT devices as publisher and subscriber. The MQTT client software is used to simuate two MQTT IoT devices.
 
-- OpenNESS Controller: performs management and policy configuration. 
-  For this example, the controller will configure traffic rules for routing MQTT IOT traffic to Baidu OpenEdge via OpenNESS.
-- Baidu OpenEdge: In the example provided, the OpenNESS Baidu OpenEdge app is deployed as a pure Consumer app which does not consume any services from producer applications on the edge node. Hence, the Baidu OpenEdge app does not need to call EAA APIs. The app will handle data traffic from/to MQTT devices via the OpenNESS dataplane.
+- Smart Edge Open Controller: performs management and policy configuration. 
+  For this example, the controller will configure traffic rules for routing MQTT IOT traffic to Baidu OpenEdge via Smart Edge Open.
+- Baidu OpenEdge: In the example provided, the Smart Edge Open Baidu OpenEdge app is deployed as a pure Consumer app which does not consume any services from producer applications on the edge node. Hence, the Baidu OpenEdge app does not need to call EAA APIs. The app will handle data traffic from/to MQTT devices via the Smart Edge Open dataplane.
 
 >**NOTE**: Implementing EAA APIs in the Baidu OpenEdge application will further enhance the capability of the Baidu OpenEdge based application as they can consume services, such as location and radio network information, from the Edge Node. 
 
 - IOT MQTT Data plane processing:
   (1) Device #1 publishes its status data by using the MQTT protocol.
-  (2) The OpenNESS Platform forwards the traffic to Baidu OpenEdge according to traffic rules. Baidu OpenEdge will then perform local computing and data filtering.
+  (2) The Smart Edge Open Platform forwards the traffic to Baidu OpenEdge according to traffic rules. Baidu OpenEdge will then perform local computing and data filtering.
   (3) According to the topic configuration, Baidu OpenEdge sends data to Baidu Cloud.
   (4) Also, Baidu OpenEdge forwards the message to device #2 subscriber.
 
 ### Run MQTT simulator
 
-The OpenNESS release package provides example scripts to help users run the MQTT simulator and RTT testing. 
+The Smart Edge Open release package provides example scripts to help users run the MQTT simulator and RTT testing. 
 The scripts can be found in the release package with the subfolder name `setup_baidu_openedge/mqtt `as the below structure:
 
 ```docker
diff --git a/doc/devkits/openness-azure-devkit.md b/doc/devkits/openness-azure-devkit.md
deleted file mode 100644
index 213667c0..00000000
--- a/doc/devkits/openness-azure-devkit.md
+++ /dev/null
@@ -1,17 +0,0 @@
-```text
-SPDX-License-Identifier: Apache-2.0
-Copyright (c) 2020 Intel Corporation
-```
-
-# OpenNESS Devkit for Azure
-
-## Introduction
-
-This devkit supports the use of OpenNESS in cloud solutions. It leverages the Azure Stack for OpenNESS deployment.
-The devkit offers a quick and easy way to deploy OpenNESS on cloud for developers and businesses. It contains templates
-for automated depoyment, and supports deployment using Porter. It enables cloud solutions supported by Intel's processors.
-
-## Getting Started
-
-Following document contains steps for quick deployment on Azure:
-* [<b>converged-edge-experience-kits/cloud/README.md</b>: Deployment and setup guide](https://github.com/open-ness/converged-edge-experience-kits/blob/master/cloud/README.md)
diff --git a/doc/devkits/smartedge-open-azure-devkit.md b/doc/devkits/smartedge-open-azure-devkit.md
new file mode 100644
index 00000000..e2902497
--- /dev/null
+++ b/doc/devkits/smartedge-open-azure-devkit.md
@@ -0,0 +1,17 @@
+```text
+SPDX-License-Identifier: Apache-2.0
+Copyright (c) 2020 Intel Corporation
+```
+
+# Smart Edge Open Devkit for Azure
+
+## Introduction
+
+This devkit supports the use of Smart Edge Open in cloud solutions. It leverages the Azure Stack for Smart Edge Open deployment.
+The devkit offers a quick and easy way to deploy Smart Edge Open on cloud for developers and businesses. It contains templates
+for automated depoyment, and supports deployment using Porter. It enables cloud solutions supported by Intel's processors.
+
+## Getting Started
+
+Following document contains steps for quick deployment on Azure:
+* [<b>converged-edge-experience-kits/cloud/README.md</b>: Deployment and setup guide](https://github.com/smart-edge-open/converged-edge-experience-kits/blob/master/cloud/README.md)
diff --git a/doc/flavors.md b/doc/flavors.md
index 75088ae3..75ccb1d0 100644
--- a/doc/flavors.md
+++ b/doc/flavors.md
@@ -3,28 +3,28 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# OpenNESS Deployment Flavors
+# Smart Edge Open Deployment Flavors
 This document introduces the supported deployment flavors that are deployable through the Converged Edge Experience Kits (CEEK).
 
-- [CERA Minimal Flavor](#cera-minimal-flavor)
-- [CERA Access Edge Flavor](#cera-access-edge-flavor)
-- [CERA Media Analytics Flavor](#cera-media-analytics-flavor)
-- [CERA Media Analytics Flavor with VCAC-A](#cera-media-analytics-flavor-with-vcac-a)
-- [CERA CDN Transcode Flavor](#cera-cdn-transcode-flavor)
-- [CERA CDN Caching Flavor](#cera-cdn-caching-flavor)
-- [CERA Core Control Plane Flavor](#cera-core-control-plane-flavor)
-- [CERA Core User Plane Flavor](#cera-core-user-plane-flavor)
-- [CERA Untrusted Non3gpp Access Flavor](#cera-untrusted-non3gpp-access-flavor)
-- [CERA Near Edge Flavor](#cera-near-edge-flavor)
-- [CERA 5G On-Prem Flavor](#cera-5g-on-prem-flavor)
+- [Smart Edge Open Experience Kit Minimal Flavor](#smart-edge-open-experience-kit-minimal-flavor)
+- [Smart Edge Open Experience Kit Access Edge Flavor](#smart-edge-open-experience-kit-access-edge-flavor)
+- [Smart Edge Open Experience Kit Media Analytics Flavor](#smart-edge-open-experience-kit-media-analytics-flavor)
+- [Smart Edge Open Experience Kit Media Analytics Flavor with VCAC-A](#smart-edge-open-experience-kit-media-analytics-flavor-with-vcac-a)
+- [Smart Edge Open Experience Kit CDN Transcode Flavor](#smart-edge-open-experience-kit-cdn-transcode-flavor)
+- [Smart Edge Open Experience Kit CDN Caching Flavor](#smart-edge-open-experience-kit-cdn-caching-flavor)
+- [Smart Edge Open Experience Kit Core Control Plane Flavor](#smart-edge-open-experience-kit-core-control-plane-flavor)
+- [Smart Edge Open Experience Kit Core User Plane Flavor](#smart-edge-open-experience-kit-core-user-plane-flavor)
+- [Smart Edge Open Experience Kit Untrusted Non3gpp Access Flavor](#smart-edge-open-experience-kit-untrusted-non3gpp-access-flavor)
+- [Smart Edge Open Experience Kit Near Edge Flavor](#smart-edge-open-experience-kit-near-edge-flavor)
+- [Smart Edge Open Experience Kit 5G On-Prem Flavor](#smart-edge-open-experience-kit-5g-on-prem-flavor)
 - [Central Orchestrator Flavor](#central-orchestrator-flavor)
 
-## CERA Minimal Flavor
+## Smart Edge Open Experience Kit Minimal Flavor
 
-The pre-defined *minimal* deployment flavor provisions the minimal set of configurations for bringing up the OpenNESS network edge deployment.
+The pre-defined *minimal* deployment flavor provisions the minimal set of configurations for bringing up the Smart Edge Open network edge deployment.
 
 The following are steps to install this flavor:
-1. Configure the CEEK as described in the [OpenNESS Getting Started Guide for Network Edge](getting-started/openness-cluster-setup.md).
+1. Configure the CEEK as described in the [Smart Edge Open Getting Started Guide for Network Edge](getting-started/smartedge-open-cluster-setup.md).
 2. Update the `inventory.yaml` file by setting the deployment flavor as `minimal`
     ```yaml
     ---
@@ -46,16 +46,16 @@ This deployment flavor enables the following ingredients:
 
 To customize this flavor we recommend creating additional file in converged-edge-experience-kits that will override any variables used in previous configuration. This file should be placed in location: `converged-edge-experience-kits/inventory/default/group_vars/all` and filenames should start with number greater than highest value currently present (e.g. `40-overrides.yml`).
 
-## CERA Access Edge Flavor
+## Smart Edge Open Experience Kit Access Edge Flavor
 
-Available in Intel Distribution of OpenNESS
+Available in Intel Distribution of Smart Edge Open
 
-## CERA Media Analytics Flavor
+## Smart Edge Open Experience Kit Media Analytics Flavor
 
 The pre-defined *media-analytics* deployment flavor provisions an optimized system configuration for media analytics workloads on Intel® Xeon® platforms. It also provisions a set of video analytics services based on the [Video Analytics Serving](https://github.com/intel/video-analytics-serving) for analytics pipeline management and execution.
 
 The following are steps to install this flavor:
-1. Configure the CEEK as described in the [OpenNESS Getting Started Guide for Network Edge](getting-started/openness-cluster-setup.md).
+1. Configure the CEEK as described in the [Smart Edge Open Getting Started Guide for Network Edge](getting-started/smartedge-open-cluster-setup.md).
 2. Update the `inventory.yaml` file by setting the deployment flavor as `media-analytics`
     ```yaml
     ---
@@ -70,7 +70,7 @@ The following are steps to install this flavor:
     $ python3 deploy.py
     ```
 
-> **NOTE:** The video analytics services integrates with the OpenNESS service mesh when the flag `ne_istio_enable: true` is set.
+> **NOTE:** The video analytics services integrates with the Smart Edge Open service mesh when the flag `ne_istio_enable: true` is set.
 > **NOTE:** Kiali management console username can be changed by editing the variable `istio_kiali_username`. By default `istio_kiali_password` is randomly generated and can be retirieved by running `kubectl get secrets/kiali -n istio-system -o json | jq -r '.data.passphrase' | base64 -d` on the Kubernetes controller.
 > **NOTE:** Istio deployment can be customized using parameters in the `flavor/media-analytics/all.yaml` (parameters set in the flavor file override default parameters set in `inventory/default/group_vars/all/10-default.yml`).
 
@@ -82,12 +82,12 @@ This deployment flavor enables the following ingredients:
 * Istio service mesh - conditional
 * Kiali management console - conditional
 
-## CERA Media Analytics Flavor with VCAC-A
+## Smart Edge Open Experience Kit Media Analytics Flavor with VCAC-A
 
 The pre-defined *media-analytics-vca* deployment flavor provisions an optimized system configuration for media analytics workloads leveraging Visual Cloud Accelerator Card for Analytics (VCAC-A) acceleration.
 
 The following are steps to install this flavor:
-1. Configure the CEEK as described in the [OpenNESS Getting Started Guide for Network Edge](getting-started/openness-cluster-setup.md).
+1. Configure the CEEK as described in the [Smart Edge Open Getting Started Guide for Network Edge](getting-started/smartedge-open-cluster-setup.md).
 2. Add the VCA host name in the `edgenode_vca_group:` group in `inventory.yml` file of the CEEK, e.g:
     ```yaml
     edgenode_vca_group:
@@ -123,12 +123,12 @@ This deployment flavor enables the following ingredients:
 * The `weavenet` Kubernetes CNI
 * Telemetry
 
-## CERA CDN Transcode Flavor
+## Smart Edge Open Experience Kit CDN Transcode Flavor
 
 The pre-defined *cdn-transcode* deployment flavor provisions an optimized system configuration for Content Delivery Network (CDN) transcode sample workloads on Intel® Xeon® platforms.
 
 The following are steps to install this flavor:
-1. Configure the CEEK as described in the [OpenNESS Getting Started Guide for Network Edge](getting-started/openness-cluster-setup.md).
+1. Configure the CEEK as described in the [Smart Edge Open Getting Started Guide for Network Edge](getting-started/smartedge-open-cluster-setup.md).
 2. Update the `inventory.yaml` file by setting the deployment flavor as `cdn-transcode`
     ```yaml
     ---
@@ -148,12 +148,12 @@ This deployment flavor enables the following ingredients:
 * The default Kubernetes CNI: `calico`
 * Telemetry
 
-## CERA CDN Caching Flavor
+## Smart Edge Open Experience Kit CDN Caching Flavor
 
 The pre-defined *cdn-caching* deployment flavor provisions an optimized system configuration for CDN content delivery workloads on Intel® Xeon® platforms.
 
 The following are steps to install this flavor:
-1. Configure the CEEK as described in the [OpenNESS Getting Started Guide for Network Edge](getting-started/openness-cluster-setup.md).
+1. Configure the CEEK as described in the [Smart Edge Open Getting Started Guide for Network Edge](getting-started/smartedge-open-cluster-setup.md).
 2. Update the `inventory.yaml` file by setting the deployment flavor as `cdn-caching`
     ```yaml
     ---
@@ -174,34 +174,34 @@ This deployment flavor enables the following ingredients:
 * Telemetry
 * Kubernetes Topology Manager policy: `single-numa-node`
 
-## CERA Core Control Plane Flavor
+## Smart Edge Open Experience Kit Core Control Plane Flavor
 
-Available in Intel Distribution of OpenNESS
+Available in Intel Distribution of Smart Edge Open
   
-## CERA Core User Plane Flavor
+## Smart Edge Open Experience Kit Core User Plane Flavor
 
-Available in Intel Distribution of OpenNESS
+Available in Intel Distribution of Smart Edge Open
   
-## CERA Untrusted Non3gpp Access Flavor
+## Smart Edge Open Experience Kit Untrusted Non3gpp Access Flavor
 
-Available in Intel Distribution of OpenNESS
+Available in Intel Distribution of Smart Edge Open
   
-## CERA Near Edge Flavor
+## Smart Edge Open Experience Kit Near Edge Flavor
 
-Available in Intel Distribution of OpenNESS
+Available in Intel Distribution of Smart Edge Open
   
-## CERA 5G On-Prem Flavor
+## Smart Edge Open Experience Kit 5G On-Prem Flavor
 
-Available in Intel Distribution of OpenNESS
+Available in Intel Distribution of Smart Edge Open
 
 ## Central Orchestrator Flavor
 
 Central Orchestrator Flavor is used to deploy EMCO.  
 
-The pre-defined *orchestration* deployment flavor provisions an optimized system configuration for emco (central orchestrator) workloads on Intel Xeon servers. It also provisions a set of central orchestrator services for [edge, multiple clusters orchestration](building-blocks/emco/openness-emco.md).
+The pre-defined *orchestration* deployment flavor provisions an optimized system configuration for emco (central orchestrator) workloads on Intel Xeon servers. It also provisions a set of central orchestrator services for [edge, multiple clusters orchestration](building-blocks/emco/smartedge-open-emco.md).
 
 The following are steps to install this flavor:
-1. Configure the CEEK as described in the [OpenNESS Getting Started Guide for Network Edge](getting-started/openness-cluster-setup.md).
+1. Configure the CEEK as described in the [Smart Edge Open Getting Started Guide for Network Edge](getting-started/smartedge-open-cluster-setup.md).
 2. Update the `inventory.yaml` file by setting the deployment flavor as `central_orchestrator`
     ```yaml
     ---
diff --git a/doc/getting-started/converged-edge-experience-kits.md b/doc/getting-started/converged-edge-experience-kits.md
index 9009a9eb..fe93b26b 100644
--- a/doc/getting-started/converged-edge-experience-kits.md
+++ b/doc/getting-started/converged-edge-experience-kits.md
@@ -33,7 +33,7 @@ The Converged Edge Experience Kit is a refreshed repository of Ansible\* playboo
 
 The Converged Edge Experience Kit introduces the following capabilities:
 1. Wide range of deployments from individual building blocks to full end-to-end reference deployments
-2. Minimal to near-zero user interventions.. Typically, the user provides the details of the nodes that constitute the OpenNESS edge cluster and executes the deployment script
+2. Minimal to near-zero user interventions.. Typically, the user provides the details of the nodes that constitute the Smart Edge Open edge cluster and executes the deployment script
 3. More advanced deployments can be customized in the form of Ansible\* group and host variables. This mode requires users with in-depth knowledge and expertise of the subject edge deployment
 4. Enablement of end-to-end multi-cluster deployments such as Near Edge and On-premises reference architectures
 
@@ -83,8 +83,8 @@ The inventory file defines the group of physical nodes that constitute the edge
 
 The following variables must be defined 
 
-* `cluster_name`: a given name for the OpenNESS edge cluster deployment - separated by underscores `_` instead of spaces.
-* `flavor`: the deployment flavor applicable for the OpenNESS edge deployment as defined in the [Deployment flavors](../flavors.md) document.
+* `cluster_name`: a given name for the Smart Edge Open edge cluster deployment - separated by underscores `_` instead of spaces.
+* `flavor`: the deployment flavor applicable for the Smart Edge Open edge deployment as defined in the [Deployment flavors](../flavors.md) document.
 * `single_node_deployment`: If set to `true`, a single-node cluster is deployed.. Must satisfy the following conditions:
   - IP address (`ansible_host`) for both controller and node must be the same
   - `controller_group` and `edgenode_group` groups must contain exactly one host
@@ -237,7 +237,7 @@ The following are several common customization scenarios.
 ### IP address range allocation for various CNIs and interfaces
 
 The Converged Edge Experience kits deployment uses/allocates/reserves a set of IP address ranges for different CNIs and interfaces. The server or host IP address should not conflict with the default address allocation.
-In case if there is a critical need for the server IP address used by the OpenNESS default deployment, it would require to modify the default addresses used by the OpenNESS.
+In case if there is a critical need for the server IP address used by the Smart Edge Open default deployment, it would require to modify the default addresses used by the Smart Edge Open.
 
 Following files specify the CIDR for CNIs and interfaces. These are the IP address ranges allocated and used by default just for reference.
 
@@ -253,7 +253,7 @@ roles/kubernetes/cni/kubeovn/controlplane/templates/crd_local.yml.j2:13:  cidrBl
 The `192.168.*.*` is used for SRIOV and interface service IP address allocation in Kube-ovn CNI. So it is not allowed for the server IP address, which conflicting with this range.
 Completely avoid the range of address defined as per the netmask as it may conflict in routing rules.
 
-E.g., If the server/host IP address is required to use `192.168.*.*` while this range by default used for SRIOV interfaces in OpenNESS. The IP address range for `cidrBlock` in `roles/kubernetes/cni/kubeovn/controlplane/templates/crd_local.yml.j2` file can be changed to `192.167.{{ loop.index0 + 1 }}.0/24` to use some other IP segment for SRIOV interfaces.
+E.g., If the server/host IP address is required to use `192.168.*.*` while this range by default used for SRIOV interfaces in Smart Edge Open. The IP address range for `cidrBlock` in `roles/kubernetes/cni/kubeovn/controlplane/templates/crd_local.yml.j2` file can be changed to `192.167.{{ loop.index0 + 1 }}.0/24` to use some other IP segment for SRIOV interfaces.
 
 
 ### Default values
@@ -407,7 +407,7 @@ The following are basic prechecks that are currently executed:
   * Check if `kubeovn` is requested as a primary (first on the list).
   * Check if the requested CNI is available (check if some CNI is requested that isn't present in the `available_kubernetes_cnis` list).
 * CNI roles should be as self-contained as possible (unless necessary, CNI-specific tasks should not be present in `kubernetes/{controlplane,node,common}` or `openness/network_edge/{controlplane,node}`).
-* If the CNI needs a custom OpenNESS service (e.g., Interface Service in case of `kube-ovn`), it can be added to the `openness/network_edge/{controlplane,node}`.<br>
+* If the CNI needs a custom Smart Edge Open service (e.g., Interface Service in case of `kube-ovn`), it can be added to the `openness/network_edge/{controlplane,node}`.<br>
   Preferably, such tasks would be contained in a separate task file (e.g., `roles/openness/controlplane/tasks/kube-ovn.yml`) and executed only if the CNI is requested. For example:
   ```yaml
   - name: deploy interface service for kube-ovn
diff --git a/doc/getting-started/harbor-registry.md b/doc/getting-started/harbor-registry.md
index 11469d84..ff6eeee0 100644
--- a/doc/getting-started/harbor-registry.md
+++ b/doc/getting-started/harbor-registry.md
@@ -3,7 +3,7 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019-2021 Intel Corporation
 ```
 <!-- omit in toc -->
-# Harbor Registry Service in OpenNESS
+# Harbor Registry Service in Smart Edge Open
 - [Deploy Harbor registry](#deploy-harbor-registry)
   - [System Prerequisite](#system-prerequisite)
   - [Ansible Playbooks](#ansible-playbooks)
@@ -17,7 +17,7 @@ Copyright (c) 2019-2021 Intel Corporation
   - [CLI - List Image Repositories](#cli---list-image-repositories)
   - [CLI - Delete Image](#cli---delete-image)
 
-Harbor registry is an open source cloud native registry which can support images and relevant artifacts with extended functionalities as described in [Harbor](https://goharbor.io/). On the OpenNESS environment, Harbor registry service is installed on Control plane Node by Harbor Helm Chart [github](https://github.com/goharbor/harbor-helm/releases/tag/v1.5.1). Harbor registry authentication enabled with self-signed certificates as well as all nodes and control plane will have access to the Harbor registry.
+Harbor registry is an open source cloud native registry which can support images and relevant artifacts with extended functionalities as described in [Harbor](https://goharbor.io/). On the Smart Edge Open environment, Harbor registry service is installed on Control plane Node by Harbor Helm Chart [github](https://github.com/goharbor/harbor-helm/releases/tag/v1.5.1). Harbor registry authentication enabled with self-signed certificates as well as all nodes and control plane will have access to the Harbor registry.
 
 ## Deploy Harbor registry
 
@@ -33,18 +33,18 @@ role: harbor_registry/controlplane
 role: harbor_registry/node
 ```
 
-The following steps are processed by converged-edge-experience-kits during the Harbor registry installation on the OpenNESS control plane node.
+The following steps are processed by converged-edge-experience-kits during the Harbor registry installation on the Smart Edge Open control plane node.
 
 * Download Harbor Helm Charts on the Kubernetes Control plane Node.
 * Check whether huge pages is enabled and templates values.yaml file accordingly.
 * Create namespace and disk PV for Harbor Services (The default disk PV/PVC total size is 20G. The values can be configured in the `roles/kubernetes/harbor_registry/controlplane/defaults/main.yaml`).
 * Install Harbor on the control plane node using the Helm Charts (The CA crt will be generated by Harbor itself). 
-* Create the new project - ```intel``` for OpenNESS microservices, Kurbernetes enhanced add-on images storage.
+* Create the new project - ```intel``` for Smart Edge Open microservices, Kurbernetes enhanced add-on images storage.
 * Docker login the Harbor Registry, thus enable pulling, pushing and tag images with the Harbor Registry
 
 
-On the OpenNESS edge nodes, converged-edge-experience-kits will conduct the following steps:
-* Get harbor.crt from the OpenNESS control plane node and save into the host location
+On the Smart Edge Open edge nodes, converged-edge-experience-kits will conduct the following steps:
+* Get harbor.crt from the Smart Edge Open control plane node and save into the host location
   /etc/docker/certs.d/<Kubernetes_Control_Plane_IP:port>
 * Docker login the Harbor Registry, thus enable pulling, pushing and tag images with the Harbor Registry
 * After above steps, the Node and Ansible host can access the private Harbor registry.
@@ -55,12 +55,12 @@ On the OpenNESS edge nodes, converged-edge-experience-kits will conduct the foll
 ### Projects 
 Two Harbor projects will be created by CEEK as below:
 - ```library``` The registry project can be used by edge application developer as default images registries.
-- ```intel```   The registry project contains the registries for the OpenNESS microservices and relevant kubernetes addon images. Can also be used for OpenNESS sample application images.
+- ```intel```   The registry project contains the registries for the Smart Edge Open microservices and relevant kubernetes addon images. Can also be used for Smart Edge Open sample application images.
 
 ## Harbor login
-For the nodes inside of the OpenNESS cluster, converged-edge-experience-kits ansible playbooks automatically login and prepare harbor CA certifications to access Harbor services. 
+For the nodes inside of the Smart Edge Open cluster, converged-edge-experience-kits ansible playbooks automatically login and prepare harbor CA certifications to access Harbor services. 
 
-For the external host outside of the OpenNESS cluster, can use following commands to access the Harbor Registry:
+For the external host outside of the Smart Edge Open cluster, can use following commands to access the Harbor Registry:
 
 ```shell
 # create directory for harbor's CA crt
@@ -96,7 +96,7 @@ Use the `docker pull` command to pull the image from Harbor registry:
 
 ## Harbor UI
 Open the https://{Kubernetes_Control_Plane_IP}:30003 with login username ```admin``` and password ```Harbor12345```:
-![](openness-cluster-setup-images/harbor_ui.png)
+![](smartedge-open-cluster-setup-images/harbor_ui.png)
 
 You could see two projects: ```intel``` and ```library``` on the Web UI. For more details about Harbor usage, can refer to [Harbor docs](https://goharbor.io/docs/2.1.0/working-with-projects/).
 
diff --git a/doc/getting-started/index.html b/doc/getting-started/index.html
index 35875c79..07291d97 100644
--- a/doc/getting-started/index.html
+++ b/doc/getting-started/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
-window.location = "openness-cluster-setup"
+window.location = "smartedge-open-cluster-setup"
 </script>
diff --git a/doc/getting-started/kubernetes-dashboard.md b/doc/getting-started/kubernetes-dashboard.md
index d62a73c7..a51549c3 100644
--- a/doc/getting-started/kubernetes-dashboard.md
+++ b/doc/getting-started/kubernetes-dashboard.md
@@ -3,9 +3,9 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019 Intel Corporation
 ```
 <!-- omit in toc -->
-# Kubernetes Dashboard in OpenNESS
+# Kubernetes Dashboard in Smart Edge Open
 - [Overview](#overview)
-- [Details - Kubernetes Dashboard support in OpenNESS](#details---kubernetes-dashboard-support-in-openness)
+- [Details - Kubernetes Dashboard support in Smart Edge Open](#details---kubernetes-dashboard-support-in-smart-edge-open)
   - [TLS encryption](#tls-encryption)
   - [Usage](#usage)
   - [Access rights](#access-rights)
@@ -13,9 +13,9 @@ Copyright (c) 2019 Intel Corporation
 
 ## Overview
 
-Kubernetes Dashboard is a web user interface for Kubernetes. User can use Dashboard to check the state of deployed pods, get information about all kinds of deployments that are being run on cluster and be provided with lots of useful insights about cluster and running applications. In OpenNESS environment Kubernetes Dashboard will be deployed with read-only access to all information except Kubernetes' Secrets. User can modify this role to disable or enable accesses as explained in [Access rights](#access-rights) chapter of this document.
+Kubernetes Dashboard is a web user interface for Kubernetes. User can use Dashboard to check the state of deployed pods, get information about all kinds of deployments that are being run on cluster and be provided with lots of useful insights about cluster and running applications. In Smart Edge Open environment Kubernetes Dashboard will be deployed with read-only access to all information except Kubernetes' Secrets. User can modify this role to disable or enable accesses as explained in [Access rights](#access-rights) chapter of this document.
 
-## Details - Kubernetes Dashboard support in OpenNESS
+## Details - Kubernetes Dashboard support in Smart Edge Open
 
 Kubernetes Dashboard is disabled by default in Converged Edge Experience Kits. It can be enabled by setting variable `kubernetes_dashboard_enable` in `inventory/default/group_vars/all/10-default.yml` file to `true` value:
 
@@ -46,7 +46,7 @@ kubectl describe secret -n kube-system $(kubectl get secret -n kube-system | gre
 
 ### Access rights
 
-By default OpenNESS will deploy Kubernetes Dashboard with read-only access to every information except Kubernetes' secrets. To change access rights (for example hide information about persistent volumes claims, etc.) please modify cluster role defined in `roles/kubernetes/dashboard/files/clusterrole.yml` of Converged Edge Experience Kits.
+By default Smart Edge Open will deploy Kubernetes Dashboard with read-only access to every information except Kubernetes' secrets. To change access rights (for example hide information about persistent volumes claims, etc.) please modify cluster role defined in `roles/kubernetes/dashboard/files/clusterrole.yml` of Converged Edge Experience Kits.
 
 ## Reference
 - [Kubernetes Dashboard](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/)
diff --git a/doc/getting-started/non-root-user.md b/doc/getting-started/non-root-user.md
index 6255e2fb..63766c3d 100644
--- a/doc/getting-started/non-root-user.md
+++ b/doc/getting-started/non-root-user.md
@@ -3,7 +3,7 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2021 Intel Corporation
 ```
 <!-- omit in toc -->
-# The non-root user on the OpenNESS Platform
+# The non-root user on the Smart Edge Open Platform
 - [Overview](#overview)
 - [Steps on K8s nodes](#steps-on-k8s-nodes)
 - [Repository modification](#repository-modification)
@@ -11,7 +11,7 @@ Copyright (c) 2021 Intel Corporation
 
 ## Overview
 
-OpenNESS provides a possibility to install all required files on a Kubernetes control plane and nodes with or without root user. From security perspective it is advised to use non-root user installation of the OpenNESS platform where all tasks are executed with non-root user’s permissions. Tasks that require root privileges use privilege escalation property "become".
+Smart Edge Open provides a possibility to install all required files on a Kubernetes control plane and nodes with or without root user. From security perspective it is advised to use non-root user installation of the Smart Edge Open platform where all tasks are executed with non-root user’s permissions. Tasks that require root privileges use privilege escalation property "become".
 
    ```yml
   - name: Run a command as root
@@ -35,7 +35,7 @@ A password for the given user is required.
 passwd "openness"
 ```
 
-As some tasks require root privileges the non-root user needs to have a possibility to become a root. For the user `openness` the following command must be performed:
+As some tasks require root privileges the non-root user needs to have a possibility to become a root. For the user `smartedge-open` the following command must be performed:
 
 ```bash
 echo "openness  ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/openness
diff --git a/doc/getting-started/openness-cluster-setup-images/harbor_ui.png b/doc/getting-started/smartedge-open-cluster-setup-images/harbor_ui.png
similarity index 100%
rename from doc/getting-started/openness-cluster-setup-images/harbor_ui.png
rename to doc/getting-started/smartedge-open-cluster-setup-images/harbor_ui.png
diff --git a/doc/getting-started/openness-cluster-setup.md b/doc/getting-started/smartedge-open-cluster-setup.md
similarity index 88%
rename from doc/getting-started/openness-cluster-setup.md
rename to doc/getting-started/smartedge-open-cluster-setup.md
index 20d29dc3..b5263328 100644
--- a/doc/getting-started/openness-cluster-setup.md
+++ b/doc/getting-started/smartedge-open-cluster-setup.md
@@ -3,7 +3,7 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2019-2021 Intel Corporation
 ```
 <!-- omit in toc -->
-# OpenNESS Cluster Setup
+# Smart Edge Open Cluster Setup
 - [Quickstart](#quickstart)
 - [Preconditions](#preconditions)
 - [Running playbooks](#running-playbooks)
@@ -30,11 +30,11 @@ Copyright (c) 2019-2021 Intel Corporation
   - [Customization of kernel, grub parameters, and tuned profile](#customization-of-kernel-grub-parameters-and-tuned-profile)
 
 # Quickstart
-The following set of actions must be completed to set up the Open Network Edge Services Software (OpenNESS) cluster.
+The following set of actions must be completed to set up the Open Network Edge Services Software (Smart Edge Open) cluster.
 
 1. Fulfill the [Preconditions](#preconditions).
 2. Become familiar with [supported features](#supported-epa-features) and enable them if desired.
-3. Clone [Converged Edge Experience Kits](https://github.com/open-ness/converged-edge-experience-kits)
+3. Clone [Converged Edge Experience Kits](https://github.com/smart-edge-open/converged-edge-experience-kits)
 4. Install deployment helper script pre-requisites (first time only)
    
     ```shell
@@ -69,7 +69,7 @@ The following subsections describe the playbooks in more details.
 
 For convenience, playbooks can be executed by running helper deployment scripts from the Ansible host. These scripts require that the Edge Controller and Edge Nodes be configured on different hosts (for deployment on a single node, refer to [Single-node Network Edge cluster](#single-node-network-edge-cluster)). This is done by configuring the Ansible playbook inventory, as described later in this document.
 
-To get started with deploying an OpenNESS edge cluster using the Converged Edge Experience Kit:
+To get started with deploying an Smart Edge Open edge cluster using the Converged Edge Experience Kit:
 
 1. Install pre-requisite tools for the the deployment script 
    
@@ -159,14 +159,14 @@ $ python3 deploy.py --clean
 
 ### Supported EPA features
 
-Several enhanced platform capabilities and features are available in OpenNESS for Network Edge. For the full list of supported features, refer to Building Blocks / Enhanced Platform Awareness section. The documents referenced in this list provide a detailed description of the features, and step-by-step instructions for enabling them. Users should become familiar with available features before executing the deployment playbooks.
+Several enhanced platform capabilities and features are available in Smart Edge Open for Network Edge. For the full list of supported features, refer to Building Blocks / Enhanced Platform Awareness section. The documents referenced in this list provide a detailed description of the features, and step-by-step instructions for enabling them. Users should become familiar with available features before executing the deployment playbooks.
 
 ### VM support for Network Edge
-Support for VM deployment on OpenNESS for Network Edge is available and enabled by default. Certain configurations and prerequisites may need to be satisfied to use all VM capabilities. The user is advised to become familiar with the VM support documentation before executing the deployment playbooks. See [VM support in OpenNESS for Network Edge](../applications-onboard/openness-network-edge-vm-support.md) for more information.
+Support for VM deployment on Smart Edge Open for Network Edge is available and enabled by default. Certain configurations and prerequisites may need to be satisfied to use all VM capabilities. The user is advised to become familiar with the VM support documentation before executing the deployment playbooks. See [VM support in Smart Edge Open for Network Edge](../applications-onboard/smartedge-open-network-edge-vm-support.md) for more information.
 
 ### Application on-boarding
 
-Refer to the [network-edge-applications-onboarding](../applications-onboard/network-edge-applications-onboarding.md) document for instructions on how to deploy edge applications for OpenNESS Network Edge.
+Refer to the [network-edge-applications-onboarding](../applications-onboard/network-edge-applications-onboarding.md) document for instructions on how to deploy edge applications for Smart Edge Open Network Edge.
 
 ### Single-node Network Edge cluster
 
@@ -241,8 +241,8 @@ The following CNIs are currently supported:
   * Network attachment definition: openness-flannel
 * [weavenet](https://github.com/weaveworks/weave)
   * CIDR: 10.32.0.0/12
-* [SR-IOV](https://github.com/intel/sriov-cni) (cannot be used as a standalone or primary CNI - [sriov setup](../building-blocks/enhanced-platform-awareness/openness-sriov-multiple-interfaces.md))
-* [Userspace](https://github.com/intel/userspace-cni-network-plugin) (cannot be used as a standalone or primary CNI - [Userspace CNI setup](../building-blocks/dataplane/openness-userspace-cni.md)
+* [SR-IOV](https://github.com/intel/sriov-cni) (cannot be used as a standalone or primary CNI - [sriov setup](../building-blocks/enhanced-platform-awareness/smartedge-open-sriov-multiple-interfaces.md))
+* [Userspace](https://github.com/intel/userspace-cni-network-plugin) (cannot be used as a standalone or primary CNI - [Userspace CNI setup](../building-blocks/dataplane/smartedge-open-userspace-cni.md)
 
 Multiple CNIs can be requested to be set up for the cluster. To provide such functionality [the Multus CNI](https://github.com/intel/multus-cni) is used.
 
@@ -250,7 +250,7 @@ Multiple CNIs can be requested to be set up for the cluster. To provide such fun
 
 ### Selecting cluster networking plugins (CNI)
 
-The default CNI for OpenNESS is calico. Non-default CNIs may be configured with OpenNESS by editing the file `inventory/default/group_vars/all/10-default.yml`.
+The default CNI for Smart Edge Open is calico. Non-default CNIs may be configured with Smart Edge Open by editing the file `inventory/default/group_vars/all/10-default.yml`.
 To add a non-default CNI, the following edits must be carried out:
 
 - The CNI name is added to the `kubernetes_cnis` variable. The CNIs are applied in the order in which they appear in the file. By default, `calico` is defined. That is,
@@ -320,9 +320,9 @@ The following interfaces are available: `calico@if142`, `flannel@if143`, and `et
 
 ## Configuring time
 
-To allow for correct certificate verification, OpenNESS requires system time to be synchronized among all nodes and controllers in a system.
+To allow for correct certificate verification, Smart Edge Open requires system time to be synchronized among all nodes and controllers in a system.
 
-OpenNESS provides the possibility to synchronize a machine's time with the NTP server.
+Smart Edge Open provides the possibility to synchronize a machine's time with the NTP server.
 To enable NTP synchronization, change `ntp_enable` in `inventory/default/group_vars/all/10-default.yml`:
 ```yaml
 ntp_enable: true
@@ -353,18 +353,18 @@ In addition to being a unique hostname within the cluster, the hostname must als
 
 ## Configuring the Inventory file
 
-To execute playbooks, an inventory file `inventory.yml` must be defined in order to specify the target nodes on which the OpenNESS cluster(s) will be deployed.
+To execute playbooks, an inventory file `inventory.yml` must be defined in order to specify the target nodes on which the Smart Edge Open cluster(s) will be deployed.
 
-The OpenNESS inventory contains three groups: `all`, `controller_group`, and `edgenode_group`.
+The Smart Edge Open inventory contains three groups: `all`, `controller_group`, and `edgenode_group`.
 
 - `all` contains all the variable definitions relevant to the cluster:
-  > `cluster_name`: defines the name of the OpenNESS edge cluster 
-  > `flavor`: the deployment flavor to be deployed to the OpenNESS edge cluster
+  > `cluster_name`: defines the name of the Smart Edge Open edge cluster 
+  > `flavor`: the deployment flavor to be deployed to the Smart Edge Open edge cluster
   > `single_node_deployment`: when set to `true`, mandates a single-node cluster deployment
-- `controller_group` defines the node to be set up as the OpenNESS Edge Controller
+- `controller_group` defines the node to be set up as the Smart Edge Open Edge Controller
   > **NOTE**: Because only one controller is supported, the `controller_group` can contain only one host.
-- `edgenode_group` defines the group of nodes that constitute the OpenNESS Edge Nodes.
-  > **NOTE**: All nodes will be joined to the OpenNESS Edge Controller defined in `controller_group`.
+- `edgenode_group` defines the group of nodes that constitute the Smart Edge Open Edge Nodes.
+  > **NOTE**: All nodes will be joined to the Smart Edge Open Edge Controller defined in `controller_group`.
 
 Example:
 
@@ -455,7 +455,7 @@ and check to make sure that only the key(s) you wanted were added.
 To make sure the key is copied successfully, try to SSH into the host: `ssh 'root@host'`. It should not ask for the password.
 
 >**NOTE**: Where non-root user is used for example `openness` the command should be replaced to `ssh openness@host`. For more information about non-root user please refer to: 
-[The non-root user on the OpenNESS Platform](../getting-started/non-root-user.md)
+[The non-root user on the Smart Edge Open Platform](../getting-started/non-root-user.md)
 ## Setting proxy
 
 If a proxy is required to connect to the Internet, it is configured via the following steps:
@@ -489,13 +489,13 @@ export no_proxy="localhost,127.0.0.1,10.244.0.0/24,10.96.0.0/12,192.168.0.0/24"
 
 ## Obtaining installation files
 
-There are no specific restrictions on the directory into which the OpenNESS directories are cloned. When OpenNESS is built, additional directories will be installed in `/opt`. It is recommended to clone the project into a directory such as `/home`.
+There are no specific restrictions on the directory into which the Smart Edge Open directories are cloned. When Smart Edge Open is built, additional directories will be installed in `/opt`. It is recommended to clone the project into a directory such as `/home`.
 
 ## Setting Git
 
 ### GitHub token
 
->**NOTE**: Only required when cloning private repositories. Not needed when using github.com/open-ness repositories.
+>**NOTE**: Only required when cloning private repositories. Not needed when using github.com/smart-edge-open repositories.
 
 To clone private repositories, a GitHub token must be provided.
 
@@ -508,7 +508,7 @@ A specific tag, branch, or commit SHA on edgeservices repository can be checked
 ```yaml
 git_repo_branch: master
 # or
-git_repo_branch: openness-20.03
+git_repo_branch: smartedge-open-20.03
 ```
 
 ## Customization of kernel, grub parameters, and tuned profile
diff --git a/doc/index.html b/doc/index.html
index 01525581..e3dbbc81 100644
--- a/doc/index.html
+++ b/doc/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
 window.location = "architecture"
 </script>
diff --git a/doc/orchestration/index.html b/doc/orchestration/index.html
index 6bbee5e8..07a73326 100644
--- a/doc/orchestration/index.html
+++ b/doc/orchestration/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
-window.location = "openness-helm"
+window.location = "smartedge-open-helm"
 </script>
diff --git a/doc/orchestration/openness-helm-images/openness-helm-arch.png b/doc/orchestration/smartedge-open-helm-images/smartedge-open-helm-arch.png
similarity index 100%
rename from doc/orchestration/openness-helm-images/openness-helm-arch.png
rename to doc/orchestration/smartedge-open-helm-images/smartedge-open-helm-arch.png
diff --git a/doc/orchestration/openness-helm.md b/doc/orchestration/smartedge-open-helm.md
similarity index 58%
rename from doc/orchestration/openness-helm.md
rename to doc/orchestration/smartedge-open-helm.md
index fff0e018..7bcbcc96 100644
--- a/doc/orchestration/openness-helm.md
+++ b/doc/orchestration/smartedge-open-helm.md
@@ -3,7 +3,7 @@ SPDX-License-Identifier: Apache-2.0
 Copyright (c) 2020 Intel Corporation
 ```
 <!-- omit in toc -->
-# Helm support in OpenNESS
+# Helm support in Smart Edge Open
 
 - [Introduction](#introduction)
 - [Architecture](#architecture)
@@ -12,53 +12,53 @@ Copyright (c) 2020 Intel Corporation
 - [References](#references)
 
 ## Introduction
-Helm is a package manager for Kubernetes\*. It allows developers and operators to easily package, configure, and deploy applications and services onto Kubernetes clusters. For details refer to the [Helm Website](https://helm.sh). With OpenNESS, Helm is used to extend the [Converged Edge Experience Kits](https://github.com/open-ness/converged-edge-experience-kits) Ansible\* playbooks to deploy Kubernetes packages. Helm adds considerable flexibility. It enables users to upgrade an existing installation without requiring a re-install. It provides the option to selectively deploy individual microservices if a full installation of OpenNESS is not needed. And it provides a standard process to deploy different applications or network functions. This document aims to familiarize the user with Helm and provide instructions on how to use the specific Helm charts available for OpenNESS. 
+Helm is a package manager for Kubernetes\*. It allows developers and operators to easily package, configure, and deploy applications and services onto Kubernetes clusters. For details refer to the [Helm Website](https://helm.sh). With Smart Edge Open, Helm is used to extend the [Converged Edge Experience Kits](https://github.com/smart-edge-open/converged-edge-experience-kits) Ansible\* playbooks to deploy Kubernetes packages. Helm adds considerable flexibility. It enables users to upgrade an existing installation without requiring a re-install. It provides the option to selectively deploy individual microservices if a full installation of Smart Edge Open is not needed. And it provides a standard process to deploy different applications or network functions. This document aims to familiarize the user with Helm and provide instructions on how to use the specific Helm charts available for Smart Edge Open. 
 
 ## Architecture
-The below figure shows the architecture for the OpenNESS Helm in this document.
-![OpenNESS Helm](openness-helm-images/openness-helm-arch.png)
+The below figure shows the architecture for the Smart Edge Open Helm in this document.
+![Smart Edge Open Helm](smartedge-open-helm-images/smartedge-open-helm-arch.png)
 
-_Figure - Helm Architecture in OpenNESS_
+_Figure - Helm Architecture in Smart Edge Open_
 
 
 ## Helm Installation
-Helm 3 is used for OpenNESS. The installation is automatically conducted by the [Converged Edge Experience Kits](https://github.com/open-ness/converged-edge-experience-kits) Ansible playbooks as below:
+Helm 3 is used for Smart Edge Open. The installation is automatically conducted by the [Converged Edge Experience Kits](https://github.com/smart-edge-open/converged-edge-experience-kits) Ansible playbooks as below:
    ```yaml
    - role: kubernetes/helm
    ```
-To check whether helm is installed successfully, run the following command on the OpenNESS controller:
+To check whether helm is installed successfully, run the following command on the Smart Edge Open controller:
    ```bash
    $ helm version
    version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}
    ```
 ## Helm Charts   
-OpenNESS provides the following helm charts: 
+Smart Edge Open provides the following helm charts: 
 - EPA, Telemetry, and k8s plugins: 
   - CMK, NFD, FPGA Config, SRIOV, VPU, and GPU Device Plugins
   - Prometheus\*, NodeExporter, Cadvisor, Collectd, Opentelemetry, PCM, and Grafana\*
   - CNI plugins including Multus\* and SRIOV CNI
   - Video analytics service
   - 5G control plane pods including AF, NEF, OAM, and CNTF
-> **NOTE**: NFD, CMK, Prometheus, NodeExporter, and Grafana leverage existing third-party helm charts: [Container Experience Kits](https://github.com/intel/container-experience-kits) and [Helm GitHub\* Repo](https://github.com/helm/charts). For other helm charts, [Converged Edge Experience Kits](https://github.com/open-ness/converged-edge-experience-kits) Ansible playbooks perform automatic charts generation and deployment.
+> **NOTE**: NFD, CMK, Prometheus, NodeExporter, and Grafana leverage existing third-party helm charts: [Container Experience Kits](https://github.com/intel/container-experience-kits) and [Helm GitHub\* Repo](https://github.com/helm/charts). For other helm charts, [Converged Edge Experience Kits](https://github.com/smart-edge-open/converged-edge-experience-kits) Ansible playbooks perform automatic charts generation and deployment.
 
-- Sample applications, network functions, and services that can be deployed and verified on the OpenNESS platform:
+- Sample applications, network functions, and services that can be deployed and verified on the Smart Edge Open platform:
   - Applications
-    - [CDN Caching Application Helm Charts](https://github.com/open-ness/edgeapps/tree/master/applications/cdn-caching)
+    - [CDN Caching Application Helm Charts](https://github.com/smart-edge-open/edgeapps/tree/master/applications/cdn-caching)
     - [CDN Transcode Application Helm Charts](https://github.com/OpenVisualCloud/CDN-Transcode-Sample/tree/master/deployment/kubernetes/helm) (Leverage OpenVisualCloud) 
     - [Smart City Application Helm Charts](https://github.com/OpenVisualCloud/Smart-City-Sample/tree/master/deployment/kubernetes/helm) (Leverage OpenVisualCloud)
-    - [Telemetry Sample Application Helm Charts](https://github.com/open-ness/edgeapps/tree/master/applications/telemetry-sample-app)
-    - [EIS Sample Application Helm Charts](https://github.com/open-ness/edgeapps/tree/master/applications/eis-experience-kit)
+    - [Telemetry Sample Application Helm Charts](https://github.com/smart-edge-open/edgeapps/tree/master/applications/telemetry-sample-app)
+    - [EIS Sample Application Helm Charts](https://github.com/smart-edge-open/edgeapps/tree/master/applications/eis-experience-kit)
   - Network Functions
-    - [FlexRAN Helm Charts](https://github.com/open-ness/edgeapps/tree/master/network-functions/ran/charts/du-dev)
-    - [xRAN Helm Charts](https://github.com/open-ness/edgeapps/tree/master/network-functions/xran/helmcharts/xranchart)
-    - [UPF Helm Charts](https://github.com/open-ness/edgeapps/tree/master/network-functions/core-network/charts/upf)
+    - [FlexRAN Helm Charts](https://github.com/smart-edge-open/edgeapps/tree/master/network-functions/ran/charts/du-dev)
+    - [xRAN Helm Charts](https://github.com/smart-edge-open/edgeapps/tree/master/network-functions/xran/helmcharts/xranchart)
+    - [UPF Helm Charts](https://github.com/smart-edge-open/edgeapps/tree/master/network-functions/core-network/charts/upf)
 
-The EPA, Telemetry, and k8s plugins helm chart files will be saved in a specific directory on the OpenNESS controller. To modify the directory, change the following variable `ne_helm_charts_default_dir` in the `inventory/default/group_vars/all/10-default.yml` file:
+The EPA, Telemetry, and k8s plugins helm chart files will be saved in a specific directory on the Smart Edge Open controller. To modify the directory, change the following variable `ne_helm_charts_default_dir` in the `inventory/default/group_vars/all/10-default.yml` file:
    ```yaml
    ne_helm_charts_default_dir: /opt/openness/helm-charts/
    ```
 
-To check helm charts files, run the following command on the OpenNESS controller:
+To check helm charts files, run the following command on the Smart Edge Open controller:
    ```bash
    $ ls /opt/openness/helm-charts/
    vpu-plugin gpu-plugin node-feature-discovery prometheus
@@ -73,7 +73,7 @@ To check helm releases, run:
    intel-gpu-plugin        default         1               2020-05-08 03:10:05.464149345 +0800 CST deployed        intel-gpu-plugin-0.1.0               0.17.0
    intel-vpu-plugin        default         1               2020-05-08 03:23:44.595413394 +0800 CST deployed        intel-vpu-plugin-0.1.0               0.17.0
    ```
-> **NOTE**: Different OpenNESS flavors contain different platform features. This is just an example of the helm charts.
+> **NOTE**: Different Smart Edge Open flavors contain different platform features. This is just an example of the helm charts.
 
 To see the values that took effect for a specific release (for example, `nfd-release`), run:
    ```bash
diff --git a/doc/overview.md b/doc/overview.md
index 19c16748..026cf2e9 100644
--- a/doc/overview.md
+++ b/doc/overview.md
@@ -4,21 +4,21 @@ Copyright (c) 2019-2020 Intel Corporation
 ```
 
 <!-- omit in toc -->
-# OpenNESS Overview
+# Smart Edge Open Overview
 
-- [Introduction to OpenNESS](#introduction-to-openness)
-- [Why consider OpenNESS](#why-consider-openness)
+- [Introduction to Smart Edge Open](#introduction-to-smart-edge-open)
+- [Why consider Smart Edge Open](#why-consider-smart-edge-open)
 - [Building Blocks](#building-blocks)
 - [Distributions](#distributions)
 - [Consumption Models](#consumption-models)
 
-## Introduction to OpenNESS 
+## Introduction to Smart Edge Open 
 
-OpenNESS is an edge computing software toolkit that enables highly optimized and performant edge platforms to on-board and manage applications and network functions with cloud-like agility across any type of network.
+Smart Edge Open is an edge computing software toolkit that enables highly optimized and performant edge platforms to on-board and manage applications and network functions with cloud-like agility across any type of network.
 
 The toolkit includes a variety of Building Blocks that enable you to build different types of Converged Edge platforms that combine IT (Information Technology), OT (Operational Technology) and CT (Communications Technology).
 
-OpenNESS can help speed up the development of Edges such as:
+Smart Edge Open can help speed up the development of Edges such as:
 
 - Cloud Native RAN with Apps
 - 5G distributed UPF with Apps
@@ -26,9 +26,9 @@ OpenNESS can help speed up the development of Edges such as:
 - AI/vision inferencing apps with MEC 
 - Media apps with MEC
 
-OpenNESS is a Certified Kubernetes* offering. See the [CNCF Software Conformance program](https://www.cncf.io/certification/software-conformance/) for details.
+Smart Edge Open is a Certified Kubernetes* offering. See the [CNCF Software Conformance program](https://www.cncf.io/certification/software-conformance/) for details.
 
-## Why consider OpenNESS
+## Why consider Smart Edge Open
 
 In the era of 5G, as the cloud architectures start to disaggregate, various locations on the Telco edge start to become prime candidates for compute workloads that are capable of delivering a new set of KPIs for a new breed of apps and services. These locations include the On-prem edge (located typically in an enterprise), the Access Edge (located at or close to a 5G basestation), the Near Edge (the next aggregation point hosting a distributed UPF) and the Regional Data Center (hosting a Next Gen Central Office with wireless/wireline convergence).
 
@@ -40,9 +40,9 @@ As the industry seeks to settle on a consistent cloud native platform approach c
 - Optimize cloud native frameworks to meet stringent edge KPIs and simplify network complexity
 - Leverage a broad ecosystem and evolving standards for edge computing
 
-OpenNESS brings together the best of breed cloud native frameworks to build a horizontal edge computing platform to address these challenges.
+Smart Edge Open brings together the best of breed cloud native frameworks to build a horizontal edge computing platform to address these challenges.
 
-**Benefits of OpenNESS**
+**Benefits of Smart Edge Open**
 
 Edge Performant & Optimized: 
 
@@ -61,7 +61,7 @@ Ease of Use, Consumability & Time to Market (TTM)
 
 ## Building Blocks
 
-OpenNESS is composed of a set of Building Blocks, each intended to offer a set of capabilities for edge solutions.
+Smart Edge Open is composed of a set of Building Blocks, each intended to offer a set of capabilities for edge solutions.
 
 | Building Block                   | Summary                                                      |
 | -------------------------------- | ------------------------------------------------------------ |
@@ -78,30 +78,30 @@ OpenNESS is composed of a set of Building Blocks, each intended to offer a set o
 
 
 ## Distributions
-OpenNESS is released as two distributions:
-1. <b>OpenNESS </b>: A full open-source distribution of OpenNESS
-2. <b>Intel® Distribution of OpenNESS </b>: A licensed distribution from Intel that includes all the features in OpenNESS along with additional microservices, Kubernetes\* extensions, enhancements, and optimizations for Intel® architecture. 
+Smart Edge Open is released as two distributions:
+1. <b>Smart Edge Open </b>: A full open-source distribution of Smart Edge Open
+2. <b>Intel® Distribution of Smart Edge Open </b>: A licensed distribution from Intel that includes all the features in Smart Edge Open along with additional microservices, Kubernetes\* extensions, enhancements, and optimizations for Intel® architecture. 
 
-The Intel Distribution of OpenNESS requires a secure login to the OpenNESS GitHub repository. For access to the Intel Distribution of OpenNESS, contact your Intel support representative. 
+The Intel Distribution of Smart Edge Open requires a secure login to the Smart Edge Open GitHub repository. For access to the Intel Distribution of Smart Edge Open, contact your Intel support representative. 
 
 ## Consumption Models
 
-OpenNESS can be consumed as a whole or as individual building blocks. Whether you are an infrastructure developer or an app developer, if you are moving your business to the Edge, you may benefit from utilizing OpenNESS in your next project. 
+Smart Edge Open can be consumed as a whole or as individual building blocks. Whether you are an infrastructure developer or an app developer, if you are moving your business to the Edge, you may benefit from utilizing Smart Edge Open in your next project. 
 
 **Building Blocks**
 
-You can explore the various building blocks packaged as Helm Charts and Kubernetes* Operators via the [OpenNESS github project](https://github.com/open-ness).
+You can explore the various building blocks packaged as Helm Charts and Kubernetes* Operators via the [Smart Edge Open github project](https://github.com/smart-edge-open).
 
-**Converged Edge Reference Architectures (CERA)**
+**Converged Edge Reference Architectures (Smart Edge Open Experience Kit)**
 
-CERA is a set of pre-integrated and readily deployable HW/SW Reference Architectures powered by OpenNESS to significantly accelerate Edge Platform Development, available via the [OpenNESS github project](https://github.com/open-ness).
+Smart Edge Open Experience Kit is a set of pre-integrated and readily deployable HW/SW Reference Architectures powered by Smart Edge Open to significantly accelerate Edge Platform Development, available via the [Smart Edge Open github project](https://github.com/smart-edge-open).
 
 **Cloud Devkits**
 
-Software toolkits to easily deploy an OpenNESS cluster in a cloud environment such as Azure Cloud, available via the [OpenNESS github project](https://github.com/open-ness). 
+Software toolkits to easily deploy an Smart Edge Open cluster in a cloud environment such as Azure Cloud, available via the [Smart Edge Open github project](https://github.com/smart-edge-open). 
 
 **Converged Edge Insights**
 
 Ready to deploy software packages available via the [Intel® Edge Software Hub](https://www.intel.com/content/www/us/en/edge-computing/edge-software-hub.html), comes with use case specific reference implementations to kick start your next pathfinding effort for the Edge.
 
-Next explore the [OpenNESS Architecture](architecture.md). 
+Next explore the [Smart Edge Open Architecture](architecture.md). 
diff --git a/doc/reference-architectures/core-network/epc-images/openness_epc1.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_epc1.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/openness_epc1.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_epc1.png
diff --git a/doc/reference-architectures/core-network/epc-images/openness_epc2.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_epc2.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/openness_epc2.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_epc2.png
diff --git a/doc/reference-architectures/core-network/epc-images/openness_epc3.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_epc3.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/openness_epc3.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_epc3.png
diff --git a/doc/reference-architectures/core-network/epc-images/openness_epc_cnca_1.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_epc_cnca_1.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/openness_epc_cnca_1.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_epc_cnca_1.png
diff --git a/doc/reference-architectures/core-network/epc-images/openness_epcconfig.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_epcconfig.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/openness_epcconfig.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_epcconfig.png
diff --git a/doc/reference-architectures/core-network/epc-images/openness_epctest1.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_epctest1.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/openness_epctest1.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_epctest1.png
diff --git a/doc/reference-architectures/core-network/epc-images/openness_epctest2.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_epctest2.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/openness_epctest2.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_epctest2.png
diff --git a/doc/reference-architectures/core-network/epc-images/openness_epctest3.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_epctest3.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/openness_epctest3.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_epctest3.png
diff --git a/doc/reference-architectures/core-network/epc-images/openness_epctest4.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_epctest4.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/openness_epctest4.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_epctest4.png
diff --git a/doc/reference-architectures/core-network/epc-images/openness_epcupf_add.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_epcupf_add.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/openness_epcupf_add.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_epcupf_add.png
diff --git a/doc/reference-architectures/core-network/epc-images/openness_epcupf_del.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_epcupf_del.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/openness_epcupf_del.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_epcupf_del.png
diff --git a/doc/reference-architectures/core-network/epc-images/openness_epcupf_get.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_epcupf_get.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/openness_epcupf_get.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_epcupf_get.png
diff --git a/doc/reference-architectures/core-network/epc-images/Openness_highlevel.png b/doc/reference-architectures/core-network/epc-images/smartedge-open_highlevel.png
similarity index 100%
rename from doc/reference-architectures/core-network/epc-images/Openness_highlevel.png
rename to doc/reference-architectures/core-network/epc-images/smartedge-open_highlevel.png
diff --git a/doc/reference-architectures/core-network/index.html b/doc/reference-architectures/core-network/index.html
index a595915d..b0ac9c9b 100644
--- a/doc/reference-architectures/core-network/index.html
+++ b/doc/reference-architectures/core-network/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
-window.location = "openness_epc"
+window.location = "smartedge-open_epc"
 </script>
diff --git a/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_add.png b/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_add.png
index 76a5bf0b..f42bea04 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_add.png and b/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_add.png differ
diff --git a/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_del.png b/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_del.png
index 7322575c..92532727 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_del.png and b/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_del.png differ
diff --git a/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_get.png b/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_get.png
index 442b58d7..49284845 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_get.png and b/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_get.png differ
diff --git a/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_update.png b/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_update.png
index 7222d94c..332ee8a6 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_update.png and b/doc/reference-architectures/core-network/ngc-images/PFD_Management_transaction_update.png differ
diff --git a/doc/reference-architectures/core-network/ngc-images/e2e_edge_deployment_flows.png b/doc/reference-architectures/core-network/ngc-images/e2e_edge_deployment_flows.png
index b0f22bd0..865a8cea 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/e2e_edge_deployment_flows.png and b/doc/reference-architectures/core-network/ngc-images/e2e_edge_deployment_flows.png differ
diff --git a/doc/reference-architectures/core-network/ngc-images/oam_af_service_add.png b/doc/reference-architectures/core-network/ngc-images/oam_af_service_add.png
index 24f2c653..b46095b0 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/oam_af_service_add.png and b/doc/reference-architectures/core-network/ngc-images/oam_af_service_add.png differ
diff --git a/doc/reference-architectures/core-network/ngc-images/oam_af_service_del.png b/doc/reference-architectures/core-network/ngc-images/oam_af_service_del.png
index 624fe3ca..d00bb514 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/oam_af_service_del.png and b/doc/reference-architectures/core-network/ngc-images/oam_af_service_del.png differ
diff --git a/doc/reference-architectures/core-network/ngc-images/oam_af_service_get.png b/doc/reference-architectures/core-network/ngc-images/oam_af_service_get.png
index 9493abc5..ab78dc9d 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/oam_af_service_get.png and b/doc/reference-architectures/core-network/ngc-images/oam_af_service_get.png differ
diff --git a/doc/reference-architectures/core-network/ngc-images/oam_af_service_update.png b/doc/reference-architectures/core-network/ngc-images/oam_af_service_update.png
index 1c02fd57..f00d49f1 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/oam_af_service_update.png and b/doc/reference-architectures/core-network/ngc-images/oam_af_service_update.png differ
diff --git a/doc/reference-architectures/core-network/ngc-images/traffic_subscription_add.png b/doc/reference-architectures/core-network/ngc-images/traffic_subscription_add.png
index 0c7fce26..7a03a2a2 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/traffic_subscription_add.png and b/doc/reference-architectures/core-network/ngc-images/traffic_subscription_add.png differ
diff --git a/doc/reference-architectures/core-network/ngc-images/traffic_subscription_del.png b/doc/reference-architectures/core-network/ngc-images/traffic_subscription_del.png
index 0b1354a4..4f2c7cf4 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/traffic_subscription_del.png and b/doc/reference-architectures/core-network/ngc-images/traffic_subscription_del.png differ
diff --git a/doc/reference-architectures/core-network/ngc-images/traffic_subscription_get.png b/doc/reference-architectures/core-network/ngc-images/traffic_subscription_get.png
index 4b086618..23970355 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/traffic_subscription_get.png and b/doc/reference-architectures/core-network/ngc-images/traffic_subscription_get.png differ
diff --git a/doc/reference-architectures/core-network/ngc-images/traffic_subscription_update.png b/doc/reference-architectures/core-network/ngc-images/traffic_subscription_update.png
index 7d1b24f6..eef609fd 100644
Binary files a/doc/reference-architectures/core-network/ngc-images/traffic_subscription_update.png and b/doc/reference-architectures/core-network/ngc-images/traffic_subscription_update.png differ
diff --git a/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_add.uml b/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_add.uml
index 1b5316ec..cceb4b06 100644
--- a/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_add.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_add.uml
@@ -11,17 +11,17 @@ skinparam sequenceArrowThickness 3
 
 header Intel Corporation
 footer Proprietary and Confidential
-title Traffic influencing flows between OpenNESS controller and 5G Core
+title Traffic influencing flows between Smart Edge Open controller and 5G Core
 
 actor "User/Admin" as user
-box "OpenNESS Controller components" #LightBlue
+box "Smart Edge Open Controller components" #LightBlue
     participant "UI/CLI" as cnca 
     participant "AF Microservice" as af
 end box
 box "5G Core components" #LightGreen
     participant "NEF" as nef
     note over nef 
-        OpenNESS provided 
+        Smart Edge Open provided 
         Core component with 
         limited functionality
     end note
@@ -36,7 +36,7 @@ group Traffic influence submission flow
     af -> nef : /3gpp-traffic-Influence/v1/{afId}/subscriptions : POST \n {3GPP TS 29.522v15.3 \n Sec. 5.4} 
     activate nef
     nef -> nef : NGC_STUB(PCF,UDR,BSF)
-    nef -> ngccp : {Open: 3rd party NGC integration with OpenNESS(NEF)}
+    nef -> ngccp : {Open: 3rd party NGC integration with Smart Edge Open(NEF)}
     ngccp --> nef :
     nef --> af : OK: {subscriptionId} \n ERROR: {400/500}
     deactivate nef
diff --git a/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_delete.uml b/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_delete.uml
index 8841e5be..5765a599 100644
--- a/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_delete.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_delete.uml
@@ -11,17 +11,17 @@ skinparam sequenceArrowThickness 3
 
 header Intel Corporation
 footer Proprietary and Confidential
-title Traffic influencing flows between OpenNESS controller and 5G Core
+title Traffic influencing flows between Smart Edge Open controller and 5G Core
 
 actor "User/Admin" as user
-box "OpenNESS Controller components" #LightBlue
+box "Smart Edge Open Controller components" #LightBlue
     participant "UI/CLI" as cnca 
     participant "AF Microservice" as af
 end box
 box "5G Core components" #LightGreen
     participant "NEF" as nef
     note over nef 
-        OpenNESS provided 
+        Smart Edge Open provided 
         Core component with 
         limited functionality
     end note
@@ -37,7 +37,7 @@ group Delete a subscribed traffic influence by subscriptionId
     af -> nef : /3gpp-traffic-Influence/v1/{afId}/subscriptions/{subscriptionId} : DELETE
     activate nef
     nef -> nef : NGC_STUB(PCF,UDR,BSF)
-    nef -> ngccp : {Open: 3rd party NGC integration with OpenNESS(NEF)}
+    nef -> ngccp : {Open: 3rd party NGC integration with Smart Edge Open(NEF)}
     ngccp --> nef :
     nef --> af : OK : Delete success \n ERROR: {400/500}
     deactivate nef
diff --git a/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_get.uml b/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_get.uml
index 44921c43..1cea90c2 100644
--- a/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_get.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_get.uml
@@ -11,17 +11,17 @@ skinparam sequenceArrowThickness 3
 
 header Intel Corporation
 footer Proprietary and Confidential
-title Traffic influencing flows between OpenNESS controller and 5G Core
+title Traffic influencing flows between Smart Edge Open controller and 5G Core
 
 actor "User/Admin" as user
-box "OpenNESS Controller components" #LightBlue
+box "Smart Edge Open Controller components" #LightBlue
     participant "UI/CLI" as cnca 
     participant "AF Microservice" as af
 end box
 box "5G Core components" #LightGreen
     participant "NEF" as nef
     note over nef 
-        OpenNESS provided 
+        Smart Edge Open provided 
         Core component with 
         limited functionality
     end note
@@ -36,7 +36,7 @@ group Get all subscribed traffic influence info
     af -> nef : /3gpp-traffic-Influence/v1/{afId}/subscriptions : GET 
     activate nef
     nef -> nef : NGC_STUB(PCF,UDR,BSF)
-    nef -> ngccp : {Open: 3rd party NGC integration with OpenNESS(NEF)}
+    nef -> ngccp : {Open: 3rd party NGC integration with Smart Edge Open(NEF)}
     ngccp --> nef :
     nef --> af : OK: traffic influence info \n ERROR: {400/500}
     deactivate nef
@@ -54,7 +54,7 @@ group Get subscribed traffic influence info by subscriptionId
     af -> nef : /3gpp-traffic-Influence/v1/{afId}/subscriptions/{subscriptionId} : GET 
     activate nef
     nef -> nef : NGC_STUB(PCF,UDR,BSF)
-    nef -> ngccp : {Open: 3rd party NGC integration with OpenNESS(NEF)}
+    nef -> ngccp : {Open: 3rd party NGC integration with Smart Edge Open(NEF)}
     ngccp --> nef :
     nef --> af : OK: traffic influence info \n ERROR: {400/500}
     deactivate nef
diff --git a/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_update.uml b/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_update.uml
index 87fd3102..12f4e520 100644
--- a/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_update.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/AF_traffic_influence_update.uml
@@ -11,17 +11,17 @@ skinparam sequenceArrowThickness 3
 
 header Intel Corporation
 footer Proprietary and Confidential
-title Traffic influencing flows between OpenNESS controller and 5G Core
+title Traffic influencing flows between Smart Edge Open controller and 5G Core
 
 actor "User/Admin" as user
-box "OpenNESS Controller components" #LightBlue
+box "Smart Edge Open Controller components" #LightBlue
     participant "UI/CLI" as cnca 
     participant "AF Microservice" as af
 end box
 box "5G Core components" #LightGreen
     participant "NEF" as nef
     note over nef 
-        OpenNESS provided 
+        Smart Edge Open provided 
         Core component with 
         limited functionality
     end note
@@ -36,7 +36,7 @@ group Update a subscribed traffic influence by subscriptionId
     af -> nef : /3gpp-traffic-Influence/v1/{afId}/subscriptions/{subscriptionId} : PUT
     activate nef
     nef -> nef : NGC_STUB(PCF,UDR,BSF)
-    nef -> ngccp : {Open: 3rd party NGC integration with OpenNESS(NEF)}
+    nef -> ngccp : {Open: 3rd party NGC integration with Smart Edge Open(NEF)}
     ngccp --> nef :
     nef --> af : OK : Update success, traffic influence info \n ERROR: {400/500}
     deactivate nef
diff --git a/doc/reference-architectures/core-network/ngc_flows/PFD_Management_transaction_delete.uml b/doc/reference-architectures/core-network/ngc_flows/PFD_Management_transaction_delete.uml
index dfaca683..979e04a8 100644
--- a/doc/reference-architectures/core-network/ngc_flows/PFD_Management_transaction_delete.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/PFD_Management_transaction_delete.uml
@@ -20,7 +20,7 @@ participant "Af Microservice" as AF
 participant "NEF" as NEF
 participant "NGC CP Function" as 5GC
 
-box "OpenNESS Controller Components" #LightBlue
+box "Smart Edge Open Controller Components" #LightBlue
 	participant UI
     participant AF
 end box
@@ -28,7 +28,7 @@ end box
 box "5G Core Components" #LightGreen
 	participant NEF
     note over NEF 
-        OpenNESS provided 
+        Smart Edge Open provided 
         Core component with 
         limited functionality
     end note    
diff --git a/doc/reference-architectures/core-network/ngc_flows/PFD_Management_transaction_get.uml b/doc/reference-architectures/core-network/ngc_flows/PFD_Management_transaction_get.uml
index b521f8c1..989672d9 100644
--- a/doc/reference-architectures/core-network/ngc_flows/PFD_Management_transaction_get.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/PFD_Management_transaction_get.uml
@@ -21,7 +21,7 @@ participant "Af Microservice" as AF
 participant "NEF" as NEF
 participant "NGC CP Function" as 5GC
 
-box "OpenNESS Controller Components" #LightBlue
+box "Smart Edge Open Controller Components" #LightBlue
 	participant UI
     participant AF
 end box
@@ -29,7 +29,7 @@ end box
 box "5G Core Components" #LightGreen
 	participant NEF
     note over NEF 
-        OpenNESS provided 
+        Smart Edge Open provided 
         Core component with 
         limited functionality
     end note    
diff --git a/doc/reference-architectures/core-network/ngc_flows/PFD_Managment_transaction_add.uml b/doc/reference-architectures/core-network/ngc_flows/PFD_Managment_transaction_add.uml
index 3e279dbd..91ec2534 100644
--- a/doc/reference-architectures/core-network/ngc_flows/PFD_Managment_transaction_add.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/PFD_Managment_transaction_add.uml
@@ -21,7 +21,7 @@ participant "Af Microservice" as AF
 participant "NEF" as NEF
 participant "NGC CP Function" as 5GC
 
-box "OpenNESS Controller Components" #LightBlue
+box "Smart Edge Open Controller Components" #LightBlue
 	participant UI
     participant AF
 end box
@@ -29,7 +29,7 @@ end box
 box "5G Core Components" #LightGreen
 	participant NEF
     note over NEF 
-        OpenNESS provided 
+        Smart Edge Open provided 
         Core component with 
         limited functionality
     end note    
diff --git a/doc/reference-architectures/core-network/ngc_flows/PFD_management_transaction_update.uml b/doc/reference-architectures/core-network/ngc_flows/PFD_management_transaction_update.uml
index 31d0cc4a..df123ad3 100644
--- a/doc/reference-architectures/core-network/ngc_flows/PFD_management_transaction_update.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/PFD_management_transaction_update.uml
@@ -20,7 +20,7 @@ participant "Af Microservice" as AF
 participant "NEF" as NEF
 participant "NGC CP Function" as 5GC
 
-box "OpenNESS Controller Components" #LightBlue
+box "Smart Edge Open Controller Components" #LightBlue
 	participant UI
     participant AF
 end box
@@ -28,7 +28,7 @@ end box
 box "5G Core Components" #LightGreen
 	participant NEF
     note over NEF 
-        OpenNESS provided 
+        Smart Edge Open provided 
         Core component with 
         limited functionality
     end note    
diff --git a/doc/reference-architectures/core-network/ngc_flows/e2e_config_flow_for_5g_edge.uml b/doc/reference-architectures/core-network/ngc_flows/e2e_config_flow_for_5g_edge.uml
index 5ab7c1f0..6b17c304 100644
--- a/doc/reference-architectures/core-network/ngc_flows/e2e_config_flow_for_5g_edge.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/e2e_config_flow_for_5g_edge.uml
@@ -23,7 +23,7 @@ participant "NEF" as nef
 end box 
 
 box "Edge components" #LightBlue
-participant "OpenNESS\nAF" as af 
+participant "Smart Edge Open\nAF" as af 
 participant "OSS" as oss
 end box
 
diff --git a/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_add.uml b/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_add.uml
index 3c6543cd..40a8b244 100644
--- a/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_add.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_add.uml
@@ -12,16 +12,16 @@ skinparam sequenceArrowThickness 3
 
 header "Intel Corporation"
 footer "Proprietary and Confidential"
-title "NGC OAM flows between OpenNESS Controller and NGC Core OAM Component"
+title "NGC OAM flows between Smart Edge Open Controller and NGC Core OAM Component"
 
 actor "Admin" as user
-box  "OpenNESS Controller" #LightBlue
+box  "Smart Edge Open Controller" #LightBlue
 participant "UI/CLI" as cnca 
 end box
 box  "NGC component" #LightGreen
 participant "OAM"  as oam
 note over oam
-   OpenNESS provided component 
+   Smart Edge Open provided component 
    with REST based HTTP interface 
    (for reference)
 end note
@@ -35,7 +35,7 @@ group AF services registration with 5G Core
     cnca  -> oam  : /ngcoam/v1/af/services : POST \n {dnn, dnai, snssai, tac, dns-ip, upf-ip}
     activate oam
     oam -> oam : NGC_OAM_STUB()
-    oam -> ngccp : {Open: 3rd Party NGC integration with OpenNESS(oam)} 
+    oam -> ngccp : {Open: 3rd Party NGC integration with Smart Edge Open(oam)} 
     ngccp --> oam : 
     oam  --> cnca : OK : {afServiceId} \n ERROR: {400/500}
     deactivate oam
diff --git a/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_delete.uml b/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_delete.uml
index 40de449c..758c92a3 100644
--- a/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_delete.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_delete.uml
@@ -12,16 +12,16 @@ skinparam sequenceArrowThickness 3
 
 header "Intel Corporation"
 footer "Proprietary and Confidential"
-title "NGC OAM flows between OpenNESS Controller and NGC Core OAM Component"
+title "NGC OAM flows between Smart Edge Open Controller and NGC Core OAM Component"
 
 actor "Admin" as user
-box  "OpenNESS Controller" #LightBlue
+box  "Smart Edge Open Controller" #LightBlue
 participant "UI/CLI" as cnca 
 end box
 box  "NGC component" #LightGreen
 participant "OAM"  as oam
 note over oam
-   OpenNESS provided component 
+   Smart Edge Open provided component 
    with REST based HTTP interface 
    (for reference)
 end note
@@ -36,7 +36,7 @@ group AF services deregistration with 5G Core
     cnca -> oam : /ngcoam/v1/af/services/{afServiceId}: DELETE
     activate oam
     oam -> oam : NGC_OAM_STUB()
-    oam -> ngccp : {Open: 3rd Party NGC integration with OpenNESS(oam)} 
+    oam -> ngccp : {Open: 3rd Party NGC integration with Smart Edge Open(oam)} 
     ngccp --> oam : 
     oam --> cnca : OK \n ERROR: {400/500}
     deactivate oam
diff --git a/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_get.uml b/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_get.uml
index 577559b4..adaec227 100644
--- a/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_get.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_get.uml
@@ -12,16 +12,16 @@ skinparam sequenceArrowThickness 3
 
 header "Intel Corporation"
 footer "Proprietary and Confidential"
-title "NGC OAM flows between OpenNESS Controller and NGC Core OAM Component"
+title "NGC OAM flows between Smart Edge Open Controller and NGC Core OAM Component"
 
 actor "Admin" as user
-box  "OpenNESS Controller" #LightBlue
+box  "Smart Edge Open Controller" #LightBlue
 participant "UI/CLI" as cnca 
 end box
 box  "NGC component" #LightGreen
 participant "OAM"  as oam
 note over oam
-   OpenNESS provided component 
+   Smart Edge Open provided component 
    with REST based HTTP interface 
    (for reference)
 end note
@@ -35,7 +35,7 @@ group Get AF registered DNN services from NGC Core
     cnca -> oam : /ngcoam/v1/af/services/{afServiceId}: GET 
     activate oam
     oam -> oam : NGC_OAM_STUB()
-    oam -> ngccp : {Open: 3rd Party NGC integration with OpenNESS(oam)} 
+    oam -> ngccp : {Open: 3rd Party NGC integration with Smart Edge Open(oam)} 
     ngccp --> oam : 
     oam --> cnca :  OK : {dnn, dnai, snssai, tac, dnsIp, upfIp} \n ERROR: {400/500}
     deactivate oam
diff --git a/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_update.uml b/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_update.uml
index 0083a509..10bb4dbb 100644
--- a/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_update.uml
+++ b/doc/reference-architectures/core-network/ngc_flows/ngcoam_af_service_update.uml
@@ -12,16 +12,16 @@ skinparam sequenceArrowThickness 3
 
 header "Intel Corporation"
 footer "Proprietary and Confidential"
-title "NGC OAM flows between OpenNESS Controller and NGC Core OAM Component"
+title "NGC OAM flows between Smart Edge Open Controller and NGC Core OAM Component"
 
 actor "Admin" as user
-box  "OpenNESS Controller" #LightBlue
+box  "Smart Edge Open Controller" #LightBlue
 participant "UI/CLI" as cnca 
 end box
 box  "NGC component" #LightGreen
 participant "OAM"  as oam
 note over oam
-   OpenNESS provided component 
+   Smart Edge Open provided component 
    with REST based HTTP interface 
    (for reference)
 end note
@@ -36,7 +36,7 @@ group Update DNS config values for DNN served by Edge DNN
     cnca -> oam : /ngcoam/v1/af/services/{afServiceId} : PATCH \n {dnn, dnai, snssai, tac, dns-ip, upf-ip} 
     activate oam 
     oam -> oam : NGC_OAM_STUB()
-    oam -> ngccp : {Open: 3rd Party NGC integration with OpenNESS(oam)} 
+    oam -> ngccp : {Open: 3rd Party NGC integration with Smart Edge Open(oam)} 
     ngccp --> oam : 
     oam --> cnca :  OK \n ERROR: {400/500}
     deactivate oam
diff --git a/doc/reference-architectures/core-network/openness-core.png b/doc/reference-architectures/core-network/smartedge-open-core.png
similarity index 100%
rename from doc/reference-architectures/core-network/openness-core.png
rename to doc/reference-architectures/core-network/smartedge-open-core.png
diff --git a/doc/reference-architectures/core-network/openness_epc.md b/doc/reference-architectures/core-network/smartedge-open_epc.md
similarity index 78%
rename from doc/reference-architectures/core-network/openness_epc.md
rename to doc/reference-architectures/core-network/smartedge-open_epc.md
index f9ed1441..78b42910 100644
--- a/doc/reference-architectures/core-network/openness_epc.md
+++ b/doc/reference-architectures/core-network/smartedge-open_epc.md
@@ -9,10 +9,10 @@ Copyright (c) 2019-2020 Intel Corporation
 - [Introduction](#introduction)
 - [4G LTE CUPS architectural aspects](#4g-lte-cups-architectural-aspects)
 - [Integration with Edge Platform](#integration-with-edge-platform)
-  - [Open Network Edge Services Software (OpenNESS)](#open-network-edge-services-software-openness)
+  - [Open Network Edge Services Software (Smart Edge Open)](#open-network-edge-services-software-smart-edge-open)
   - [EPC Deployment Models and Integration with Edge Platforms](#epc-deployment-models-and-integration-with-edge-platforms)
-  - [OpenNESS implementation](#openness-implementation)
-  - [OpenNESS API flows for CUPS integration](#openness-api-flows-for-cups-integration)
+  - [Smart Edge Open implementation](#smart-edge-open-implementation)
+  - [Smart Edge Open API flows for CUPS integration](#smart-edge-open-api-flows-for-cups-integration)
   - [API schema for the Core Network Configuration Agent (CNCA) Endpoint](#api-schema-for-the-core-network-configuration-agent-cnca-endpoint)
   - [Additional Recommended Semantics for Core Network Configuration Agent (CNCA) API](#additional-recommended-semantics-for-core-network-configuration-agent-cnca-api)
 - [Validation and Data path models](#validation-and-data-path-models)
@@ -26,7 +26,7 @@ Copyright (c) 2019-2020 Intel Corporation
 
 ## Abstract
 
-One of the primary requirement for edge computing is allocation of edge computing resources for end users along with maintaining application services deployment flexibility for edge platform. An architecture enhancements in Long-Term Evolution (LTE) standards for Control and User Plane Separtion (CUPS) provides an effective means of achieving these goals. CUPS approach has been proven for edge deployemnts with commericial EPC solution partners on the Open Network Edge Services Software (OpenNESS) platform.  The interfaces required for CUPS integration and further implementation strategies for user plane selection and traffic steering towards edge applications are discussed in this paper.
+One of the primary requirement for edge computing is allocation of edge computing resources for end users along with maintaining application services deployment flexibility for edge platform. An architecture enhancements in Long-Term Evolution (LTE) standards for Control and User Plane Separtion (CUPS) provides an effective means of achieving these goals. CUPS approach has been proven for edge deployemnts with commericial EPC solution partners on the Open Network Edge Services Software (Smart Edge Open) platform.  The interfaces required for CUPS integration and further implementation strategies for user plane selection and traffic steering towards edge applications are discussed in this paper.
 
 ## Introduction
 
@@ -55,33 +55,33 @@ In CUPS, additional reference points (Sxa,  Sxb, and Sxc) between the correspond
 
 Thus, the strategy for integrating an edge platform with a CUPS network is to coordinate the configuration rules established in the EPC user plane functions with the deployment of edge platform applications, so that the user plane functions are co-located with the corresponding edge platform.
 
-The 3GPP standard describes multiple ways to select SGW-U and PGW-U during the UE initial attach or PDN connection establishment phases. The user has the flexibility to choose from multiple methods that best serve their Edge requirements. The implementation in OpenNESS presents a subset of those methods for a selection of user planes and for steering subscriber traffic to an appropriate user plane node (usually the closest), where the application data processing can be co-located with the gateway. The Access Point Name (APN) (or APN FQDN, per [3GPP_23003](<https://www.3gpp.org/DynaReport/23003.htm>)) can be used in the selection process of PGW-U. The selection of SGW-U can be based on the Traffic Area Code (TAC), which is based on the network topology and the current location of the subscriber.
+The 3GPP standard describes multiple ways to select SGW-U and PGW-U during the UE initial attach or PDN connection establishment phases. The user has the flexibility to choose from multiple methods that best serve their Edge requirements. The implementation in Smart Edge Open presents a subset of those methods for a selection of user planes and for steering subscriber traffic to an appropriate user plane node (usually the closest), where the application data processing can be co-located with the gateway. The Access Point Name (APN) (or APN FQDN, per [3GPP_23003](<https://www.3gpp.org/DynaReport/23003.htm>)) can be used in the selection process of PGW-U. The selection of SGW-U can be based on the Traffic Area Code (TAC), which is based on the network topology and the current location of the subscriber.
 
 ## Integration with Edge Platform
 
-The [previous section](#4G-LTE-CUPS-architectural-aspects) of this white paper described the networking environment in which an edge platform must be integrated. In this section, an integration with the OpenNESS edge computing platform is described.
+The [previous section](#4G-LTE-CUPS-architectural-aspects) of this white paper described the networking environment in which an edge platform must be integrated. In this section, an integration with the Smart Edge Open edge computing platform is described.
 
-### Open Network Edge Services Software (OpenNESS)
+### Open Network Edge Services Software (Smart Edge Open)
 
-OpenNESS is an open-source edge computing platform that enables Service Providers and Enterprises to deploy applications and services on a network edge. It is inspired by the edge computing architecture defined by the ETSI Multi-access Edge Computing (MEC) standards (e.g., [ETSI_MEC 003]), as well as the 5G network architecture ([3GPP_23501]).
+Smart Edge Open is an open-source edge computing platform that enables Service Providers and Enterprises to deploy applications and services on a network edge. It is inspired by the edge computing architecture defined by the ETSI Multi-access Edge Computing (MEC) standards (e.g., [ETSI_MEC 003]), as well as the 5G network architecture ([3GPP_23501]).
 
-OpenNESS is access network agnostic, as it provides an architecture that interoperates with LTE, 5G, WiFi\*, and wired networks. OpenNESS provides APIs that allow network orchestrators and edge computing controllers to configure routing policies uniformly.
+Smart Edge Open is access network agnostic, as it provides an architecture that interoperates with LTE, 5G, WiFi\*, and wired networks. Smart Edge Open provides APIs that allow network orchestrators and edge computing controllers to configure routing policies uniformly.
 
-Because it is an open-source platform, OpenNESS enables operators, Independant Software Vendors(ISVs), and OSVs to innovate with new technologies and services. Field trials may be run with platforms implemented via OpenNESS, or functionality from the OpenNESS platform may be imported into existing third-party products. Thus, OpenNESS is an attractive platform for investigating approaches to integration with a CUPS-based network. Refer to [OpenNESS documentation](https://www.openness.org/docs/doc/architecture) for more information on the OpenNESS platform.
+Because it is an open-source platform, Smart Edge Open enables operators, Independant Software Vendors(ISVs), and OSVs to innovate with new technologies and services. Field trials may be run with platforms implemented via Smart Edge Open, or functionality from the Smart Edge Open platform may be imported into existing third-party products. Thus, Smart Edge Open is an attractive platform for investigating approaches to integration with a CUPS-based network. Refer to [Smart Edge Open documentation](https://www.openness.org/docs/doc/architecture) for more information on the Smart Edge Open platform.
 
-Figure 1 shows the architecture of the OpenNESS platform. It consists of:
+Figure 1 shows the architecture of the Smart Edge Open platform. It consists of:
 
 - a Controller through which external orchestrators act on the system and which is used to manage edge platforms
 - one or more Edge Nodes, which host edge applications
 
-In general, many edge nodes are associated with a Controller. To accomplish performance objectives, such as latency minimization, the edge node should be "close" in the network to a PGW-U. In the OpenNESS platform, the Controller establishes the appropriate configuration rules in the EPC functions.
+In general, many edge nodes are associated with a Controller. To accomplish performance objectives, such as latency minimization, the edge node should be "close" in the network to a PGW-U. In the Smart Edge Open platform, the Controller establishes the appropriate configuration rules in the EPC functions.
 
-The functional elements of the OpenNESS platform interact with each other via service interfaces. Of these, certain interfaces, such as those that interact with the access network or with edge applications, are exposed as OpenAPI (i.e., RESTful) APIs.
+The functional elements of the Smart Edge Open platform interact with each other via service interfaces. Of these, certain interfaces, such as those that interact with the access network or with edge applications, are exposed as OpenAPI (i.e., RESTful) APIs.
 
-Refer to [OpenNESS documentation](https://www.openness.org/docs/doc/architecture) for a details of the architecture and the service interfaces.
+Refer to [Smart Edge Open documentation](https://www.openness.org/docs/doc/architecture) for a details of the architecture and the service interfaces.
 
-![OpenNESS Architecture overview](epc-images/Openness_highlevel.png)
-Figure 1 - Open Network Edge Services Software (OpenNESS) Architecture
+![Smart Edge Open Architecture overview](epc-images/smartedge-open_highlevel.png)
+Figure 1 - Open Network Edge Services Software (Smart Edge Open) Architecture
 
 ### EPC Deployment Models and Integration with Edge Platforms
 
@@ -91,48 +91,48 @@ To explore these alternatives, we will consider three different deployment model
 
 Figure 2 depicts the first, most decoupled model in which multiple SGW-Us are associated with a single PGW-U. The edge compute node is associated with the PGW-U, and the configurations of the multiple SGW-Us, the PGW-U, and the edge compute node must be coordinated so that the PGW-U is selected as a destination for the traffic from a particular UE. In this model, a network orchestration function configures the EPC elements and selects the edge node for the deployment of an edge application. In this model, the edge Controller function does not have visibility to the network.
 
-![3GPP CUPS model 1](epc-images/openness_epc1.png)
+![3GPP CUPS model 1](epc-images/smartedge-open_epc1.png)
 Figure 2 - Deployment Model 1: Separate S-GW, Co-located P-GW, and Edge Platform
 
 In the second deployment model, shown in Figure 3, the PGW-U is integrated into an edge infrastructure. This model implies that the PGW-U function runs as a bare metal server, a virutal machine(VM), or container implementation in the same host or rack as an edge node. The number of hops through the network for user plane traffic is reduced because it is now possible for the PGW-U function to be orchestrated by the same virtualization manager as the edge platform. However, to realize this economy, the control plane should expose an API by which the edge platform can configure it (e.g., by setting the forwarding, QoS, and DNS rules required by the SGW-U).
 
-![3GPP CUPS model 2](epc-images/openness_epc2.png)
+![3GPP CUPS model 2](epc-images/smartedge-open_epc2.png)
 Figure 3 - Deployment Model 2: Combined S-GW, P-GW, Separate Edge Platform
 
 In the third deployment model, shown in Figure 4, the SGW-U and PGW-U functions are integrated into the same platform as the edge node. This model looks like a single user plane gateway that also executes edge applications, which reduces latency and operational costs. The user plane functions may run in bare metal server, a VM, or containers managed by the edge platform virtualization manager. The control plane functions should expose an API by which the edge platform can configure it, as in the case of the second model.
 
-![3GPP CUPS model 3](epc-images/openness_epc3.png)
+![3GPP CUPS model 3](epc-images/smartedge-open_epc3.png)
 Figure 4 - Combined S-GW, P-GW, Co-located with Edge Platform
 
-### OpenNESS implementation
+### Smart Edge Open implementation
 
 An implementation of the third deployment model was created to demonstrate the approach of integrating userplane gateways with an edge platform. Its high-level architecture is depicted in Figure 5.
 
-The interacting functions in this architecture are the EPC Control Plane and the OpenNESS Controller.
+The interacting functions in this architecture are the EPC Control Plane and the Smart Edge Open Controller.
 
 The EPC Control Plane is a reference implementation of a 3GPP control plane. It exposes APIs for performing network configuration operations which can by used by the Core Network Configuration API (CNCA). Invocations of the EPC Control API's result in setting appropriate configuration rules in the LTE access network.
 
-The OpenNESS Controller is a reference implementation that maintains a representation of requested UE traffic steering configuration, and issues configuration commands via the new API developed as a part of this integration (the CNCA API).
+The Smart Edge Open Controller is a reference implementation that maintains a representation of requested UE traffic steering configuration, and issues configuration commands via the new API developed as a part of this integration (the CNCA API).
 
-The combined user plane functions must still be subject to control by the operators' OAM interfaces. Because there is no standard interface defined for this reference point currently, it is assumed that the OAM will be customizable to use the APIs exposed by the OpenNESS Controller.
+The combined user plane functions must still be subject to control by the operators' OAM interfaces. Because there is no standard interface defined for this reference point currently, it is assumed that the OAM will be customizable to use the APIs exposed by the Smart Edge Open Controller.
 
-![LTE CUPS Configuration](epc-images/openness_epcconfig.png)
+![LTE CUPS Configuration](epc-images/smartedge-open_epcconfig.png)
 
 Figure 5 - High-Level CUPS/EPC Configuration Flow
 
-### OpenNESS API flows for CUPS integration
+### Smart Edge Open API flows for CUPS integration
 
-The following sequence diagrams show the API communication between the Edge Controller, the LTE Control Plane functions, and the Edge Node. These sequence diagrams follow the reference implementation carried out with OpenNESS, and they assume the combined user plane configuration (Deployment model 3). However, corresponding flows can be visualized for the other deployment models.
+The following sequence diagrams show the API communication between the Edge Controller, the LTE Control Plane functions, and the Edge Node. These sequence diagrams follow the reference implementation carried out with Smart Edge Open, and they assume the combined user plane configuration (Deployment model 3). However, corresponding flows can be visualized for the other deployment models.
 
-![LTE CUPS Configuration Sequence diagram 1](epc-images/openness_epcupf_add.png)
+![LTE CUPS Configuration Sequence diagram 1](epc-images/smartedge-open_epcupf_add.png)
 
 Figure 6 - Adding a User Plane Configuration from Controller
 
-![LTE CUPS Configuration Sequence diagram 2](epc-images/openness_epcupf_get.png)
+![LTE CUPS Configuration Sequence diagram 2](epc-images/smartedge-open_epcupf_get.png)
 
 Figure 7 - Getting  a User Plane Configuration from Controller
 
-![LTE CUPS Configuration Sequence diagram 3](epc-images/openness_epcupf_del.png)
+![LTE CUPS Configuration Sequence diagram 3](epc-images/smartedge-open_epcupf_del.png)
 
 Figure 8 - Deleting a User Plane Configuration from Controller
 
@@ -152,7 +152,7 @@ patch: /userplanes/{id}
 delete: /userplanes/{id}
 ```
 
-![LTE CUPS Configuration Sequence diagram 3](epc-images/openness_epc_cnca_1.png)
+![LTE CUPS Configuration Sequence diagram 3](epc-images/smartedge-open_epc_cnca_1.png)
 
 Figure 9 - Parameters of Core Network Configuration Agent (CNCA) API
 
@@ -169,7 +169,7 @@ The above API parameters are grouped into three categories:
 The previous section describes the parameters of the API. For additional control over traffic routing, additional policies are recommended:
 
 - In addition to the APN (for PDN GW selection) and TAC (for S-GW selection), UE-level entitlements can be specified to refine the edge resources selected for a given flow. This is done from the Controller by specifying access control on edge compute resources.
-- Though the OpenNESS API refers to International Mobile Subscriber Identity (IMSI) to identify UE uniquely, UE tagging is left as an implementation decision because it may not be desirable to expose IMSI information outside of the operator’s environment scope (e.g., for security).
+- Though the Smart Edge Open API refers to International Mobile Subscriber Identity (IMSI) to identify UE uniquely, UE tagging is left as an implementation decision because it may not be desirable to expose IMSI information outside of the operator’s environment scope (e.g., for security).
 
 Application data filtering functionality for processing at the edge can be further implemented in the PDN Gateway data pipeline itself to reduce the overhead of data processing in the Edge compute node data plane. Indeed, many EPC solutions already support application-level packet filtering and steering based on 5-tuples through proprietary implementations, which can be leveraged and extended for edge solutions.
 
@@ -182,9 +182,9 @@ The reference implementation described in this white paper has been tested in a
 Figure 10 depicts this test. This flow is a basic session between an application front-end on a UE, and an application back-end on an edge node.
 
 - The UE indicates its desired APN, which reflects in the right PGW-U being selected. The network assigns the correct SGW-U based on the current TAC.
-- The Subscriber’s application data is processed at the edge application launched at the OpenNESS Edge compute node.
+- The Subscriber’s application data is processed at the edge application launched at the Smart Edge Open Edge compute node.
 
-![LTE CUPS Configuration test flow 1](epc-images/openness_epctest1.png)
+![LTE CUPS Configuration test flow 1](epc-images/smartedge-open_epctest1.png)
 
 Figure 10 - User Plane Routing between UE and Edge Application
 
@@ -193,10 +193,10 @@ Figure 10 - User Plane Routing between UE and Edge Application
 Figure 11 depicts this test. An example of this flow is a media stream from a web camera to a computer vision application on an edge node, which computes metadata from the media stream and forwards the metadata to the cloud.
 
 - The UE indicates its desired APN, which reflects in the right PGW-U being selected. The network assigns the correct SGW-U based on the current TAC.
-- The Subscriber’s application data is processed at the edge application launched at the OpenNESS Edge compute node.
+- The Subscriber’s application data is processed at the edge application launched at the Smart Edge Open Edge compute node.
 - The application output is sent back to the PDN/internet for further processing.
 
-![LTE CUPS Configuration test flow 2](epc-images/openness_epctest2.png)
+![LTE CUPS Configuration test flow 2](epc-images/smartedge-open_epctest2.png)
 
 Figure 11 - User Plane Routing UE - Edge Application - Internet
 
@@ -207,7 +207,7 @@ Figure 12 depicts this test. An example of this flow is a UE that attempts to us
 - The UE indicates its desired APN, which reflects in the right PGW-U being selected. The network assigns the correct SGW-U based on the current TAC.
 - The Subscriber’s application data is not configured for Edge location processing and is therefore forwarded to the PDN/internet.
 
-![LTE CUPS Configuration test flow 3](epc-images/openness_epctest3.png)
+![LTE CUPS Configuration test flow 3](epc-images/smartedge-open_epctest3.png)
 
 Figure 12 - User Plane Routing of Unauthenticated Traffic - UE to Internet
 
@@ -218,13 +218,13 @@ Figure 13 depicts this test. This is another default case where the UE matches n
 - The UE connects to a different User plane function because its location and/or APN configurations are different and are not in the Edge service location.
 - The Subscriber’s application data, therefore, uses a different UPF to reach the PDN.
 
-![LTE CUPS Configuration test flow 4](epc-images/openness_epctest4.png)
+![LTE CUPS Configuration test flow 4](epc-images/smartedge-open_epctest4.png)
 
 Figure 13 - User Plane Routing of non-Application Traffic - UE to Internet
 
 ## Summary
 
-This white paper describes an investigation of how an edge platform can be integrated in a LTE access network that supports CUPS. Such an integration is a key factor for achieving the performance goals of an edge platform. During the validation for illustrating this integration, EPC control plane was modified  to interact with Core Network Configuration Agent (CNCA) APIs from OpenNESS, through which an edge controller can configure the EPC. By doing this, a central control point (the Edge Controller) can coordinate the deployment of an edge application and the rules for steering UE data traffic to a specific edge application.
+This white paper describes an investigation of how an edge platform can be integrated in a LTE access network that supports CUPS. Such an integration is a key factor for achieving the performance goals of an edge platform. During the validation for illustrating this integration, EPC control plane was modified  to interact with Core Network Configuration Agent (CNCA) APIs from Smart Edge Open, through which an edge controller can configure the EPC. By doing this, a central control point (the Edge Controller) can coordinate the deployment of an edge application and the rules for steering UE data traffic to a specific edge application.
 
 Further validation of this architecture will be carried out with commercial EPC partners.
 
@@ -255,7 +255,7 @@ Further validation of this architecture will be carried out with commercial EPC
 - IMSI: International Mobile Subscriber Identity
 - JSON: JavaScript Object Notation
 - MEC: Multi-Access Edge Computing
-- OpenNESS: Open Network Edge Services Software
+- OpenNES: Open Network Edge Services Software
 - LTE: Long-Term Evolution
 - MCC: Mobile Country Code
 - MME: Mobility Management Entity
diff --git a/doc/reference-architectures/core-network/openness_ngc.md b/doc/reference-architectures/core-network/smartedge-open_ngc.md
similarity index 73%
rename from doc/reference-architectures/core-network/openness_ngc.md
rename to doc/reference-architectures/core-network/smartedge-open_ngc.md
index 7672c675..487f23f7 100644
--- a/doc/reference-architectures/core-network/openness_ngc.md
+++ b/doc/reference-architectures/core-network/smartedge-open_ngc.md
@@ -10,10 +10,10 @@ Copyright (c) 2019-2020 Intel Corporation
   - [Edge 5G Architecture view](#edge-5g-architecture-view)
     - [Edge deployment scenarios in 5G](#edge-deployment-scenarios-in-5g)
     - [Application Traffic steering in 5G towards Edge](#application-traffic-steering-in-5g-towards-edge)
-- [OpenNESS integration with 5G systems](#openness-integration-with-5g-systems)
-  - [OpenNESS scope](#openness-scope)
-  - [OpenNESS implementation](#openness-implementation)
-  - [OpenNESS functional elements](#openness-functional-elements)
+- [Smart Edge Open integration with 5G systems](#smart-edge-open-integration-with-5g-systems)
+  - [Smart Edge Open scope](#smart-edge-open-scope)
+  - [Smart Edge Open implementation](#smart-edge-open-implementation)
+  - [Smart Edge Open functional elements](#smart-edge-open-functional-elements)
     - [Application Function](#application-function)
       - [Traffic steering NB APIs](#traffic-steering-nb-apis)
       - [AF supported Traffic steering API (South bound)](#af-supported-traffic-steering-api-south-bound)
@@ -24,7 +24,7 @@ Copyright (c) 2019-2020 Intel Corporation
     - [OAM Interface](#oam-interface)
       - [Edge service registration](#edge-service-registration)
     - [Core Network Configuration Agent](#core-network-configuration-agent)
-    - [Security between OpenNess 5GC micro-services](#security-between-openness-5gc-micro-services)
+    - [Security between OpenNess 5GC micro-services](#security-between-smart-edge-open-5gc-micro-services)
       - [HTTPS support](#https-support)
       - [OAuth2 Support](#oauth2-support)
   - [REST based API flows](#rest-based-api-flows)
@@ -32,9 +32,9 @@ Copyright (c) 2019-2020 Intel Corporation
     - [AF-NEF interface for PFD Management](#af-nef-interface-for-pfd-management)
     - [OAM interface for edge service registration](#oam-interface-for-edge-service-registration)
       - [OAM API flows](#oam-api-flows)
-  - [5G End to End flows for Edge by OpenNESS](#5g-end-to-end-flows-for-edge-by-openness)
-  - [5G Edge Data paths supported by OpenNESS](#5g-edge-data-paths-supported-by-openness)
-- [5G Core Network functionality for OpenNESS integration](#5g-core-network-functionality-for-openness-integration)
+  - [5G End to End flows for Edge by Smart Edge Open](#5g-end-to-end-flows-for-edge-by-smart-edge-open)
+  - [5G Edge Data paths supported by Smart Edge Open](#5g-edge-data-paths-supported-by-smart-edge-open)
+- [5G Core Network functionality for Smart Edge Open integration](#5g-core-network-functionality-for-smart-edge-open-integration)
 - [Summary](#summary)
   - [References](#references)
   - [List of abbreviations](#list-of-abbreviations)
@@ -43,7 +43,7 @@ Copyright (c) 2019-2020 Intel Corporation
 
 The 3GPP Release 15 specification ([3GPP TS 23.501](<https://www.3gpp.org/DynaReport/23501.htm>)) introduced Edge Computing. Edge Compute is highlighted as a key deployment mechanism for delivering services to end users by placing applications closer to the user. Network and Enterprise operators are taking advantage of this advancement to provide edge services that are low-latency, user-centric, and secure.
 
-This white paper focuses on some key challenges for 5G Standalone (SA) mode edge deployments and outlines how OpenNESS helps to address them. The next version of this white paper will address the 5G Non-standalone (NSA) mode.
+This white paper focuses on some key challenges for 5G Standalone (SA) mode edge deployments and outlines how Smart Edge Open helps to address them. The next version of this white paper will address the 5G Non-standalone (NSA) mode.
 
 Two key challenges in edge deployments are:
 
@@ -53,7 +53,7 @@ Two key challenges in edge deployments are:
 2. **UE Traffic identification and steering within the UPF towards edge node interfaces**
     - The standard clearly outlines REST-based APIs for this purpose in 5G.
 
-OpenNESS provides REST-based reference APIs along with 3GPP standard traffic influencing APIs (using the Application Function) to address some of these major challenges in 5G edge deployments.
+Smart Edge Open provides REST-based reference APIs along with 3GPP standard traffic influencing APIs (using the Application Function) to address some of these major challenges in 5G edge deployments.
 
 # 5G Systems Architecture
 
@@ -71,7 +71,7 @@ As discussed in the ETSI White paper "MEC in 5G Networks" [ETSI_2018a](<https://
 
 - Multiple Local Data Networks connected to the UPF and traffic steering of selected data traffic for a PDU session towards a local data network interface in UPF are key enablers of 5g edge deployments.
 
-- Influencing the traffic steering rules in the UPF through external components like OpenNESS/MEC Controllers using an Application Function (AF) provides another level of flexibility for on-demand application deployments on edge nodes as described in [3GPP_23501](<https://www.3gpp.org/DynaReport/23501.htm>) Release 15 Sec. 5.6.7.
+- Influencing the traffic steering rules in the UPF through external components like Smart Edge Open/MEC Controllers using an Application Function (AF) provides another level of flexibility for on-demand application deployments on edge nodes as described in [3GPP_23501](<https://www.3gpp.org/DynaReport/23501.htm>) Release 15 Sec. 5.6.7.
 
 - Session and Service Connectivity (SSC) and Local Area Data Networks (LADN) play an important role in edge deployments.
 
@@ -100,21 +100,21 @@ The 3GPP standard provides multiple references for implementing the selection of
 
 The standard also defines a set of procedures in the Application Function (AF) to influence the traffic routing in the UPF as well as the selection of UPF to reach UE traffic on the local data network [[3GPP_23501](<https://www.3gpp.org/DynaReport/23501.htm>) Release 15 Sec. 5.6.7].
 
-# OpenNESS integration with 5G systems
+# Smart Edge Open integration with 5G systems
 
-As a reference software solution kit, OpenNESS addresses some of the key challenges in the 5G edge deployment scenarios referred to above through the Application Function (AF) microservice and REST-based APIs. The rest of the sections will focus on explaining about the components in OpenNESS, how they interact with each other,  supported REST-based APIs (to interact with the 5G NGC solution), and end-user APIs  (to integrate with orchestration and/or solutions).
+As a reference software solution kit, Smart Edge Open addresses some of the key challenges in the 5G edge deployment scenarios referred to above through the Application Function (AF) microservice and REST-based APIs. The rest of the sections will focus on explaining about the components in Smart Edge Open, how they interact with each other,  supported REST-based APIs (to interact with the 5G NGC solution), and end-user APIs  (to integrate with orchestration and/or solutions).
 
-## OpenNESS scope
+## Smart Edge Open scope
 
-In the context of 5G edge deployments, OpenNESS interacts with 5G NGC through the AF Network Function microservice as defined in the 3GPP standard SBI interface. Additionally, OpenNESS proposes a reference REST-based API endpoint (OAM interface) to configure the 5G Control Plane elements with the information about UPF deployed at the edge nodes. In most cases, 5G NGC solutions may have this configuration path implemented. In the scope of OpenNESS integration with the 5G Core, the OAM interface is a point of discussion based on the existing 5G core interface.
+In the context of 5G edge deployments, Smart Edge Open interacts with 5G NGC through the AF Network Function microservice as defined in the 3GPP standard SBI interface. Additionally, Smart Edge Open proposes a reference REST-based API endpoint (OAM interface) to configure the 5G Control Plane elements with the information about UPF deployed at the edge nodes. In most cases, 5G NGC solutions may have this configuration path implemented. In the scope of Smart Edge Open integration with the 5G Core, the OAM interface is a point of discussion based on the existing 5G core interface.
 
-## OpenNESS implementation
+## Smart Edge Open implementation
 
-The key challenges for Edge deployments in 5G networks have been outlined in the section [Introduction](#Introduction). OpenNESS tries to address them in compliance with the standards by:
+The key challenges for Edge deployments in 5G networks have been outlined in the section [Introduction](#Introduction). Smart Edge Open tries to address them in compliance with the standards by:
 
 1. UPF selection
 
-- For deployment scenarios #1 and #2, where the serving UPF and edge node are co-located with the RAN, proper UPF selection for UE is critical. If the 5G Core considers UE location and requesting DNN (i.e. TAC, DNN, DNAI, SNSSAI, SSC) in UPF selection, it would make the Edge deployment more efficient.  To enable this capability, OpenNESS proposes an OAM REST-based API interface to inform the 5G core about the UPF info (upf-ip, tac, dnn, dnai, snssai, dns-ip) co-located with edge node.
+- For deployment scenarios #1 and #2, where the serving UPF and edge node are co-located with the RAN, proper UPF selection for UE is critical. If the 5G Core considers UE location and requesting DNN (i.e. TAC, DNN, DNAI, SNSSAI, SSC) in UPF selection, it would make the Edge deployment more efficient.  To enable this capability, Smart Edge Open proposes an OAM REST-based API interface to inform the 5G core about the UPF info (upf-ip, tac, dnn, dnai, snssai, dns-ip) co-located with edge node.
 
 - In the case of an edge node deployed at regional centers (#3), the selection of the serving UPF is done by 5G Core (SMF). However, UE application traffic needs to be steered from the serving UPF to the UPF co-located at the edge node through an N9 interface. To achieve this, traffic influencing rules need to be pushed in both UPFs to identify proper N9 and N6 interfaces for the data traffic to reach applications deployed on the edge node.
 
@@ -123,20 +123,20 @@ The key challenges for Edge deployments in 5G networks have been outlined in the
 - The 5G standard exposes REST-based APIs defined through Network Exposure Function [3GPP TS 23.502-f30 Sec. 5.2.6] for the AF to configure
   - The traffic flow rules to identify the application traffic, ie. Packet Flow Descriptor (PFD)
   - Operations create/modify/delete and traffic influencing subscription APIs for steering application traffic towards edge node N6 interfaces and more.
-   OpenNESS AF will support these APIs in multiple phases, starting with traffic influencing subscription APIs in OpenNESS Rel 19.12.
+   Smart Edge Open AF will support these APIs in multiple phases, starting with traffic influencing subscription APIs in Smart Edge Open Rel 19.12.
 
 3. DNS service
 
 - For UE traffic to reach applications deployed at the edge, the DNS plays a major role. Resolving the DNS entry for applications running on Edge is always a topic for discussion with multiple options available and the choice is always influenced by the required deployment scenario.
 
-    Two immediate options are (1) Use the DNS server maintained by the Network operator (2) Use the DNS services provided by the OpenNESS edge node.
+    Two immediate options are (1) Use the DNS server maintained by the Network operator (2) Use the DNS services provided by the Smart Edge Open edge node.
     1. DNS server provided by the network operator
         - Pros: Central DNS server for multiple edge nodes hosting applications, one-stop-shop.
         - Cons: Challenging to keep the DNS records database up to date with the dynamic nature of application deployment at edge nodes.
 
-    2. DNS server provided by the OpenNESS edge node
+    2. DNS server provided by the Smart Edge Open edge node
         - Pros: Keeps DNS records up to date for applications deployed dynamically, supports DNS forwarding functionality for unresolved DNS queries. An ideal solution for single-edge node deployment scenarios.
-        - Cons: If a single UPF connects to multiple edge nodes, then some sort of daisy-chaining activity of the DNS server configuration within edge nodes is needed. Assigning an Edge Node DNS server IP to UEs is also a challenge in some implementations. Through the OAM reference APIs, OpenNESS proposes a path to configure the edge DNS server (associated with UPF) to the 5G core but may not be able to address all scenarios.
+        - Cons: If a single UPF connects to multiple edge nodes, then some sort of daisy-chaining activity of the DNS server configuration within edge nodes is needed. Assigning an Edge Node DNS server IP to UEs is also a challenge in some implementations. Through the OAM reference APIs, Smart Edge Open proposes a path to configure the edge DNS server (associated with UPF) to the 5G core but may not be able to address all scenarios.
 
 4. UE mobility
 
@@ -148,23 +148,23 @@ The key challenges for Edge deployments in 5G networks have been outlined in the
 
   Technical challenges aside, as Edge services are mostly location-based, the visualization of mobility might not be applicable in all edge deployment scenarios.
 
-## OpenNESS functional elements
+## Smart Edge Open functional elements
 
-Below is a list of functional elements provided through the OpenNESS solution to address the key 5G integration challenges.
+Below is a list of functional elements provided through the Smart Edge Open solution to address the key 5G integration challenges.
 
-![5G OpenNESS Components](ngc-images/5g_openess_components.png)
+![5G Smart Edge Open Components](ngc-images/5g_openess_components.png)
 
-The following pictures show the microservice architectural view of the OpenNESS solution with 5G integration components:
+The following pictures show the microservice architectural view of the Smart Edge Open solution with 5G integration components:
 
-![5G OpenNESS Microservices](ngc-images/5g_openess_microservices.png)
+![5G Smart Edge Open Microservices](ngc-images/5g_openess_microservices.png)
 
 ### Application Function
 
-An Application Function (AF) is a microservice in the OpenNESS edge controller solution, and it is developed in golang. AF supports the Traffic influencing subscription and Packet Flow Description Management functionality to help steer the Edge-specific traffic in UPF towards the applications deployed on the OpenNESS edge node.
+An Application Function (AF) is a microservice in the Smart Edge Open edge controller solution, and it is developed in golang. AF supports the Traffic influencing subscription and Packet Flow Description Management functionality to help steer the Edge-specific traffic in UPF towards the applications deployed on the Smart Edge Open edge node.
 
-Other AF functionalities as discussed in 3GPP 5G standard [3GPP_29122], Changing chargeable party Section 4.4.4, configuration QoS for AF sessions Section 4.4.13, Monitoring Section 4.4.2, Device triggering Section 4.4.6, and resource management of Background Data Transfer (BDT) Section 4.4.3 are under consideration for future OpenNESS releases.
+Other AF functionalities as discussed in 3GPP 5G standard [3GPP_29122], Changing chargeable party Section 4.4.4, configuration QoS for AF sessions Section 4.4.13, Monitoring Section 4.4.2, Device triggering Section 4.4.6, and resource management of Background Data Transfer (BDT) Section 4.4.3 are under consideration for future Smart Edge Open releases.
 
-The OpenNESS AF microservice provides a northbound (NB) REST-based API interface for other microservices that provide a user interface (i.e., CNCA/UI or CLI). Also, these NB APIs can be invoked from external services that provide infrastructure for automation and/or orchestration.
+The Smart Edge Open AF microservice provides a northbound (NB) REST-based API interface for other microservices that provide a user interface (i.e., CNCA/UI or CLI). Also, these NB APIs can be invoked from external services that provide infrastructure for automation and/or orchestration.
 
 #### Traffic steering NB APIs
 
@@ -196,38 +196,38 @@ As part of the traffic subscription API exchange, SMF generated notifications re
 
 ### Network Exposure Function
 
-According to 3GPP 5G System Architecture [[3GPP_23501](<https://www.3gpp.org/DynaReport/23501.htm>) Release 15], NEF is a functional component in the 5G Core network. However, the reason for including NEF as a microservice in the OpenNESS solution is two-fold.
+According to 3GPP 5G System Architecture [[3GPP_23501](<https://www.3gpp.org/DynaReport/23501.htm>) Release 15], NEF is a functional component in the 5G Core network. However, the reason for including NEF as a microservice in the Smart Edge Open solution is two-fold.
 
-- For validation of AF functionality in OpenNESS before integrating with the 5G Core. This could enable OpenNESS partners to validate their interfaces before integrating with their 5G Core partner.  Hence, the NEF microservice scope in OpenNESS is limited and in line with the AF functional scope.
+- For validation of AF functionality in Smart Edge Open before integrating with the 5G Core. This could enable Smart Edge Open partners to validate their interfaces before integrating with their 5G Core partner.  Hence, the NEF microservice scope in Smart Edge Open is limited and in line with the AF functional scope.
 
-- It may be helpful for 5G Core partners who are looking for NEF service to be added in their solution for OpenNESS integration.
+- It may be helpful for 5G Core partners who are looking for NEF service to be added in their solution for Smart Edge Open integration.
 
-The OpenNESS provided NEF reference implementation for Traffic influence and PFD management is as per 3GPP TS 23.502 Section 5.2.6. Supported API endpoints are Nnef_TrafficInfluence {CREATE,UPDATE,DELETE} and Nnef_PfdManagement {CREATE, UPDATE, DELETE}.
+The Smart Edge Open provided NEF reference implementation for Traffic influence and PFD management is as per 3GPP TS 23.502 Section 5.2.6. Supported API endpoints are Nnef_TrafficInfluence {CREATE,UPDATE,DELETE} and Nnef_PfdManagement {CREATE, UPDATE, DELETE}.
 
 ### OAM Interface
 
-OAM agent functionality is another component that should be part of the 5G Core solution to add/update certain configuration information outside the scope of standards. For example, the Configuration of UPF parameters such as UPF IP address, DNS configuration, and DNNs are supported.  In the case of edge deployments, when the UPF is deployed as an NFV service on the edge node platform, MEC controllers may need to update the 5G Core control-plane components about the edge associated user-planes. 5G solutions may have some sort of interface to address this requirement. However, to provide a unified interface for integrated solutions, OpenNESS proposes REST-based OAM interface APIs to configure certain UPF related parameters. The use of the OAM agent is optional and can be replaced with an OAM interface of the 5G Core solution if any exists.
+OAM agent functionality is another component that should be part of the 5G Core solution to add/update certain configuration information outside the scope of standards. For example, the Configuration of UPF parameters such as UPF IP address, DNS configuration, and DNNs are supported.  In the case of edge deployments, when the UPF is deployed as an NFV service on the edge node platform, MEC controllers may need to update the 5G Core control-plane components about the edge associated user-planes. 5G solutions may have some sort of interface to address this requirement. However, to provide a unified interface for integrated solutions, Smart Edge Open proposes REST-based OAM interface APIs to configure certain UPF related parameters. The use of the OAM agent is optional and can be replaced with an OAM interface of the 5G Core solution if any exists.
 
 #### Edge service registration
 
-- OpenNESS suggested OAM API endpoint: _/ngcoam/v1/af/services_
+- Smart Edge Open suggested OAM API endpoint: _/ngcoam/v1/af/services_
 - Supported methods: POST, GET, PUT, DELETE
 
-**NOTE1**:  Because the OAM agent is a component in 5G Core and may need to interact with multiple AF instances (i.e., the OpenNESS edge controllers), the above API endpoint may need enhancements to incorporate `afId` to distinguish between AFs.  THE updated API endpoint could be _/ngcoam/v2/af/{afId}/services_, which is an interest for OpenNESS in future enhancements.
+**NOTE1**:  Because the OAM agent is a component in 5G Core and may need to interact with multiple AF instances (i.e., the Smart Edge Open edge controllers), the above API endpoint may need enhancements to incorporate `afId` to distinguish between AFs.  THE updated API endpoint could be _/ngcoam/v2/af/{afId}/services_, which is an interest for Smart Edge Open in future enhancements.
 
-**NOTE2**: Registration of AF instance (OpenNESS controller) with 5G Core network could also be a topic for discussion during implementation. Customers can choose the suggested 3GPP method using NRF functionality or the existing OAM functionality can be extended with an additional API (for example, _/ngcoam/v2/af/register_)  to register and obtain `afId` from 5G Core.
+**NOTE2**: Registration of AF instance (Smart Edge Open controller) with 5G Core network could also be a topic for discussion during implementation. Customers can choose the suggested 3GPP method using NRF functionality or the existing OAM functionality can be extended with an additional API (for example, _/ngcoam/v2/af/register_)  to register and obtain `afId` from 5G Core.
 
 ### Core Network Configuration Agent
 
-Core Network Configuration Agent (CNCA) is a microservice that provides an interface for end users of the OpenNESS controller to interact with the 5G Core network solution. CNCA provides a CLI (kube-ctl plugin) interface to interact with the AF and OAM services.
+Core Network Configuration Agent (CNCA) is a microservice that provides an interface for end users of the Smart Edge Open controller to interact with the 5G Core network solution. CNCA provides a CLI (kube-ctl plugin) interface to interact with the AF and OAM services.
 
 ### Security between OpenNess 5GC micro-services
 
-The security among OpenNESS 5GC microservices is supported through HTTPS and OAuth2.
+The security among Smart Edge Open 5GC microservices is supported through HTTPS and OAuth2.
 
 #### HTTPS support
 
-The OpenNESS 5GC microservices such as OAM, CNCA-UI, CLI kube-ctl, AF, and NEF communicate using REST API's over the HTTPS interface among them.
+The Smart Edge Open 5GC microservices such as OAM, CNCA-UI, CLI kube-ctl, AF, and NEF communicate using REST API's over the HTTPS interface among them.
 
 #### OAuth2 Support
 
@@ -241,7 +241,7 @@ The OAuth2 flow between AF and NEF is as shown in below diagram.
 
 ## REST based API flows
 
-The flow diagrams below depict the scenarios for the traffic influence subscription operations from an end user of OpenNESS controller towards 5G core.
+The flow diagrams below depict the scenarios for the traffic influence subscription operations from an end user of Smart Edge Open controller towards 5G core.
 
 ### AF-NEF interface for traffic influence
 
@@ -276,7 +276,7 @@ The flow diagrams below depict the scenarios for the traffic influence subscript
 #### OAM API flows
 
 As discussed above, the need for configuring the 5G Control plane components with the information about UPF DNN information related to the edge.  The flow diagrams below depict the API flow between various components to passdown the information towards 5G control plane.
-Detailed information about the OAM reference API endpoints can be found at 5G OAM API Schema in the documentation page at OpenNESS.org.
+Detailed information about the OAM reference API endpoints can be found at 5G OAM API Schema in the documentation page at Smart Edge Open.org.
 
 - Addition of UPF services info about Edge to 5G Control Plane:
 ![AF Service registration](ngc-images/oam_af_service_add.png)
@@ -290,7 +290,7 @@ Detailed information about the OAM reference API endpoints can be found at 5G OA
 - Delete UPF services info about Edge from 5G Control Plane:
 ![AF Service Delete](ngc-images/oam_af_service_del.png)
 
-## 5G End to End flows for Edge by OpenNESS
+## 5G End to End flows for Edge by Smart Edge Open
 
 The flow diagrams below depict a possible end-to-end edge deployment scenario including the PFD management, traffic influencing, and traffic routing in UPF towards Local DN.
 
@@ -310,20 +310,20 @@ The flow diagrams below depict a possible end-to-end edge deployment scenario in
   - When a new UPF is deployed in the 5G network or a new DN service is started on an existing UPF, SMF may generate a trigger to AF about the DNAI change notification.
 
 - Data path from UE
-  - Edge traffic sent by the UE reaches the UPF, the UPF routes the edge-traffic towards the local DN where the OpenNESS Edge Node is configured.
+  - Edge traffic sent by the UE reaches the UPF, the UPF routes the edge-traffic towards the local DN where the Smart Edge Open Edge Node is configured.
   - All other traffic sent by the UE that reaches the UPF will be sent to another UPF or to a remote gateway.
 
-## 5G Edge Data paths supported by OpenNESS
+## 5G Edge Data paths supported by Smart Edge Open
 
-The below picture shows multiple data paths that are supported in OpenNESS integrated edge deployment scenarios.
+The below picture shows multiple data paths that are supported in Smart Edge Open integrated edge deployment scenarios.
 
-![5G Edge Data path supported by OpenNESS](ngc-images/5g_edge_data_paths.png)
+![5G Edge Data path supported by Smart Edge Open](ngc-images/5g_edge_data_paths.png)
 
 Each data path/scenario is represented by a colored line, which is described below.
 
 All the UEs attached from Base Station gNB1 are assigned to UPF1 based on location (TAC) configuration. UEs that are attached from gNB2 are assigned to UPF1 or UPF2 based on TAC, DNN configuration while assigning UPF.
 
-**Green Colored data-path :**  UE application traffic that reaches UPF1 is routed to OpenNESS edge node through N6 interface.  Traffic is served by applications deployed at the Edge node.
+**Green Colored data-path :**  UE application traffic that reaches UPF1 is routed to Smart Edge Open edge node through N6 interface.  Traffic is served by applications deployed at the Edge node.
 
 **Orange colored data-path :** UE application traffic that reaches UPF1, but non-edge traffic will be routed towards cloud through another N6 interface.
 
@@ -333,9 +333,9 @@ All the UEs attached from Base Station gNB1 are assigned to UPF1 based on locati
 
 **NOTE** All the above mentioned data paths also applicable to other two deployment scenarios described in the section [Edge deployment scenarios in 5G](#edge-deployment-scenarios-in-5g).
 
-# 5G Core Network functionality for OpenNESS integration
+# 5G Core Network functionality for Smart Edge Open integration
 
-The following is the minimum functionality required to support the integration of the OpenNESS integrated MEC solution with a 5G Core network based on the required deployment scenarios:
+The following is the minimum functionality required to support the integration of the Smart Edge Open integrated MEC solution with a 5G Core network based on the required deployment scenarios:
 
 - Control and Configuration in UPF selection functionality. Required in the case of location-based edge node deployments with associated 5G user-plane.
 
@@ -345,9 +345,9 @@ The following is the minimum functionality required to support the integration o
 
 # Summary
 
-This white paper highlights the Edge computing enhancements made in the 3GPP 5G standards along with the key implementation challenges. This document provides a description of the OpenNESS view of integration for Edge controllers with the 5G Core Network as well as the API endpoints and end-to-end flows required in edge deployments. The OpenNESS reference implementation was validated with a modified 5G Core in SA mode to support the APIs for edge deployments (per the 3GPP 5G Standard) and the 5G UPF on the edge node with multiple N6 interfaces connected towards local DNN interface.
+This white paper highlights the Edge computing enhancements made in the 3GPP 5G standards along with the key implementation challenges. This document provides a description of the Smart Edge Open view of integration for Edge controllers with the 5G Core Network as well as the API endpoints and end-to-end flows required in edge deployments. The Smart Edge Open reference implementation was validated with a modified 5G Core in SA mode to support the APIs for edge deployments (per the 3GPP 5G Standard) and the 5G UPF on the edge node with multiple N6 interfaces connected towards local DNN interface.
 
-Along with discussing the supported features in OpenNESS for 5G integration, the areas of interest for future enhancements are also outlined.
+Along with discussing the supported features in Smart Edge Open for 5G integration, the areas of interest for future enhancements are also outlined.
 
 ## References
 
diff --git a/doc/reference-architectures/core-network/openness_upf.md b/doc/reference-architectures/core-network/smartedge-open_upf.md
similarity index 85%
rename from doc/reference-architectures/core-network/openness_upf.md
rename to doc/reference-architectures/core-network/smartedge-open_upf.md
index d5bd7076..05f33d80 100644
--- a/doc/reference-architectures/core-network/openness_upf.md
+++ b/doc/reference-architectures/core-network/smartedge-open_upf.md
@@ -12,9 +12,9 @@ Copyright (c) 2020 Intel Corporation
   - [Platform-specific information](#platform-specific-information)
   - [UPF application-specific information](#upf-application-specific-information)
 - [How to start](#how-to-start)
-  - [Deploy UPF pod from OpenNESS controller](#deploy-upf-pod-from-openness-controller)
+  - [Deploy UPF pod from Smart Edge Open controller](#deploy-upf-pod-from-smart-edge-open-controller)
   - [To start UPF](#to-start-upf)
-  - [Uninstall UPF pod from OpenNESS controller](#uninstall-upf-pod-from-openness-controller)
+  - [Uninstall UPF pod from Smart Edge Open controller](#uninstall-upf-pod-from-smart-edge-open-controller)
 - [List of abbreviations](#list-of-abbreviations)
 
 # Introduction
@@ -37,29 +37,29 @@ Defined in 3GPP technical specification [23.501](<https://www.3gpp.org/DynaRepor
 - Sending and forwarding of one or more "end marker(s)" to the source Next Generation-Radio Access Network(NG-RAN) node.
 - Functionality to respond to Address Resolution Protocol (ARP) requests and / or IPv6 Neighbor Solicitation requests based on local cache information for the Ethernet\* PDUs. The UPF responds to the ARP and / or the IPv6 Neighbor Solicitation Request by providing the Media Access Control(MAC) address corresponding to the IP address sent in the request.
 
-As part of the end-to-end integration of the Edge cloud deployment using OpenNESS, a reference 5G Core network is used along with reference RAN (FlexRAN). The diagram below shows the UPF and Next Generation Core(NGC) Control plane deployed on the OpenNESS platform along with the necessary microservice and Kubernetes\* (K8s) enhancements required for high throughput user plane workload deployment.
+As part of the end-to-end integration of the Edge cloud deployment using Smart Edge Open, a reference 5G Core network is used along with reference RAN (FlexRAN). The diagram below shows the UPF and Next Generation Core(NGC) Control plane deployed on the Smart Edge Open platform along with the necessary microservice and Kubernetes\* (K8s) enhancements required for high throughput user plane workload deployment.
 
-![UPF and NGC Control plane deployed on OpenNESS](openness-core.png)
+![UPF and NGC Control plane deployed on Smart Edge Open](smartedge-open-core.png)
 
->**NOTE**: The UPF source or binary is not released as part of OpenNESS.
+>**NOTE**: The UPF source or binary is not released as part of Smart Edge Open.
 
 # Purpose
 
-This document provides the required steps to deploy UPF on the OpenNESS platform. 4G/(Long Term Evolution network)LTE or 5G UPF can run as network functions on the Edge node in a virtualized environment.  The reference [Dockerfile](https://github.com/open-ness/edgeapps/blob/master/network-functions/core-network/5G/UPF/Dockerfile) and [5g-upf.yaml](https://github.com/open-ness/edgeapps/blob/master/network-functions/core-network/5G/UPF/5g-upf.yaml) provide details on how to deploy UPF as a Cloud-native network functions (CNF) in a K8s pod on OpenNESS edge node using OpenNESS Enhanced Platform Awareness (EPA) features.
+This document provides the required steps to deploy UPF on the Smart Edge Open platform. 4G/(Long Term Evolution network)LTE or 5G UPF can run as network functions on the Edge node in a virtualized environment.  The reference [Dockerfile](https://github.com/smart-edge-open/edgeapps/blob/master/network-functions/core-network/5G/UPF/Dockerfile) and [5g-upf.yaml](https://github.com/smart-edge-open/edgeapps/blob/master/network-functions/core-network/5G/UPF/5g-upf.yaml) provide details on how to deploy UPF as a Cloud-native network functions (CNF) in a K8s pod on Smart Edge Open edge node using Smart Edge Open Enhanced Platform Awareness (EPA) features.
 
-These scripts are validated through a reference UPF solution (implementation is based on Vector Packet Processing (VPP)) that is not part of the OpenNESS release.
+These scripts are validated through a reference UPF solution (implementation is based on Vector Packet Processing (VPP)) that is not part of the Smart Edge Open release.
 
 >**NOTE**: The AF and NEF Dockerfile and pod specification can be found here:
 >
-> - AF - [dockerfile](https://github.com/open-ness/epcforedge/blob/master/ngc/build/networkedge/af/Dockerfile). [Pod Specification](https://github.com/open-ness/epcforedge/blob/master/ngc/scripts/networkedge/ngctest/podAF.yaml)
-> - NEF - [dockerfile](https://github.com/open-ness/epcforedge/blob/master/ngc/build/networkedge/nef/Dockerfile). [Pod Specification](https://github.com/open-ness/epcforedge/blob/master/ngc/scripts/networkedge/ngctest/podNEF.yaml)
-> - OAM - [dockerfile](https://github.com/open-ness/epcforedge/blob/master/ngc/build/networkedge/oam/Dockerfile). [Pod Specification](https://github.com/open-ness/epcforedge/blob/master/ngc/scripts/networkedge/ngctest/podOAM.yaml)
+> - AF - [dockerfile](https://github.com/smart-edge-open/epcforedge/blob/master/ngc/build/networkedge/af/Dockerfile). [Pod Specification](https://github.com/smart-edge-open/epcforedge/blob/master/ngc/scripts/networkedge/ngctest/podAF.yaml)
+> - NEF - [dockerfile](https://github.com/smart-edge-open/epcforedge/blob/master/ngc/build/networkedge/nef/Dockerfile). [Pod Specification](https://github.com/smart-edge-open/epcforedge/blob/master/ngc/scripts/networkedge/ngctest/podNEF.yaml)
+> - OAM - [dockerfile](https://github.com/smart-edge-open/epcforedge/blob/master/ngc/build/networkedge/oam/Dockerfile). [Pod Specification](https://github.com/smart-edge-open/epcforedge/blob/master/ngc/scripts/networkedge/ngctest/podOAM.yaml)
 
 # How to build
 
 1. To keep the build and deploy process straightforward, the Docker\* build and image are stored on the Edge node.
 
-2. Copy the upf binary package to the Docker build folder. Reference Docker files and the Helm chart for deploying the UPF is available at [edgeapps_upf_docker](https://github.com/open-ness/edgeapps/tree/master/network-functions/core-network/5G/UPF) and [edgeapps_upf_helmchart](https://github.com/open-ness/edgeapps/tree/master/network-functions/core-network/charts/upf) respectively
+2. Copy the upf binary package to the Docker build folder. Reference Docker files and the Helm chart for deploying the UPF is available at [edgeapps_upf_docker](https://github.com/smart-edge-open/edgeapps/tree/master/network-functions/core-network/5G/UPF) and [edgeapps_upf_helmchart](https://github.com/smart-edge-open/edgeapps/tree/master/network-functions/core-network/charts/upf) respectively
 
     ```bash
     ne-node# cp -rf <5g-upf-binary-package> edgeapps/network-functions/core-network/5G/UPF/upf
@@ -77,7 +77,7 @@ These scripts are validated through a reference UPF solution (implementation is
 
 # UPF configuration
 
-To keep the bring up setup simple, the UPF configuration can be provided through the Helm charts. A reference Helm chart is available at  [edgeapps_upf_helmchart](https://github.com/open-ness/edgeapps/tree/master/network-functions/core-network/charts/upf)
+To keep the bring up setup simple, the UPF configuration can be provided through the Helm charts. A reference Helm chart is available at  [edgeapps_upf_helmchart](https://github.com/smart-edge-open/edgeapps/tree/master/network-functions/core-network/charts/upf)
 
 Below is a list of minimal configuration parameters for VPP-based applications such as UPF.
 
@@ -93,7 +93,7 @@ Below is a list of minimal configuration parameters for VPP-based applications s
 
 # How to start
 
-1. Ensure that all EPA microservices and Enhancements (part of OpenNESS playbook) are deployed `kubectl get po --all-namespaces`. Also, ensure that `multus`, `sriov-cni`, and `sriov-device-plugin` pods are alive on the controller and node. The `interface service` pod should also be alive on the node.
+1. Ensure that all EPA microservices and Enhancements (part of Smart Edge Open playbook) are deployed `kubectl get po --all-namespaces`. Also, ensure that `multus`, `sriov-cni`, and `sriov-device-plugin` pods are alive on the controller and node. The `interface service` pod should also be alive on the node.
 
     ```bash
     ne-controller# kubectl get po --all-namespaces
@@ -278,9 +278,9 @@ Below is a list of minimal configuration parameters for VPP-based applications s
       "intel.com/intel_sriov_netdevice": "1",
     ```
 
-## Deploy UPF pod from OpenNESS controller
+## Deploy UPF pod from Smart Edge Open controller
 
-In this reference validation, UPF will be deployed using Helm charts. The reference Helm chart for UPF is available at [edgeapps_upf_helmchart](https://github.com/open-ness/edgeapps/tree/master/network-functions/core-network/charts/upf)
+In this reference validation, UPF will be deployed using Helm charts. The reference Helm chart for UPF is available at [edgeapps_upf_helmchart](https://github.com/smart-edge-open/edgeapps/tree/master/network-functions/core-network/charts/upf)
 
 helm install \<pod-name\> \<path to the upf helm chart\> \<list of configuration values\>
 
@@ -330,7 +330,7 @@ In this reference validation, the UPF application will be started manually after
     upf-cnf# sudo -E ./run_upf.sh
     ```
 
-## Uninstall UPF pod from OpenNESS controller
+## Uninstall UPF pod from Smart Edge Open controller
 
 In this reference validation, UPF can be deleted/uninstalled using the UPF Helm chart.
 
diff --git a/doc/reference-architectures/index.html b/doc/reference-architectures/index.html
index a1c1b84c..5c07a1af 100644
--- a/doc/reference-architectures/index.html
+++ b/doc/reference-architectures/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
 window.location = "core-network"
 </script>
diff --git a/index.html b/index.html
index fd9122d4..4205e853 100644
--- a/index.html
+++ b/index.html
@@ -4,11 +4,11 @@
 -->
 
 ---
-title: OpenNESS Documentation
+title: Smart Edge Open Documentation
 description: Home
-layout: openness
+layout: smartedge-open
 ---
-<p>You are being redirected to the OpenNESS Docs.</p>
+<p>You are being redirected to the Smart Edge Open Docs.</p>
 <script type="text/javascript">
 window.location = "doc/overview"
 </script>
diff --git a/js/custom.js b/js/custom.js
index bdeab05c..72d73cf6 100644
--- a/js/custom.js
+++ b/js/custom.js
@@ -34,7 +34,7 @@ jQuery(document).ready(function(){
             jQuery('.collapseArea').slideToggle();
     });
     jQuery('.nav-mobile').on('click', function(){
-            jQuery('.opennessmenu').slideToggle();
+            jQuery('.smartedge-openmenu').slideToggle();
     });
         
         
diff --git a/schema/5goam/5goam.swagger.json b/schema/5goam/5goam.swagger.json
index c0278b08..8362855d 100644
--- a/schema/5goam/5goam.swagger.json
+++ b/schema/5goam/5goam.swagger.json
@@ -5,7 +5,7 @@
     "title": "5G OAM Northbound API",
     "contact": {
       "name": "intel",
-      "url": "github.com/open-ness/epcedge",
+      "url": "github.com/smart-edge-open/epcedge",
       "email": "support@intel.com"
     },
     "license": {
diff --git a/schema/5goam/5goam.swagger.yaml b/schema/5goam/5goam.swagger.yaml
index 8da72063..2a3e1636 100644
--- a/schema/5goam/5goam.swagger.yaml
+++ b/schema/5goam/5goam.swagger.yaml
@@ -7,7 +7,7 @@ info:
   title: 5G OAM Northbound API
   contact:
     name: intel
-    url: github.com/open-ness/epcedge
+    url: github.com/smart-edge-open/epcedge
     email: support@intel.com
   license:
     name: Apache 2.0 License
diff --git a/schema/pb/auth.proto b/schema/pb/auth.proto
index b60d28fe..8284e769 100644
--- a/schema/pb/auth.proto
+++ b/schema/pb/auth.proto
@@ -4,7 +4,7 @@
 syntax = "proto3";
 
 package openness.auth;
-option go_package = "github.com/open-ness/schema;auth";
+option go_package = "github.com/smart-edge-open/schema;auth";
 
 import "google/api/annotations.proto";
 import "protoc-gen-swagger/options/annotations.proto";
diff --git a/schema/pb/cups.proto b/schema/pb/cups.proto
index bb8ea2e6..8549970a 100644
--- a/schema/pb/cups.proto
+++ b/schema/pb/cups.proto
@@ -4,7 +4,7 @@
 syntax = "proto3";
 
 package openness.cups;
-option go_package = "github.com/open-ness/cups;cups";
+option go_package = "github.com/smart-edge-open/cups;cups";
 
 import "google/protobuf/empty.proto";
 import "google/api/annotations.proto";
diff --git a/schema/pb/eaa.proto b/schema/pb/eaa.proto
index edaad841..65ce5657 100644
--- a/schema/pb/eaa.proto
+++ b/schema/pb/eaa.proto
@@ -4,7 +4,7 @@
 syntax = "proto3";
 
 package openness.eaa;
-option go_package = "github.com/open-ness/eaa;eaa";
+option go_package = "github.com/smart-edge-open/eaa;eaa";
 
 import "google/protobuf/empty.proto";
 import "google/api/annotations.proto";
diff --git a/schema/pb/eva.proto b/schema/pb/eva.proto
index 7dd8eee3..d27f76fb 100644
--- a/schema/pb/eva.proto
+++ b/schema/pb/eva.proto
@@ -4,7 +4,7 @@
 syntax = "proto3";
 
 package openness.eva;
-option go_package = "github.com/open-ness/eva";
+option go_package = "github.com/smart-edge-open/eva";
 
 import "google/protobuf/empty.proto";
 
diff --git a/openness_releasenotes.md b/smartedge-open_releasenotes.md
similarity index 73%
rename from openness_releasenotes.md
rename to smartedge-open_releasenotes.md
index bc66194b..364dcc08 100644
--- a/openness_releasenotes.md
+++ b/smartedge-open_releasenotes.md
@@ -4,66 +4,69 @@ Copyright (c) 2019-2021 Intel Corporation
 ```
 <!-- omit in toc -->
 # Release Notes
-This document provides high-level system features, issues, and limitations information for Open Network Edge Services Software (OpenNESS).
+This document provides high-level system features, issues, and limitations information for Open Network Edge Services Software (Smart Edge Open).
 - [Release history](#release-history)
-  - [OpenNESS - 19.06](#openness---1906)
-  - [OpenNESS - 19.09](#openness---1909)
-  - [OpenNESS - 19.12](#openness---1912)
-  - [OpenNESS - 20.03](#openness---2003)
-  - [OpenNESS - 20.06](#openness---2006)
-  - [OpenNESS - 20.09](#openness---2009)
-  - [OpenNESS - 20.12](#openness---2012)
-  - [OpenNESS - 21.03](#openness---2103)
-  - [OpenNESS - 21.03.01](#openness---210301)
-  - [OpenNESS - 21.03.02](#openness---210302)
-  - [OpenNESS - 21.03.03](#openness---210303)
+  - [Smart Edge Open - 19.06](#smart-edge-open---1906)
+  - [Smart Edge Open - 19.09](#smart-edge-open---1909)
+  - [Smart Edge Open - 19.12](#smart-edge-open---1912)
+  - [Smart Edge Open - 20.03](#smart-edge-open---2003)
+  - [Smart Edge Open - 20.06](#smart-edge-open---2006)
+  - [Smart Edge Open - 20.09](#smart-edge-open---2009)
+  - [Smart Edge Open - 20.12](#smart-edge-open---2012)
+  - [Smart Edge Open - 21.03](#smart-edge-open---2103)
+  - [Smart Edge Open - 21.03.01](#smart-edge-open---210301)
+  - [Smart Edge Open - 21.03.02](#smart-edge-open---210302)
+  - [Smart Edge Open - 21.03.03](#smart-edge-open---210303)
+  - [Smart Edge Open - 21.09](#smart-edge-open---2109)
 - [Changes to Existing Features](#changes-to-existing-features)
-  - [OpenNESS - 19.06](#openness---1906-1)
-  - [OpenNESS - 19.06.01](#openness---190601)
-  - [OpenNESS - 19.09](#openness---1909-1)
-  - [OpenNESS - 19.12](#openness---1912-1)
-  - [OpenNESS - 20.03](#openness---2003-1)
-  - [OpenNESS - 20.06](#openness---2006-1)
-  - [OpenNESS - 20.09](#openness---2009-1)
-  - [OpenNESS - 20.12](#openness---2012-1)
-  - [OpenNESS - 21.03](#openness---2103-1)
+  - [Smart Edge Open - 19.06](#smart-edge-open---1906-1)
+  - [Smart Edge Open - 19.06.01](#smart-edge-open---190601)
+  - [Smart Edge Open - 19.09](#smart-edge-open---1909-1)
+  - [Smart Edge Open - 19.12](#smart-edge-open---1912-1)
+  - [Smart Edge Open - 20.03](#smart-edge-open---2003-1)
+  - [Smart Edge Open - 20.06](#smart-edge-open---2006-1)
+  - [Smart Edge Open - 20.09](#smart-edge-open---2009-1)
+  - [Smart Edge Open - 20.12](#smart-edge-open---2012-1)
+  - [Smart Edge Open - 21.03](#smart-edge-open---2103-1)
+  - [Smart Edge Open - 21.09](#smart-edge-open---2109-1)
 - [Fixed Issues](#fixed-issues)
-  - [OpenNESS - 19.06](#openness---1906-2)
-  - [OpenNESS - 19.06.01](#openness---190601-1)
-  - [OpenNESS - 19.06.01](#openness---190601-2)
-  - [OpenNESS - 19.12](#openness---1912-2)
-  - [OpenNESS - 20.03](#openness---2003-2)
-  - [OpenNESS - 20.06](#openness---2006-2)
-  - [OpenNESS - 20.09](#openness---2009-2)
-  - [OpenNESS - 20.12](#openness---2012-2)
-  - [OpenNESS - 20.12.02](#openness---201202)
-  - [OpenNESS - 21.03](#openness---2103-2)
-  - [OpenNESS - 21.03.01](#openness---210301-1)
-  - [OpenNESS - 21.03.02](#openness---210302-1)
-  - [OpenNESS - 21.03.03](#openness---210303-1)
+  - [Smart Edge Open - 19.06](#smart-edge-open---1906-2)
+  - [Smart Edge Open - 19.06.01](#smart-edge-open---190601-1)
+  - [Smart Edge Open - 19.06.01](#smart-edge-open---190601-2)
+  - [Smart Edge Open - 19.12](#smart-edge-open---1912-2)
+  - [Smart Edge Open - 20.03](#smart-edge-open---2003-2)
+  - [Smart Edge Open - 20.06](#smart-edge-open---2006-2)
+  - [Smart Edge Open - 20.09](#smart-edge-open---2009-2)
+  - [Smart Edge Open - 20.12](#smart-edge-open---2012-2)
+  - [Smart Edge Open - 20.12.02](#smart-edge-open---201202)
+  - [Smart Edge Open - 21.03](#smart-edge-open---2103-2)
+  - [Smart Edge Open - 21.03.01](#smart-edge-open---210301-1)
+  - [Smart Edge Open - 21.03.02](#smart-edge-open---210302-1)
+  - [Smart Edge Open - 21.03.03](#smart-edge-open---210303-1)
+  - [Smart Edge Open - 21.09](#smart-edge-open---2109-2)
 - [Known Issues and Limitations](#known-issues-and-limitations)
-  - [OpenNESS - 19.06](#openness---1906-3)
-  - [OpenNESS - 19.06.01](#openness---190601-3)
-  - [OpenNESS - 19.09](#openness---1909-2)
-  - [OpenNESS - 19.12](#openness---1912-3)
-  - [OpenNESS - 20.03](#openness---2003-3)
-  - [OpenNESS - 20.06](#openness---2006-3)
-  - [OpenNESS - 20.09](#openness---2009-3)
-  - [OpenNESS - 20.12](#openness---2012-3)
-  - [OpenNESS - 20.12.02](#openness---201202-1)
-  - [OpenNESS - 21.03](#openness---2103-3)
-  - [OpenNESS - 21.03.02](#openness---210302-2)
+  - [Smart Edge Open - 19.06](#smart-edge-open---1906-3)
+  - [Smart Edge Open - 19.06.01](#smart-edge-open---190601-3)
+  - [Smart Edge Open - 19.09](#smart-edge-open---1909-2)
+  - [Smart Edge Open - 19.12](#smart-edge-open---1912-3)
+  - [Smart Edge Open - 20.03](#smart-edge-open---2003-3)
+  - [Smart Edge Open - 20.06](#smart-edge-open---2006-3)
+  - [Smart Edge Open - 20.09](#smart-edge-open---2009-3)
+  - [Smart Edge Open - 20.12](#smart-edge-open---2012-3)
+  - [Smart Edge Open - 20.12.02](#smart-edge-open---201202-1)
+  - [Smart Edge Open - 21.03](#smart-edge-open---2103-3)
+  - [Smart Edge Open - 21.03.02](#smart-edge-open---210302-2)
 - [Release Content](#release-content)
-  - [OpenNESS - 19.06](#openness---1906-4)
-  - [OpenNESS - 19.06.01](#openness---190601-4)
-  - [OpenNESS - 19.09](#openness---1909-3)
-  - [OpenNESS - 19.12](#openness---1912-4)
-  - [OpenNESS - 20.03](#openness---2003-4)
-  - [OpenNESS - 20.06](#openness---2006-4)
-  - [OpenNESS - 20.09](#openness---2009-4)
-  - [OpenNESS - 20.12](#openness---2012-4)
-  - [OpenNESS - 20.12.02](#openness---201202-2)
-  - [OpenNESS - 21.03](#openness---2103-4)
+  - [Smart Edge Open - 19.06](#smart-edge-open---1906-4)
+  - [Smart Edge Open - 19.06.01](#smart-edge-open---190601-4)
+  - [Smart Edge Open - 19.09](#smart-edge-open---1909-3)
+  - [Smart Edge Open - 19.12](#smart-edge-open---1912-4)
+  - [Smart Edge Open - 20.03](#smart-edge-open---2003-4)
+  - [Smart Edge Open - 20.06](#smart-edge-open---2006-4)
+  - [Smart Edge Open - 20.09](#smart-edge-open---2009-4)
+  - [Smart Edge Open - 20.12](#smart-edge-open---2012-4)
+  - [Smart Edge Open - 20.12.02](#smart-edge-open---201202-2)
+  - [Smart Edge Open - 21.03](#smart-edge-open---2103-4)
 - [Hardware and Software Compatibility](#hardware-and-software-compatibility)
   - [Intel® Xeon® D Processor](#intel-xeon-d-processor)
   - [2nd Generation Intel® Xeon® Scalable Processors](#2nd-generation-intel-xeon-scalable-processors)
@@ -73,20 +76,20 @@ This document provides high-level system features, issues, and limitations infor
 
 # Release history
 
-## OpenNESS - 19.06
+## Smart Edge Open - 19.06
 - Edge Cloud Deployment options
   - Controller-based deployment of Applications in Docker Containers/VM–using-Libvirt
   - Controller + Kubernetes\* based deployment of Applications in Docker\* Containers
-- OpenNESS Controller
+- Smart Edge Open Controller
   - Support for Edge Node Orchestration
   - Support for Web UI front end
-- OpenNESS APIs
+- Smart Edge Open APIs
   - Edge Application APIs
   - Edge Virtualization Infrastructure APIs
   - Edge Application life cycle APIs
   - Core Network Configuration APIs
   - Edge Application authentication APIs
-  - OpenNESS Controller APIs
+  - Smart Edge Open Controller APIs
 - Platform Features
   - Microservices based Appliance and Controller agent deployment
   - Support for DNS for the edge
@@ -99,45 +102,45 @@ This document provides high-level system features, issues, and limitations infor
   - DPDK/KNI based Dataplane – NTS
   - Support for deployment on IP, LTE (S1, SGi and LTE CUPS)
 - Cloud Adapters
-  - Support for running Amazon\* Greengrass\* cores as an OpenNESS application
-  - Support for running Baidu\* Cloud as an OpenNESS application
+  - Support for running Amazon\* Greengrass\* cores as an Smart Edge Open application
+  - Support for running Baidu\* Cloud as an Smart Edge Open application
 - Documentation
   - User Guide Enterprise and Operator Edge
-  - OpenNESS Architecture
+  - Smart Edge Open Architecture
   - Swagger/Proto buff  External API Guide
   - 4G/CUPS API whitepaper
   - Cloud Connector App note
-  - OpenVINO™ on OpenNESS App note
+  - OpenVINO™ on Smart Edge Open App note
 
-## OpenNESS - 19.09
+## Smart Edge Open - 19.09
 - Edge Cloud Deployment options
   - Async method for image download to avoid timeout.
 - Dataplane
   - Support for OVN/OVS based Dataplane and network overlay for Network Edge (based on Kubernetes)
 - Cloud Adapters
-  - Support for running Amazon Green grass cores as an OpenNESS application with OVN/OVS as Dataplane and network overlay
+  - Support for running Amazon Green grass cores as an Smart Edge Open application with OVN/OVS as Dataplane and network overlay
 - Support for Inter-App comms
   - Support for OVS-DPDK or Linux\* bridge or Default interface for inter-Apps communication for OnPrem deployment
 - Accelerator support
   - Support for HDDL-R accelerator for interference in a container environment for OnPrem deployment
 - Edge Applications
-  - Early Access Support for Open Visual Cloud (OVC) based Smart City App on OpenNESS OnPrem
+  - Early Access Support for Open Visual Cloud (OVC) based Smart City App on Smart Edge Open OnPrem
   - Support for Dynamic use of VPU or CPU for Inferences
 - Gateway
-  - Support for Edge node and OpenNESS Controller gate way to support route-ability
+  - Support for Edge node and Smart Edge Open Controller gate way to support route-ability
 - Documentation
-  - OpenNESS Architecture (update)
-  - OpenNESS Support for OVS as dataplane with OVN
-  - Open Visual Cloud Smart City Application on OpenNESS - Solution Overview
-  - Using Intel® Movidius™ Myriad™ X High Density Deep Learning (HDDL) solution in OpenNESS
-  - OpenNESS How-to Guide (update)
+  - Smart Edge Open Architecture (update)
+  - Smart Edge Open Support for OVS as dataplane with OVN
+  - Open Visual Cloud Smart City Application on Smart Edge Open - Solution Overview
+  - Using Intel® Movidius™ Myriad™ X High Density Deep Learning (HDDL) solution in Smart Edge Open
+  - Smart Edge Open How-to Guide (update)
 
-## OpenNESS - 19.12
+## Smart Edge Open - 19.12
 - Hardware
   - Support for Cascade lake 6252N
   - Support for Intel® FPGA Programmable Acceleration Card (Intel® FPGA PAC) N3000
 - Edge Application
-  - Fully cloud native Open Visual Cloud Smart City Application pipeline on OpenNESS Network edge.
+  - Fully cloud native Open Visual Cloud Smart City Application pipeline on Smart Edge Open Network edge.
 - Edge cloud
   - EAA and CNCA microservice as native Kubernetes-managed services
   - Support for Kubernetes version 1.16.2
@@ -153,9 +156,9 @@ This document provides high-level system features, issues, and limitations infor
   - FPGA Remote System Update service: Support the Open Programmable Acceleration Engine (OPAE) (fpgautil) based image update service for FPGA
   - Non-Privileged Container: Support deployment of non-privileged pods (CNFs and Applications as reference)
 - Edge Compute EPA features support for On-Premises
-  - Using Intel® Movidius™ Myriad™ X High Density Deep Learning (HDDL) solution in OpenNESS
+  - Using Intel® Movidius™ Myriad™ X High Density Deep Learning (HDDL) solution in Smart Edge Open
 - Converged Edge Experience Kits for Network and OnPremises edge
-  - Offline Release Package: Customers should be able to create an installer package that can be used to install OnPremises version of OpenNESS without the need for Internet access.
+  - Offline Release Package: Customers should be able to create an installer package that can be used to install OnPremises version of Smart Edge Open without the need for Internet access.
 - 5G NR Edge Cloud deployment support
   - 5G NR edge cloud deployment support with SA mode
   - AF: Support for 5G NGC Application function as a microservice
@@ -169,7 +172,7 @@ This document provides high-level system features, issues, and limitations infor
   - 5G NR Edge Cloud deployment Whitepaper
   - EPA application note for each of the features
 
-## OpenNESS - 20.03
+## Smart Edge Open - 20.03
 - OVN/OVS-DPDK support for dataplane
   - Network Edge: Support for kube-ovn CNI with OVS or OVS-DPDK as dataplane. Support for Calico as CNI.
   - OnPremises Edge: Support for OVS-DPDK CNI with OVS-DPDK as dataplane supporting application deployed in containers or VMs
@@ -203,13 +206,13 @@ This document provides high-level system features, issues, and limitations infor
   - NEF: Dockerfile and pod specification
   - UPF: Dockerfile and pod specification
 
-## OpenNESS - 20.06
-- OpenNESS is now available in two distributions
+## Smart Edge Open - 20.06
+- Smart Edge Open is now available in two distributions
   - Open source (Apache 2.0 license)
-  - Intel Distribution of OpenNESS (Intel Proprietary License)
+  - Intel Distribution of Smart Edge Open (Intel Proprietary License)
     - Includes all the code from the open source distribution plus additional features and enhancements to improve the user experience
-    - Access requires a signed license. A request for access can be made at openness.org by navigating to the "Products" section and selecting "Intel Distribution of OpenNESS"
-  - Both distributions are hosted at github.com/open-ness
+    - Access requires a signed license. A request for access can be made at smartedge-open.org by navigating to the "Products" section and selecting "Intel Distribution of Smart Edge Open"
+  - Both distributions are hosted at github.com/smart-edge-open
 - On premises configuration now optionally supports Kubernetes
 - Dataplane
   - Support for Calico eBPF as CNI
@@ -241,9 +244,9 @@ This document provides high-level system features, issues, and limitations infor
   - Media Analytics with VCAC-A and with CPU only mode
   - CDN - Transcode
   - CDN - Content Delivery
-  - Azure - Deployment of OpenNESS cluster on Microsoft\* Azure\* cloud
-- Support for OpenNESS on CSP Cloud
-  - Azure - Deployment of OpenNESS cluster on Microsoft\* Azure\* cloud
+  - Azure - Deployment of Smart Edge Open cluster on Microsoft\* Azure\* cloud
+- Support for Smart Edge Open on CSP Cloud
+  - Azure - Deployment of Smart Edge Open cluster on Microsoft\* Azure\* cloud
 - Telemetry Support
   - Support for Collectd backend with hardware from Intel and custom metrics
   - cpu, cpufreq, load, hugepages, intel_pmu, intel_rdt, ipmi, ovs_stats, ovs_pmd_stats
@@ -254,33 +257,33 @@ This document provides high-level system features, issues, and limitations infor
   - Telemetry Aware Scheduler
 - Early Access support for Resource Management Daemon (RMD)
   - RMD for cache allocation to the application Pods
-- Ability to deploy OpenNESS Master and Node on the same platform
+- Ability to deploy Smart Edge Open Master and Node on the same platform
 
-## OpenNESS - 20.09
+## Smart Edge Open - 20.09
 - Native On-premises mode
   - Following from the previous release decision of pausing Native on-premises Development the code has been move to a dedicated repository “native-on-prem”
   - Kubernetes based solution will now support both Network and on-premises Edge
 - Service Mesh support
-  - Basic support for Service Mesh using Istio Service Mesh within an OpenNESS cluster.
+  - Basic support for Service Mesh using Istio Service Mesh within an Smart Edge Open cluster.
     > **NOTE**: When deploying Istio Service Mesh in VMs, a minimum of 8 CPU core and 16GB RAM must be allocated to each worker VM so that Istio operates smoothly
-  - Application of Service Mesh openness 5G and Media analytics - A dedicated network for service to service communications
+  - Application of Service Mesh smartedge-open 5G and Media analytics - A dedicated network for service to service communications
 - EAA Update
   - EAA microservices has been updated to be more cloud-native friendly
 - Edge Insights Application (update)
   - Industrial Edge Insights Software update to version 2.3.
   - Experience Kit now supports multiple detection video's – Safety equipment detection, PCB default detection and also supports external video streams.
 
-## OpenNESS - 20.12
-- Early access release of Edge Multi-Cluster Orchestration(EMCO), a Geo-distributed application orchestrator for Kubernetes. This release supports EMCO deploying and managing the life cycle of the Smart City Application pipeline on the edge cluster. More details in the [EMCO Release Notes](https://github.com/open-ness/EMCO/blob/main/ReleaseNotes.md).
-- Reference implementation of the offline installation package for the Converged Edge Reference Architecture (CERA) Access Edge flavor enabling installation of Kubernetes and related enhancements for Access edge deployments.
-- Azure Development kit (Devkit) supporting the installation of an OpenNESS Kubernetes cluster on the Microsoft* Azure* cloud. This is typically used by a customer who wants to develop applications and services for the edge using OpenNESS building blocks.
+## Smart Edge Open - 20.12
+- Early access release of Edge Multi-Cluster Orchestration(EMCO), a Geo-distributed application orchestrator for Kubernetes. This release supports EMCO deploying and managing the life cycle of the Smart City Application pipeline on the edge cluster. More details in the [EMCO Release Notes](https://github.com/smart-edge-open/EMCO/blob/main/ReleaseNotes.md).
+- Reference implementation of the offline installation package for the Converged Edge Reference Architecture (Smart Edge Open Experience Kit) Access Edge flavor enabling installation of Kubernetes and related enhancements for Access edge deployments.
+- Azure Development kit (Devkit) supporting the installation of an Smart Edge Open Kubernetes cluster on the Microsoft* Azure* cloud. This is typically used by a customer who wants to develop applications and services for the edge using Smart Edge Open building blocks.
 - Support Intel® vRAN Dedicated Accelerator ACC100, Kubernetes Cloud-native deployment supporting higher capacity 4G/LTE and 5G vRANs cells/carriers for FEC offload.
 - Major system Upgrades: Kubernetes 1.19.3, CentOS 7.8, Calico 3.16, and Kube-OVN 1.5.2.
 
-## OpenNESS - 21.03
+## Smart Edge Open - 21.03
 - Edge Insights for Industrial updated to 2.4
 - Support for Intel® Ethernet Controller E810 
-- Improvements to Converged Edge Reference Architecture framework including support for deploying one or more OpenNESS Kubernetes clusters 
+- Improvements to Converged Edge Reference Architecture framework including support for deploying one or more Smart Edge Open Kubernetes clusters 
 - OpenVINO upgraded to  2021.1.110
 - Major system upgrades: CentOS 7.9, Kubernetes 1.20.0, Docker 20.10.2, QEMU 5.2 and Golang 1.16.
 - Kubernetes CNI upgrades: Calico 3.17, SR-IOV CNI 2.6, Flannel 0.13.0.
@@ -288,64 +291,71 @@ This document provides high-level system features, issues, and limitations infor
 - Set Calico as a default cni for cdn-transcode, central_orchestrator, core-cplane, core-uplane, media-analytics and minimal flavor.
 - Intel CMK is replaced with Kubernetes native CPU manager for core resource allocation
 
-## OpenNESS - 21.03.01
+## Smart Edge Open - 21.03.01
 - Resolved an intermittent issue with Kubernetes repository signature verification
 
-## OpenNESS - 21.03.02
+## Smart Edge Open - 21.03.02
 - Kubernetes deployment support for Intel® QuickAssist Technology (Intel® QAT)
 - Provided an option to use CGroupFS as a CGroup driver for Kubernetes and Docker
 - EII upgraded from 2.4 to 2.4.1
 - VCA package upgraded from R5 to R5.1
 
-## OpenNESS - 21.03.03
+## Smart Edge Open - 21.03.03
 - Changed the CNI used for Azure cloud deployment from default Calico to Azure-supported kube-ovn.
+## Smart Edge Open - 21.09
+
+- No new features updates
+- Intel Edge Software Hub Reference implementation updated and revalidated to working with Smart Edge Open - 21.09.
 
 # Changes to Existing Features
 
-## OpenNESS - 19.06
+## Smart Edge Open - 19.06
 There are no unsupported or discontinued features relevant to this release.
 
-## OpenNESS - 19.06.01
+## Smart Edge Open - 19.06.01
 There are no unsupported or discontinued features relevant to this release.
 
-## OpenNESS - 19.09
+## Smart Edge Open - 19.09
 There are no unsupported or discontinued features relevant to this release.
 
-## OpenNESS - 19.12
+## Smart Edge Open - 19.12
 - NTS Dataplane support for Network edge is discontinued.
 - Controller UI for Network edge has been discontinued except for the CNCA configuration. Customers can optionally leverage the Kubernetes dashboard to onboard applications.
 - Edge node only supports non-realtime kernel.
 
-## OpenNESS - 20.03
+## Smart Edge Open - 20.03
 - Support for HDDL-R only restricted to non-real-time or non-customized CentOS 7.6 default kernel.
 
-## OpenNESS - 20.06
+## Smart Edge Open - 20.06
 - Offline install for Native mode OnPremises has be deprecated
 
-## OpenNESS - 20.09
+## Smart Edge Open - 20.09
 - Native on-premises is now located in a dedicated repository with no further feature updates from previous release.
 
-## OpenNESS - 20.12
+## Smart Edge Open - 20.12
 There are no unsupported or discontinued features relevant to this release.
 
-## OpenNESS - 21.03
-- FlexRAN/Access Edge CERA Flavor is only available in Intel Distribution of OpenNESS
-- OpenNESS repositories have been consolidated to the following 
-  - https://github.com/open-ness/converged-edge-experience-kits
-  - https://github.com/open-ness/specs
-  - https://github.com/open-ness/edgeapps
-  - https://github.com/open-ness/edgeservices
-  - https://github.com/open-ness/openshift-operator
+## Smart Edge Open - 21.03
+- FlexRAN/Access Edge Smart Edge Open Experience Kit Flavor is only available in Intel Distribution of Smart Edge Open
+- Smart Edge Open repositories have been consolidated to the following 
+  - https://github.com/smart-edge-open/converged-edge-experience-kits
+  - https://github.com/smart-edge-open/specs
+  - https://github.com/smart-edge-open/edgeapps
+  - https://github.com/smart-edge-open/edgeservices
+  - https://github.com/smart-edge-open/openshift-operator
+
+## Smart Edge Open - 21.09
+- No new features updates
 
 # Fixed Issues
 
-## OpenNESS - 19.06
+## Smart Edge Open - 19.06
 There are no non-Intel issues relevant to this release.
 
-## OpenNESS - 19.06.01
+## Smart Edge Open - 19.06.01
 There are no non-Intel issues relevant to this release.
 
-## OpenNESS - 19.06.01
+## Smart Edge Open - 19.06.01
 - VHOST HugePages dependency
 - Bug in getting appId by IP address for the container
 - Wrong value of appliance verification key printed by ansible script
@@ -355,155 +365,159 @@ There are no non-Intel issues relevant to this release.
 - Invalid status after app un-deployment
 - Application memory field is in MB
 
-## OpenNESS - 19.12
+## Smart Edge Open - 19.12
 - Improved usability/automation in Ansible scripts
 
-## OpenNESS - 20.03
+## Smart Edge Open - 20.03
 - Realtime Kernel support for network edge with K8s.
 - Modular playbooks
 
-## OpenNESS - 20.06
+## Smart Edge Open - 20.06
 - Optimized the Kubernetes based deployment by supporting multiple Flavors
 
-## OpenNESS - 20.09
+## Smart Edge Open - 20.09
 - Further optimized the Kubernetes based deployment by supporting multiple Flavors
 - Network edge installation time is optimized using pre-built Docker images
 - cAdvisor occasional failure issue is resolved
 - "Traffic rule creation: cannot parse filled and cleared fields" in Legacy OnPremises is fixed
 - Issue fixed when removing Edge Node from Controller when its offline and traffic policy is configured or app deployed
 
-## OpenNESS - 20.12
+## Smart Edge Open - 20.12
 - Known issue with Pod that uses hugepage get stuck in terminating state on deletion hs been fixed after upgrading to Kubernetes 1.19.3
 - Upgraded to Kube-OVN v1.5.2 for further Kube-OVN CNI enhancements
 
-## OpenNESS - 20.12.02
+## Smart Edge Open - 20.12.02
 - Fixed EdgeDNS service building failure resulting in deployment failure
 - Fixed FlexRAN and FlexRAN Telemetry flavors to eliminate deployment failures
 - Fixed Calico and SR-IOV deployment failures
 - Fixed TAS deployment
 - Updated SR-IOV CNI and device plugin to fix issues with image build in offline package creator
 
-## OpenNESS - 21.03
+## Smart Edge Open - 21.03
 - Offline deployment issues related to zlib-devel version 1.2.7-19
 - CAdvisor resource utilization has been optimized using "--docker_only=true" which decreased CPU usage from 15-25% to 5-6% (confirmed with ‘docker stats’ and ‘top’ commands). Memory usage also decreased by around 15-20%.
 
-## OpenNESS - 21.03.01
+## Smart Edge Open - 21.03.01
 - Resolved an intermittent issue with Kubernetes repository signature verification
 
-## OpenNESS - 21.03.02
+## Smart Edge Open - 21.03.02
 - Fixed DPDK compilation issue when primary CNI is Calico with eBPF and kernel is 5.X.
 - Resolved intermittent Pip installation issues.
 - Corrected Azure single node deployment issues due to incorrect configuration in the setup script.
 - Resolved offline installation of Ansible prerequisites.
 - VCA card is now correctly brought up after node reboot.
 
-## OpenNESS - 21.03.03
+## Smart Edge Open - 21.03.03
 - Fixed multi-node deployment for Azure cloud by changing CNI to kube-ovn as Calico is not supported by Azure.
 
+## Smart Edge Open - 21.09
+
+- Intel Edge Software Hub Reference implementation updated and revalidated to working with Smart Edge Open - 21.09.
+
 # Known Issues and Limitations
-## OpenNESS - 19.06
+## Smart Edge Open - 19.06
 There are no issues relevant to this release.
 
-## OpenNESS - 19.06.01
+## Smart Edge Open - 19.06.01
 There is one issue relevant to this release: it is not possible to remove the application from Edge Node in case of error during application deployment. The issue concerns applications in a Virtual Machine.
 
-## OpenNESS - 19.09
+## Smart Edge Open - 19.09
 - Gateway in multi-node - will not work when few nodes will have the same public IP (they will be behind one common NAT)
 - Ansible in K8s can cause problems when rerun on a machine:
   - If after running all 3 scripts
   - Script 02 will be run again (it will not remove all necessary K8s related artifacts)
   - We would recommend cleaning up the installation on the node
 
-## OpenNESS - 19.12
+## Smart Edge Open - 19.12
 - Gateway in multi-node - will not work when few nodes will have the same public IP (they will be behind one common NAT)
-- OpenNESS On-Premises: Cannot remove a failed/disconnected the edge node information/state from the controller
+- Smart Edge Open On-Premises: Cannot remove a failed/disconnected the edge node information/state from the controller
 - The CNCA API (4G & 5G) supported in this release is an early access reference implementation and does not support authentication
 - Real-time kernel support has been temporarily disabled to address the Kubernetes 1.16.2 and Realtime kernel instability.
 
-## OpenNESS - 20.03
+## Smart Edge Open - 20.03
 - On-Premises edge installation takes more than 1.5 hours because of the Docker image build for OVS-DPDK
 - Network edge installation takes more than 1.5 hours because of the Docker image build for OVS-DPDK
-- OpenNESS controller allows management NICs to be in the pool of configuration, which might allow configuration by mistake. Thus, disconnecting the node from control plane
+- Smart Edge Open controller allows management NICs to be in the pool of configuration, which might allow configuration by mistake. Thus, disconnecting the node from control plane
 - When using the SRIOV EPA feature added in 20.03 with OVNCNI, the container cannot access the CNI port. This is due to the SRIOV port being set by changing the network used by the container from default to a custom network. This overwrites the OVNCNI network setting configured before this to enable the container to work with OVNCNI. Another issue with the SRIOV, is that this also overwrites the network configuration with the EAA and edgedns, agents, which prevents the SRIOV enabled container from communicating with the agents.
 - Cannot remove Edge Node from Controller when its offline and traffic policy is configured or the app is deployed.
 
-## OpenNESS - 20.06
+## Smart Edge Open - 20.06
 - On-Premises edge installation takes 1.5hrs because of the Docker image build for OVS-DPDK
 - Network edge installation takes 1.5hrs because of docker image build for OVS-DPDK
-- OpenNESS controller allows management NICs to be in the pool of configuration, which might allow configuration by mistake and thereby disconnect the node from control plane
+- Smart Edge Open controller allows management NICs to be in the pool of configuration, which might allow configuration by mistake and thereby disconnect the node from control plane
 - When using the SRIOV EPA feature added in 20.03 with OVNCNI, the container cannot access the CNI port. This is due to the SRIOV port being set by changing the network used by the container from default to a custom network, This overwrites the OVNCNI network setting configured prior to this to enable the container to work with OVNCNI. Another issue with the SRIOV, is that this also overwrites the network configuration with the EAA and edgedns, agents, which prevents the SRIOV enabled container from communicating with the agents.
 - Cannot remove Edge Node from Controller when its offline and traffic policy is configured or app is deployed.
 - Legacy OnPremises - Traffic rule creation: cannot parse filled and cleared fields
 - There is an issue with using CDI when uploading VM images when CMK is enabled due to missing CMK taint toleration. The CDI upload pod does not get deployed and the `virtctl` plugin command times out waiting for the action to complete. A workaround for the issue is to invoke the CDI upload command, edit the taint toleration for the CDI upload to tolerate CMK, update the pod, create the PV, and let the pod run to completion.
 - There is a known issue with cAdvisor which in certain scenarios occasionally fails to expose the metrics for the Prometheus endpoint. See the following GitHub\* link: https://github.com/google/cadvisor/issues/2537
 
-## OpenNESS - 20.09
+## Smart Edge Open - 20.09
 - Pod which uses hugepage get stuck in terminating state on deletion. This is a known issue on Kubernetes 1.18.x and is planned to be fixed in 1.19.x
-- Calico cannot be used as secondary CNI with Multus in OpenNESS. It will work only as primary CNI. Calico must be the only network provider in each cluster. We do not currently support migrating a cluster with another network provider to use Calico networking. https://docs.projectcalico.org/getting-started/kubernetes/requirements
+- Calico cannot be used as secondary CNI with Multus in Smart Edge Open. It will work only as primary CNI. Calico must be the only network provider in each cluster. We do not currently support migrating a cluster with another network provider to use Calico networking. https://docs.projectcalico.org/getting-started/kubernetes/requirements
 - Collectd Cache telemetry using RDT does not work when RMD is enabled because of resource conflict. Workaround is to disable collectd RDT plugin when using RMD - this by default is implemented globally. With this workaround customers will be able to allocate the Cache but not use Cache related telemetry. In case where RMD is not being enabled customers who desire RDT telemetry can re-enable collectd RDT.
 
-## OpenNESS - 20.12
+## Smart Edge Open - 20.12
 - cAdvisor CPU utilization of Edge Node is high and could cause a delay to get an interactive SSH session. A work around is to remove CAdvisor if not needed using `helm uninstall cadvisor -n telemetry`
-- An issue appears when the KubeVirt Containerized Data Importer (CDI) upload pod is deployed with Kube-OVN CNI, the deployed pods readiness probe fails and pod is never in ready state. It is advised that the user uses other CNI such as Calico CNI when using CDI with OpenNESS
+- An issue appears when the KubeVirt Containerized Data Importer (CDI) upload pod is deployed with Kube-OVN CNI, the deployed pods readiness probe fails and pod is never in ready state. It is advised that the user uses other CNI such as Calico CNI when using CDI with Smart Edge Open
 - Telemetry deployment with PCM enabled will cause a deployment failure in single node cluster deployments due to PCM dashboards for Grafana not being found
 
-## OpenNESS - 20.12.02
+## Smart Edge Open - 20.12.02
 - Offline deployment issues related to zlib-devel version 1.2.7-19
 
-## OpenNESS - 21.03
-- An issue appears when the KubeVirt Containerized Data Importer (CDI) upload pod is deployed with Kube-OVN CNI, the deployed pods readiness probe fails and pod is never in ready state. Calico CNI is used by default in OpenNESS when using CDI
-- Telemetry deployment with PCM enabled will cause a deployment failure in single node cluster deployments due to conflict with CollectD deployment, it is advised to not use PCM and CollectD at the same time in OpenNESS at this time
+## Smart Edge Open - 21.03
+- An issue appears when the KubeVirt Containerized Data Importer (CDI) upload pod is deployed with Kube-OVN CNI, the deployed pods readiness probe fails and pod is never in ready state. Calico CNI is used by default in Smart Edge Open when using CDI
+- Telemetry deployment with PCM enabled will cause a deployment failure in single node cluster deployments due to conflict with CollectD deployment, it is advised to not use PCM and CollectD at the same time in Smart Edge Open at this time
 - Kafka and Zookeeper resource consumption is on the higher side. When deployed in the context of uCPE and SD-WAN users need to consider this. 
 - When flannel CNI is being used and worker node is being manually joined or re-joined to the cluster, then 
 `kubectl patch node NODE_NAME -p '{ "spec":{ "podCIDR":"10.244.0.0/24" }}`
 command should be issued on controller to enable flannel CNI on that node.
 
-## OpenNESS - 21.03.02
+## Smart Edge Open - 21.03.02
 - Multi-node deployment through Azure cloud fails due to the default (Calico) CNI not being supported by Azure.
 
 # Release Content
 
-## OpenNESS - 19.06
-OpenNESS Edge node, OpenNESS Controller, Common, Spec, and OpenNESS Applications.
+## Smart Edge Open - 19.06
+Smart Edge Open Edge node, Smart Edge Open Controller, Common, Spec, and Smart Edge Open Applications.
 
-## OpenNESS - 19.06.01
-OpenNESS Edge node, OpenNESS Controller, Common, Spec, and OpenNESS Applications.
+## Smart Edge Open - 19.06.01
+Smart Edge Open Edge node, Smart Edge Open Controller, Common, Spec, and Smart Edge Open Applications.
 
-## OpenNESS - 19.09
-OpenNESS Edge node, OpenNESS Controller, Common, Spec, and OpenNESS Applications.
+## Smart Edge Open - 19.09
+Smart Edge Open Edge node, Smart Edge Open Controller, Common, Spec, and Smart Edge Open Applications.
 
-## OpenNESS - 19.12
-OpenNESS Edge node, OpenNESS Controller, Common, Spec, OpenNESS Applications, and Experience kit.
+## Smart Edge Open - 19.12
+Smart Edge Open Edge node, Smart Edge Open Controller, Common, Spec, Smart Edge Open Applications, and Experience kit.
 
-## OpenNESS - 20.03
-OpenNESS Edge node, OpenNESS Controller, Common, Spec, OpenNESS Applications, and Experience kit.
+## Smart Edge Open - 20.03
+Smart Edge Open Edge node, Smart Edge Open Controller, Common, Spec, Smart Edge Open Applications, and Experience kit.
 
-## OpenNESS - 20.06
+## Smart Edge Open - 20.06
 - Open Source: Edge node, Controller, Epcforedge, Common, Spec, Applications, and Experience kit.
 - IDO: IDO Edge node, IDO Controller, IDO Epcforedge, IDO Spec, and IDO Experience kit.
 
-## OpenNESS - 20.09
+## Smart Edge Open - 20.09
 - Open Source: Edge node, Controller, Epcforedge, Common, Spec, Applications and Experience kit.
 - IDO: IDO Edge node, IDO Controller, IDO Epcforedge, IDO Spec and IDO Experience kit.
 
-## OpenNESS - 20.12
+## Smart Edge Open - 20.12
 - Open Source: Edge node, Controller, Epcforedge, Common, Spec, Applications and Experience kit.
 - IDO: IDO Edge node, IDO Controller, IDO Epcforedge, IDO Spec and IDO Experience kit.
 
 > **NOTE**: Edge applications repo is common to Open Source and IDO
 
-## OpenNESS - 20.12.02
+## Smart Edge Open - 20.12.02
 - Open Source: Edge node, Controller, Epcforedge, Common, Spec, Applications and Experience kit.
 - IDO: IDO Edge node, IDO Controller, IDO Epcforedge, IDO Spec and IDO Experience kit.
-## OpenNESS - 21.03
-  - https://github.com/open-ness/converged-edge-experience-kits
-  - https://github.com/open-ness/specs
-  - https://github.com/open-ness/edgeapps
-  - https://github.com/open-ness/edgeservices
-  - https://github.com/open-ness/openshift-operator
+## Smart Edge Open - 21.03
+  - https://github.com/smart-edge-open/converged-edge-experience-kits
+  - https://github.com/smart-edge-open/specs
+  - https://github.com/smart-edge-open/edgeapps
+  - https://github.com/smart-edge-open/edgeservices
+  - https://github.com/smart-edge-open/openshift-operator
 
 # Hardware and Software Compatibility
-OpenNESS Edge Node has been tested using the following hardware specification:
+Smart Edge Open Edge Node has been tested using the following hardware specification:
 
 ## Intel® Xeon® D Processor
 - Supermicro\* 3U form factor chassis server, product SKU code: 835TQ-R920B
@@ -550,8 +564,8 @@ OpenNESS Edge Node has been tested using the following hardware specification:
 
 # Supported Operating Systems
 
-OpenNESS was tested on CentOS Linux release 7.9.2009 (Core)
-> **NOTE**: OpenNESS is tested with CentOS 7.9 Pre-empt RT kernel to ensure VNFs and Applications can co-exist. There is no requirement from OpenNESS software to run on a Pre-empt RT kernel.
+Smart Edge Open was tested on CentOS Linux release 7.9.2009 (Core)
+> **NOTE**: Smart Edge Open is tested with CentOS 7.9 Pre-empt RT kernel to ensure VNFs and Applications can co-exist. There is no requirement from Smart Edge Open software to run on a Pre-empt RT kernel.
 
 # Packages Version