update #9 with lcm intro

doc/naas/lcm_intro.md

 # Lifecycle Management - LCM
 
 
-Lifecycle Management: The orchestration framework handles updates, scaling, and any necessary modifications throughout the service lifecycle.
+Lifecycle Management: The orchestration framework handles the activation, termination and any necessary modifications throughout the service lifecycle.
 
 
 ## Intended Audience: Service Designers
@@ -14,9 +14,9 @@ In OpenSlice the Lifecycle of a service follows in general the concept of Networ
 
 ## Introduction in OpenSlice LCM
 
-OpenSlice Adopted adopted the LCM model by 3GPP and mapped to the TMF model service state. Next we discuss briefly the process and the relationships.
+OpenSlice adopted the LCM model by 3GPP and mapped to the TMF model service state. Next we discuss briefly the process and the relationships.
 
-The lifecycle of a service, particularly in the context of Network Service lifecycleencompasses several stages that ensure the service is effectively planned, deployed, managed, and eventually decommissioned. 
+The lifecycle of a service, particularly in the context of Network Service lifecycle encompasses several stages that ensure the service is effectively planned, deployed, managed, and eventually decommissioned. 
 
 Here is an overview of these stages and relationships with OpenSlice:
 
@@ -41,23 +41,25 @@ This phase is performed by Service Designers
 
 #### Service Instantiation:
 
-- **Configuration:** Configure the network service according to the specifications includin the user requirements from the service order, ensuring that all components are correctly set up to provide the desired service.
-- **Resource Allocation - Feasibility check:** Allocate the necessary physical and virtual resources based on the service specification. This includes any containerized resources, virtual network functions (VNFs) and software-defined networking (SDN) components. (This step is not perfromed in OpenSlice)
+- **Configuration:** Configure the network service according to the specifications including the user requirements from the service order, ensuring that all components are correctly set up to provide the desired service.
+- **Resource Allocation - Feasibility check:** Allocate the necessary physical and virtual resources based on the service specification. This includes any containerized resources, virtual network functions (VNFs) and software-defined networking (SDN) components. (This step is not performed in OpenSlice)
 - OpenSlice Service Orchestrator creates the services at "RESERVED" state
 - **User Notification:**  There could be an email notification from the system (if Bugzilla is configured)
 
 #### Service Deployment:
+
 - **Activation:** OpenSlice Service Orchestrator activates the network service and makes the service available to the end-users. This may involve:
   - Create any related services that the service depends on
   - Contacting all related controllers during provisioning, e.g. Kubernetes controllers, Kubernetes operators, MANO Orchestrators, RAN controllers, SDN Controlles, or other external services (e.g. via REST calls)
   - Scheduling instantiation, Resolving dependencies and passing paramemters between controllers,
   - setting up user accounts, provisioning access credentials -this is performed either offline or via other services.
-- OpenSlice Service Orchestrator if everything is succesful put the service at "ACTIVE" state
+- OpenSlice Service Orchestrator if everything is succesful puts the service at "ACTIVE" state
 - **User Notification:**  There could be an email notification from the system (if Bugzilla is configured)
 
 ### 2. Operation Phase
 
 #### Service Operation:
+
 - **Lifecycle Management:** Manage the network slice throughout its lifecycle, including scaling, reconfiguration, and adaptation to changing requirements. 
 - In OpenSlice this is performed with Lifecycle management Rules (see next)
 
@@ -70,13 +72,11 @@ In this phase the Service Designer can define several aspects.  **Be aware that
 
 ### 3. Decommissioning Phase
 
-#### Service Decommissioning:
-
- **Service Termination:** Service Orchestrator terminates the network service . This may involve:
+- **Service Termination:** Service Orchestrator terminates the network service. This may involve:
   - Terminate any related services that the service depends on
   - Contacting all related controllers during termination to release resources, e.g. Kubernetes controllers, Kubernetes operators, MANO Orchestrators, RAN controllers, SDN Controlles, or other external services (e.g. via REST calls)
   - Scheduling termination, Resolving dependencies and passing paramemters between controllers
-- OpenSlice Service Orchestrator if everything is succesful put the service at "TERMINATED" state
+- OpenSlice Service Orchestrator, if everything is succesful, puts the service at "TERMINATED" state
 - **User Notification:**  There could be an email notification from the system (if Bugzilla is configured)
 
 ### High level example: Enhanced Mobile Broadband (eMBB) Service Lifecycle

