Commit 27693ef7 authored by Kevin Di Lallo's avatar Kevin Di Lallo
Browse files

moved demo documentation to gh-pages + moved demo3 template configuration

parent b100d4a7
Loading
Loading
Loading
Loading
+7 −5
Original line number Diff line number Diff line
@@ -4,15 +4,17 @@

**_What's New in v1.8.1!_**

:zap: **Edge native services:  [ETSI MEC011 - Edge Platform Application Enablement](https://interdigitalinc.github.io/AdvantEDGE/docs/overview/edge-services/#edge-platform-application-enablement-service) and [ETSI MEC021 - Application Mobility](https://interdigitalinc.github.io/AdvantEDGE/docs/overview/edge-services/#application-mobility-service) fixes & improvements**
:zap: **Improved edge native services: Multiple fixes to [ETSI MEC011 - Edge Platform Application Enablement](https://interdigitalinc.github.io/AdvantEDGE/docs/overview/edge-services/#edge-platform-application-enablement-service) and [ETSI MEC021 - Application Mobility](https://interdigitalinc.github.io/AdvantEDGE/docs/overview/edge-services/#application-mobility-service)**

:zap: **WebSocket subscriptions: [ETSI MEC028 - WLAN Access Information Service](https://interdigitalinc.github.io/AdvantEDGE/docs/overview/edge-services/#wireless-access-information-service) support for WebSocket connections**
:zap: **New! [Demo3 example application](https://interdigitalinc.github.io/AdvantEDGE/docs/usage/usage-demo3) to showcase MEC011 & MEC021 service API usage**

:zap: **Data management: [Sandbox Metrics Garbage Collection](https://interdigitalinc.github.io/AdvantEDGE/docs/overview/features/#sandbox-subsystem) :wastebasket: to free unused resources & disk space**
:zap: **ETSI MEC028 WebSocket support: [ETSI MEC028 - WLAN Access Information Service](https://interdigitalinc.github.io/AdvantEDGE/docs/overview/edge-services/#wireless-access-information-service) now supports WebSocket model for receiving notifications**

:zap: **General maintenance fixes :hammer_and_wrench:**
:zap: **Improved sandbox data management: [Sandbox Metrics Garbage Collection](https://interdigitalinc.github.io/AdvantEDGE/docs/overview/features/#sandbox-subsystem) :wastebasket: can be configured to periodically recover unused sandbox disk space**

:zap: **"_Old New_" :wink: you can still easily reach out to the team by initiating [GitHub Discussion](https://github.com/InterDigitalInc/AdvantEDGE/discussions) :octocat:**
:zap: **General maintenance :hammer_and_wrench:**

:zap: **Don't hesitate to reach out to us by initiating [GitHub Discussion](https://github.com/InterDigitalInc/AdvantEDGE/discussions) :octocat:**

------

examples/README.md

deleted100644 → 0
+0 −5
Original line number Diff line number Diff line
# List of Demo Scenarios

- [Demo1](demo1/README.md)
- [Demo2](demo2/README.md)
+3 −122
Original line number Diff line number Diff line
# Demo1

A simple scenario used to showcase platform capabilities.

This scenario is composed of three applications (_iperf-server_, _iperf-proxy & _demo-server_) deployed across multiple tiers of the network (fog/edge/cloud).

- The _iperf-server_ is the standard open-source _iperf-server_ that is containerized; it runs in the AdvantEDGE platform. It is used to generate traffic between the internal & external UE. The demo scenario contains multiple instances of the _iperf-server_ deployed across various tiers of the network. The _iperf-server_ image form the public iperf registry is used in this demo.
- _iperf-proxy_ is a small server application runs on the host machine. It allows to control the local host iperf-client from the demo web-client. The demo scenario runs a single instance of the _iperf-proxy_. Source code is available in this repo; _iperf-proxy_ is built as part of this demo.
- _demo-server_ is an edge application that is containerized; it runs in the AdvantEDGE platform. It has been developed to demonstrate AdvantEDGE capabilities. The demo scenario contains multiple instances of _demo-server_ deployed across various tiers of the network. Source code is available in this repo;_demo-server_ is built as part of this demo.

It has two clients (internal & external) that communicate with the servers.
Internal client traffic is iperf only and has no GUI.
External client accesses both iperf and demo servers and has a GUI.

The platform capabilities demonstrated with this scenario are:

Demo1 scenario showcases the following platform capabilities:
- Scenario deployment (dynamic charts)
- Network tiering
- Internal & external clients
- Network characteristics
- Edge-application deployment model: one-to many relationship
- UE mobility
- Applciation state transfer (_demo server_)
- Application state transfer
- Monitoring (demo specific dashboards)

## Scenario composition

The scenario is composed of the following components:

- 2 distant cloud application: _iperf_ server and _demo_ server
- 1 MNO that has 2 Zones
  - Zone1 has 2 PoAs & 1 Edge node
  - Zone2 has 1 PoA & 1 Edge node
  - PoA1 in Zone1 is equipped with a Fog node
  - Each Fog/Edge node runs 2 Edge servers (_iperf_ and _demo_)
- 2 UEs
  - 1 internal UE that runs an iperf client
  - 1 external UE that runs a Demo client

#### Internal UE application

Upon scenario startup, internal UE application (an iperf client) connects automatically to the closest iperf server and starts transferring traffic.

As the UE moves around the network, edge node instance will change.

#### External UE

External UE application is a javascript application running in an external browser.

To start the aooplcation, load the following page in the browser `<AdvantEDGE-node-ip-address>:31111`

The application shows details about the connection, allows to start a state counter and iperf traffic and presents an image. See Iperf & Demo server sub-sections for more details.

#### Iperf server

This is a standard iperf server that will terminate iperf client connections.

There is an iperf client running in the internal UE and another one in the external UE.

External UE needs the iperf proxy running to be able to control the iperf client from the javascript GUI.

#### Demo server

Demo server is a web server that maintains a UE state and also stores unique data.
Only the external UE accesses the demo server.

Unique data is an image that is different for each location; therefore depending on the UE location in the network, the external UE GUI will show a different image. This image provides a visual indication that the UE is connected to a different network location.

UE state is in the form of a counter incremented on the server every second. Counter lives on the server side and UE can only start/reset the counter and display its value.
On the UE GUI, the counter is started by pressing the button.

When the external UE moves in the network and transitions from one edge instance to another, the "UE state" (e.g. the counter value) is transferred using the application state transfer. On the UE GUI, the counter continue incrementing (e.g. not reset to zero) when the UE moves in the network.

## Using the scenario

The following steps need to be done prior to using this scenario

#### Obtain demo binaries

##### Build from source

To build _iperf-proxy_ & _demo-server_ binaries from source code:

```
cd ~/AdvantEDGE/examples/demo1/
./build-demo1.sh
```

> **NOTE:** Binary files are created in ./bin/ folder

##### Optionally use pre-built binaries (from GitHub release)

```
# Get bin folder tarball from desired release
cd ~/AdvantEDGE/examples/demo1
tar -zxvf demo1.<version>.linux-amd64.tar.gz
```

#### Dockerize demo applications

Demo Application binaries must be dockerized (containerized) as container images in the Docker registry. This step is necessary every time the demo binaries are updated.

> **NOTE:** Make sure you have deployed the AdvantEDGE dependencies (e.g. docker registry) before dockerizing the demo binaries.

To generate docker images from demo binary files:

```
cd ~/AdvantEDGE/examples/demo1/
./dockerize.sh
```

#### Start iperf proxy

Do it everytime you start using the demo when the iperf-proxy is not running

This demo scenario requires iperf installed on the AdvantEDGE host and the iperf proxy running.

If `which iperf` returns nothing, install iperf

```
sudo apt-get install iperf
# the following should now return /usr/bin/iperf
which iperf
```

Start iperf proxy, in a command line shell

```
cd ~/AdvantEDGE/examples/demo1/bin/iperf-proxy
./iperf-proxy
```
For more details, check out the [Demo1 Documentation](https://interdigitalinc.github.io/AdvantEDGE/docs/usage/usage-demo1)
+2 −35
Original line number Diff line number Diff line
# Demo2
Demo2 scenario is the same as [Demo1](../demo1/README.md) except that it uses _user charts_ to deploy its components instead of using dynamic chart generation.

This scenario is the same as [demo1](../demo1/README.md) except that it uses _user charts_ to deploy its components instead of using dynamic chart generation.

## Prerequisites

- Running AdvantEDGE platform
- Demo1 docker images
  - [Build demo1](../demo1/README.md)
  - [Dockerize demo1](../demo1/README.md)

## Using the scenario

The following steps need to be done prior to using this scenario

##### Build

To build demo2:

```
cd ~/AdvantEDGE/examples/demo2/
./build-demo2.sh
```

##### Import

To import demo2 follow steps given for demo1 just import demo2-scenario.yaml from AdvantEDGE/examples/demo2/ instead of demo1-scenario.yaml:

[Import scenario in AdvantEDGE](https://github.com/InterDigitalInc/AdvantEDGE/wiki/basic-operation#import-demo1-scenario-in-advantedge)



##### Deploy

To deploy demo2 follow steps given for demo1 just select demo2 from dropdown instead of demo:

[Deploy scenario in AdvantEDGE](https://github.com/InterDigitalInc/AdvantEDGE/wiki/basic-operation#deploy-demo1-scenario)
For more details, check out the [Demo2 Documentation](https://interdigitalinc.github.io/AdvantEDGE/docs/usage/usage-demo2)
+2 −137
Original line number Diff line number Diff line
# Demo3
Demo3 scenario showcases the _Edge Platform Application Enablement_ and _Application Mobility_ edge services.

Demo 3 demonstrates how to use AdvantEDGE mec services showcasing Application Mobility Service (AMS) and Edge Application Enablement Service API.

Demo 3 is a user MEC application that can be integrated within an AdvantEDGE scenario or used as an external application with [ETSI MEC Sandbox](https://try-mec.etsi.org/). 




Demo3 MEC Application provides a dashboard GUI that allow a user to visualize interactions with MEC Service such as:

1. MEC011 - Application Enablement and Service Enablement Services:

- MEC Application registration/deregistration 
- MEC Service discovery & offering 
- Monitor event notifications about service and application availability 

2. Application Mobility Service provides support for relocation of user context and/or application instance between MEC hosts enabling:

- MEC Assisted state transfer operationn



## Getting Started:
Demo 3 can be used with an AdvantEDGE deployment or with the ETSI MEC Sandbox public deployment.
#### AdvantEDGE procedure overview
- Demo3 is built and dockerized using provided bash scripts
- Demo3 scenario (provided) is imported in AdvantEDGE
- Demo3 scenario is deployed on AdvantEDGE
#### MEC Sandbox procedure overview
- Demo3 is built using provided bash scripts
- Demo3 executable and frontend are copied to a common folder
- A MEC Sandbox is created and configured on ETSI MEC Sandbox [site](https://try-mec.etsi.org/)
- Demo3 configuration files (provided) are updated with your environment values
- Demo3 application is executed and accesses the ETSI MEC Sandbox

###  Using Demo3 with ETSI MEC Sandbox

- Demo 3 does not have any prior knowledge or configuration information of the MEC services offered by the MEC platform

The following steps need to be done prior to running demo 3

| Operation: | Notes: |
| ---------  | ------ |
| 0a. Build demo3 server and frontend by invoking `Advantedge/examples/demo3/build-demo3.sh` |  |
| 0b. Create work directories of your choice on the system of your choosing; we'll use `~/demo3-mep1` and `~/demo3-mep2` for this example and create a folder named `static` inside each one of the folders. The structure should look like this <br>
     ├── demo3-mep1
          ├── static
     ├── demo3-mep2
          ├── static
**IMPORTANT** ``` For this demo to work, the system running demo applications must be at a public IP address so that notifications sent by the ETSI MEC Sandbox can be received by demo applications. If the system is behind a firewall, ports will need to be opened.  ``` 

|  |  |
| ---------  | ------ |
| 0c. For each application instance, copy Demo3 server (`/AdvantEDGE/examples/demo3/bin/demo-server/demo-server`) in the work directories and copy Demo3 frontend bundle `/AdvantEDGE/example/demo3/bin/demo-frontend/*` in the static folder <br> The resulting should look like this <br>
     ├── demo3-mep1
          ├── demo-server
          ├── static
               ├── bundle.css
               ├── bundle.js
               ├── img
                    ├── AdvantEDGE-logo-NoTagline_White_RGB.png
                    ├── ID-Icon-01-idcc.svg
                    ├── network.png
               ├── index.html
     ├── demo3-mep2
          ├── demo-server
          ├── static
               ├── bundle.css
               ├── bundle.js
               ├── img
                    ├── AdvantEDGE-logo-NoTagline_White_RGB.png
                    ├── ID-Icon-01-idcc.svg
                    ├── network.png
               ├── index.html
|  |  |                  
| ---------  | ------ |
| 1. Login via the MEC Sandbox frontend |  |
| 2. Deploy a Dual MEP scenario and create two Application Instance IDs calles `demo3`, one on MEP1 and one on MEP2 respectively |  |
| 3. Using provided `demo3-config.yaml` template, create a configuration file for each of the MEP1 and MEP2 applications and save each configuration files in their respective work folder created in step 0 <br> The resulting structure should look like this <br>` mode: 'sandbox'` - demo3 runs against ETSI MEC Sandbox <br> ` https: true ` - ETSI MEC sandbox uses https<br>`sandbox: 'https://try-mec.testfqdn.dev/mep1' `- URL to your sandbox, this info is available in the ETSI MEC Sandbox frontend <br> `mecplatform: 'mep1'`- the MEP where the instance is running, one of your application should be mep1 and the other mep2<br> `appid: '' ` - these are created in the ETSI MEC Sandbox frontend<br> ` localurl: 'http://'` - the public IP address where demo3 instance is running<br> `port: ''` - the port number that demo3 is listening on for incoming traffic<br>
| 4. Start the demo3 instances `./demo3-server demo3-config.yaml` -- after starting the servers, the frontend can be accessed at `<your-ip-address>:<your-port>` <br> From the frontend, demo3 can register to MEC011 and then devices present in the scenario can be added.

Example of a configuration file
```sh .env
# This file defines the configuration of Demo3 edge application
# Required to define if application will run on MEC Sandbox or AdvantEDGE. Expected Values: sandbox or advantedge
mode: 'sandbox'
# Field to define MEC platform URL that app will run on. Example: http://{Mec_IP_Address}/{Sandbox_name}/{Mep_name}/
https: true
sandbox: 'https://try-mec.testfqdn.dev/sbx-1234abcd/mep1'
# Field to define MEC platform name. Example: mep1
mecplatform: 'mep1'
# Field to define user-application ID that can be generated using MEC Sandbox frontend
appid: 'cd9e4234-d7b7-4d49-be64-850ca436e24c'
# Local I.P address application will run on
localurl: 'http://1.2.3.4'
# Port number of user-application example: port: '8093'
port: '31111'

```

### Build Demo 3 Server and Frontend

``` shell
cd AdvantEdge/examples/demo3
./build-demo3.sh
``` 
###  Using Demo3 with AdvantEDGE

### Demo server & Demo frontend 

Demo server is a web server that will run internally in AdvantEdge as the backend of demo 3 application. The frontend is a dashboard to provide information on the MEC application instance in the scenario. One capability When the external UE moves in the network and transitions from one edge instance to another, the "UE state" (e.g. the counter value) is transferred using the application state transfer. On the demo server, it maintains a state of external UE as a counter that will continue incrementing (e.g. not reset to zero) when the UE moves in the network.



The following steps need to be done prior to using this scenario

#### Configure demo frontend and obtain binaries
| Operation | Notes |   
| ---------  | ------ |
| 0. Build and dockerize demo3 by invoking `AdvantEDGE/examples/demo3/build-demo3.sh` and `AdvantEDGE/examples/demo3/dockerize.sh`|  |
| 1. Import provided `demo3-scenario.yaml` in AdvantEDGE and save it | |
| 2. Deploy `demo3-scenario` from the frontend | this scenario uses geo-localization, therefore it is necessary to provision a map as described [here](https://interdigitalinc.github.io/AdvantEDGE/docs/overview/features/gis/#map-provisioning) |


## Scenario composition

The scenario is composed of two instance of same MEC applications running on two different mec platform

MEC Application instance 1 on MEC Platform mep1 coverage area: zone01 (PoA:4g-macro-cell-1)
MEC Application instance 2 on MEC Platform mep2 coverage area: zone2, zone3 (PoA: 4g1 & wifi1) 

The scenario is composed of the following components:

- 2 instance of the same edge application: demo-app and demo-app2
- 1 MNO that has 3 Zones
  - Zone1 has 1 Edge node
  - Zone2&3 has 1 Edge node
- 3 UEs with pre-defined route will move interchangeably from mep 1 to mep2
For more details, check out the [Demo3 Documentation](https://interdigitalinc.github.io/AdvantEDGE/docs/usage/usage-demo3)
Loading