doc/naas/lcm_rules_intro.md

+# Lifecycle Management Rules - LCM Rules
+
+
+Lifecycle Management Rules: Defining complex conditions and actions during the lifecycle of a service and any necessary modifications throughout the service lifecycle.
+
+
+## Intended Audience: Service Designers
+
+ OpenSlice end-to-end (E2E) service orchestrator follows some predefined workflows to manage a service lifecycle (They are described in BPMN language and included in our orchestration engine)
+
+ So in the system there are already predefined recipes, which in each process-step of the workflow some piece of code is executed. 
+
+ How is it possible to intervene in the workflow process and inject some user defined actions? The next image illustrates the idea
+
+[![lcm](./lcm/img02.png)](./lcm/img02.png)
+
+
+ ## How is it possible to intervene in the workflow process and affect it?
+
+LCM Rules are used for defining complex conditions and actions during the lifecycle of a service. In Openslice there are the following types of rules defined:
+
+* PRE_PROVISION
+* CREATION
+* AFTER_ACTIVATION 
+* SUPERVISION 
+* AFTER_DEACTIVATION 
+
+The following figure displays the different phases that the rules are performed, during the lifecycle of a Network Service Instance. 
+
+
+[![lcm](./lcm/img03.png)](./lcm/img03.png)
+
+
+* PRE_PROVISION rules: Run only once just before creating a service with a given priority. 
+* CREATION rules: Run while the referenced service dependencies of a service are created
+* AFTER_ACTIVATION rules: Run only once just after a service get the ACTIVE state
+* SUPERVISION rules: Run when a characteristic of a service is changed and the service is in the ACTIVE state 
+* AFTER_DEACTIVATION rules: Run only once just after a service get the INACTIVE/TERMINATED state 
+
+In general the rules allow to perform many actions during service LCM. These are some examples:
+
+* Modify service specification parameters before the instantiation of a service (or during operation) based on other dependencies. These parameters might be part of other services already included in Service order
+* Translate GST/NEST parameter values to other values passed later to NFVO for instantiation or control
+* Define complex OSM Configs based on other dependencies and passing variables
+* Define any dependencies when creating the referenced services
+* Dynamically include new service dependencies
+* Create new service orders so include dynamically other services
+* Call external (RESTful) services (via http(s), define payload, examine response)
+
+
+
+
+## Examine if the rules are executed successfully 
+
+Rules are transformed automatically to executable code (currently is Java). If a rule is performed successfully  or has any issues (e.g. unexpected syntax errors or exceptions) appear in OSOM logfiles and also tey are attached as Notes to the running Service.
+
+
+## Probe further
+
+* In the [Service Design](../service_design/intro.md) section we present in details the Lifecycle rules and how one can design them
+* Many of them are used in our provided Service Design [examples](../service_design/examples/intro.md)
\ No newline at end of file

doc/naas/so_intro.md

@@ -6,5 +6,13 @@
 
 OpenSlice end-to-end (E2E) service orchestration framework is designed to manage and automate the entire lifecycle of services across multiple domains and technologies. For delivering, Network as a Service (NaaS) OpenSlice automates and manages the entire lifecycle of network services, from provisioning to monitoring and decommissioning, while ensuring seamless integration, operation, and delivery of services from the initial request to the final delivery, spanning all involved components and layers.
 
-This section provides an overview of the Service Orchestration process
+As next image depicts, service orchestrators follow some predefined workflows. OpenSlice end-to-end (E2E) service orchestrator follows some predefined workflows to manage a service lifecycle (They are described in BPMN language and included in our orchestration engine)
+
+[![SO](./so/img01.png)](./so/img01.png)
+
+This section provides a high level overview of the Service Orchestration process.
+
+
+
+
 

mkdocs.yml

@@ -123,6 +123,7 @@ nav:
       - Specification: ./service_design/lcmrules/specification.md
       - Typical Examples: ./service_design/lcmrules/examples.md
     - Service Specification Examples: 
+      - Introduction: ./service_design/examples/intro.md
       - Open5GS (NFV approach): ./service_design/examples/open5gs_nfv.md
       - Open5GS (Kubernetes approach): ./service_design/examples/open5gs_kubernetes.md
       - Exposing CRDs_aaS_Example_Calculator: ./service_design/examples/ExposingCRDs_aaS_Example_Calculator/ExposingCRDs_aaS_Example_Calculator.md