Skip to content

Commit 27693ef

Browse files
committed
moved demo documentation to gh-pages + moved demo3 template configuration
1 parent b100d4a commit 27693ef

File tree

7 files changed

+15
-305
lines changed

7 files changed

+15
-305
lines changed

README.md

Lines changed: 7 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -4,15 +4,17 @@
44

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

7-
: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**
7+
: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)**
88

9-
: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**
9+
:zap: **New! [Demo3 example application](https://interdigitalinc.github.io/AdvantEDGE/docs/usage/usage-demo3) to showcase MEC011 & MEC021 service API usage**
1010

11-
:zap: **Data management: [Sandbox Metrics Garbage Collection](https://interdigitalinc.github.io/AdvantEDGE/docs/overview/features/#sandbox-subsystem) :wastebasket: to free unused resources & disk space**
11+
: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**
1212

13-
:zap: **General maintenance fixes :hammer_and_wrench:**
13+
: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**
1414

15-
:zap: **"_Old New_" :wink: you can still easily reach out to the team by initiating [GitHub Discussion](https://github.com/InterDigitalInc/AdvantEDGE/discussions) :octocat:**
15+
:zap: **General maintenance :hammer_and_wrench:**
16+
17+
:zap: **Don't hesitate to reach out to us by initiating [GitHub Discussion](https://github.com/InterDigitalInc/AdvantEDGE/discussions) :octocat:**
1618

1719
------
1820

examples/README.md

Lines changed: 0 additions & 5 deletions
This file was deleted.

examples/demo1/README.md

Lines changed: 3 additions & 122 deletions
Original file line numberDiff line numberDiff line change
@@ -1,131 +1,12 @@
11
# Demo1
2-
3-
A simple scenario used to showcase platform capabilities.
4-
5-
This scenario is composed of three applications (_iperf-server_, _iperf-proxy & _demo-server_) deployed across multiple tiers of the network (fog/edge/cloud).
6-
7-
- 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.
8-
- _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.
9-
- _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.
10-
11-
It has two clients (internal & external) that communicate with the servers.
12-
Internal client traffic is iperf only and has no GUI.
13-
External client accesses both iperf and demo servers and has a GUI.
14-
15-
The platform capabilities demonstrated with this scenario are:
16-
2+
Demo1 scenario showcases the following platform capabilities:
173
- Scenario deployment (dynamic charts)
184
- Network tiering
195
- Internal & external clients
206
- Network characteristics
217
- Edge-application deployment model: one-to many relationship
228
- UE mobility
23-
- Applciation state transfer (_demo server_)
9+
- Application state transfer
2410
- Monitoring (demo specific dashboards)
2511

26-
## Scenario composition
27-
28-
The scenario is composed of the following components:
29-
30-
- 2 distant cloud application: _iperf_ server and _demo_ server
31-
- 1 MNO that has 2 Zones
32-
- Zone1 has 2 PoAs & 1 Edge node
33-
- Zone2 has 1 PoA & 1 Edge node
34-
- PoA1 in Zone1 is equipped with a Fog node
35-
- Each Fog/Edge node runs 2 Edge servers (_iperf_ and _demo_)
36-
- 2 UEs
37-
- 1 internal UE that runs an iperf client
38-
- 1 external UE that runs a Demo client
39-
40-
#### Internal UE application
41-
42-
Upon scenario startup, internal UE application (an iperf client) connects automatically to the closest iperf server and starts transferring traffic.
43-
44-
As the UE moves around the network, edge node instance will change.
45-
46-
#### External UE
47-
48-
External UE application is a javascript application running in an external browser.
49-
50-
To start the aooplcation, load the following page in the browser `<AdvantEDGE-node-ip-address>:31111`
51-
52-
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.
53-
54-
#### Iperf server
55-
56-
This is a standard iperf server that will terminate iperf client connections.
57-
58-
There is an iperf client running in the internal UE and another one in the external UE.
59-
60-
External UE needs the iperf proxy running to be able to control the iperf client from the javascript GUI.
61-
62-
#### Demo server
63-
64-
Demo server is a web server that maintains a UE state and also stores unique data.
65-
Only the external UE accesses the demo server.
66-
67-
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.
68-
69-
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.
70-
On the UE GUI, the counter is started by pressing the button.
71-
72-
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.
73-
74-
## Using the scenario
75-
76-
The following steps need to be done prior to using this scenario
77-
78-
#### Obtain demo binaries
79-
80-
##### Build from source
81-
82-
To build _iperf-proxy_ & _demo-server_ binaries from source code:
83-
84-
```
85-
cd ~/AdvantEDGE/examples/demo1/
86-
./build-demo1.sh
87-
```
88-
89-
> **NOTE:** Binary files are created in ./bin/ folder
90-
91-
##### Optionally use pre-built binaries (from GitHub release)
92-
93-
```
94-
# Get bin folder tarball from desired release
95-
cd ~/AdvantEDGE/examples/demo1
96-
tar -zxvf demo1.<version>.linux-amd64.tar.gz
97-
```
98-
99-
#### Dockerize demo applications
100-
101-
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.
102-
103-
> **NOTE:** Make sure you have deployed the AdvantEDGE dependencies (e.g. docker registry) before dockerizing the demo binaries.
104-
105-
To generate docker images from demo binary files:
106-
107-
```
108-
cd ~/AdvantEDGE/examples/demo1/
109-
./dockerize.sh
110-
```
111-
112-
#### Start iperf proxy
113-
114-
Do it everytime you start using the demo when the iperf-proxy is not running
115-
116-
This demo scenario requires iperf installed on the AdvantEDGE host and the iperf proxy running.
117-
118-
If `which iperf` returns nothing, install iperf
119-
120-
```
121-
sudo apt-get install iperf
122-
# the following should now return /usr/bin/iperf
123-
which iperf
124-
```
125-
126-
Start iperf proxy, in a command line shell
127-
128-
```
129-
cd ~/AdvantEDGE/examples/demo1/bin/iperf-proxy
130-
./iperf-proxy
131-
```
12+
For more details, check out the [Demo1 Documentation](https://interdigitalinc.github.io/AdvantEDGE/docs/usage/usage-demo1)

examples/demo2/README.md

Lines changed: 2 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -1,37 +1,4 @@
11
# Demo2
2+
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.
23

3-
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.
4-
5-
## Prerequisites
6-
7-
- Running AdvantEDGE platform
8-
- Demo1 docker images
9-
- [Build demo1](../demo1/README.md)
10-
- [Dockerize demo1](../demo1/README.md)
11-
12-
## Using the scenario
13-
14-
The following steps need to be done prior to using this scenario
15-
16-
##### Build
17-
18-
To build demo2:
19-
20-
```
21-
cd ~/AdvantEDGE/examples/demo2/
22-
./build-demo2.sh
23-
```
24-
25-
##### Import
26-
27-
To import demo2 follow steps given for demo1 just import demo2-scenario.yaml from AdvantEDGE/examples/demo2/ instead of demo1-scenario.yaml:
28-
29-
[Import scenario in AdvantEDGE](https://github.com/InterDigitalInc/AdvantEDGE/wiki/basic-operation#import-demo1-scenario-in-advantedge)
30-
31-
32-
33-
##### Deploy
34-
35-
To deploy demo2 follow steps given for demo1 just select demo2 from dropdown instead of demo:
36-
37-
[Deploy scenario in AdvantEDGE](https://github.com/InterDigitalInc/AdvantEDGE/wiki/basic-operation#deploy-demo1-scenario)
4+
For more details, check out the [Demo2 Documentation](https://interdigitalinc.github.io/AdvantEDGE/docs/usage/usage-demo2)

examples/demo3/README.md

Lines changed: 2 additions & 137 deletions
Original file line numberDiff line numberDiff line change
@@ -1,139 +1,4 @@
11
# Demo3
2+
Demo3 scenario showcases the _Edge Platform Application Enablement_ and _Application Mobility_ edge services.
23

3-
Demo 3 demonstrates how to use AdvantEDGE mec services showcasing Application Mobility Service (AMS) and Edge Application Enablement Service API.
4-
5-
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/).
6-
7-
8-
9-
10-
Demo3 MEC Application provides a dashboard GUI that allow a user to visualize interactions with MEC Service such as:
11-
12-
1. MEC011 - Application Enablement and Service Enablement Services:
13-
14-
- MEC Application registration/deregistration
15-
- MEC Service discovery & offering
16-
- Monitor event notifications about service and application availability
17-
18-
2. Application Mobility Service provides support for relocation of user context and/or application instance between MEC hosts enabling:
19-
20-
- MEC Assisted state transfer operationn
21-
22-
23-
24-
## Getting Started:
25-
Demo 3 can be used with an AdvantEDGE deployment or with the ETSI MEC Sandbox public deployment.
26-
#### AdvantEDGE procedure overview
27-
- Demo3 is built and dockerized using provided bash scripts
28-
- Demo3 scenario (provided) is imported in AdvantEDGE
29-
- Demo3 scenario is deployed on AdvantEDGE
30-
#### MEC Sandbox procedure overview
31-
- Demo3 is built using provided bash scripts
32-
- Demo3 executable and frontend are copied to a common folder
33-
- A MEC Sandbox is created and configured on ETSI MEC Sandbox [site](https://try-mec.etsi.org/)
34-
- Demo3 configuration files (provided) are updated with your environment values
35-
- Demo3 application is executed and accesses the ETSI MEC Sandbox
36-
37-
### Using Demo3 with ETSI MEC Sandbox
38-
39-
- Demo 3 does not have any prior knowledge or configuration information of the MEC services offered by the MEC platform
40-
41-
The following steps need to be done prior to running demo 3
42-
43-
| Operation: | Notes: |
44-
| --------- | ------ |
45-
| 0a. Build demo3 server and frontend by invoking `Advantedge/examples/demo3/build-demo3.sh` | |
46-
| 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>
47-
├── demo3-mep1
48-
├── static
49-
├── demo3-mep2
50-
├── static
51-
**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. ```
52-
53-
| | |
54-
| --------- | ------ |
55-
| 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>
56-
├── demo3-mep1
57-
├── demo-server
58-
├── static
59-
├── bundle.css
60-
├── bundle.js
61-
├── img
62-
├── AdvantEDGE-logo-NoTagline_White_RGB.png
63-
├── ID-Icon-01-idcc.svg
64-
├── network.png
65-
├── index.html
66-
├── demo3-mep2
67-
├── demo-server
68-
├── static
69-
├── bundle.css
70-
├── bundle.js
71-
├── img
72-
├── AdvantEDGE-logo-NoTagline_White_RGB.png
73-
├── ID-Icon-01-idcc.svg
74-
├── network.png
75-
├── index.html
76-
| | |
77-
| --------- | ------ |
78-
| 1. Login via the MEC Sandbox frontend | |
79-
| 2. Deploy a Dual MEP scenario and create two Application Instance IDs calles `demo3`, one on MEP1 and one on MEP2 respectively | |
80-
| 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>
81-
| 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.
82-
83-
Example of a configuration file
84-
```sh .env
85-
# This file defines the configuration of Demo3 edge application
86-
# Required to define if application will run on MEC Sandbox or AdvantEDGE. Expected Values: sandbox or advantedge
87-
mode: 'sandbox'
88-
# Field to define MEC platform URL that app will run on. Example: http://{Mec_IP_Address}/{Sandbox_name}/{Mep_name}/
89-
https: true
90-
sandbox: 'https://try-mec.testfqdn.dev/sbx-1234abcd/mep1'
91-
# Field to define MEC platform name. Example: mep1
92-
mecplatform: 'mep1'
93-
# Field to define user-application ID that can be generated using MEC Sandbox frontend
94-
appid: 'cd9e4234-d7b7-4d49-be64-850ca436e24c'
95-
# Local I.P address application will run on
96-
localurl: 'http://1.2.3.4'
97-
# Port number of user-application example: port: '8093'
98-
port: '31111'
99-
100-
```
101-
102-
### Build Demo 3 Server and Frontend
103-
104-
``` shell
105-
cd AdvantEdge/examples/demo3
106-
./build-demo3.sh
107-
```
108-
### Using Demo3 with AdvantEDGE
109-
110-
### Demo server & Demo frontend
111-
112-
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.
113-
114-
115-
116-
The following steps need to be done prior to using this scenario
117-
118-
#### Configure demo frontend and obtain binaries
119-
| Operation | Notes |
120-
| --------- | ------ |
121-
| 0. Build and dockerize demo3 by invoking `AdvantEDGE/examples/demo3/build-demo3.sh` and `AdvantEDGE/examples/demo3/dockerize.sh`| |
122-
| 1. Import provided `demo3-scenario.yaml` in AdvantEDGE and save it | |
123-
| 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) |
124-
125-
126-
## Scenario composition
127-
128-
The scenario is composed of two instance of same MEC applications running on two different mec platform
129-
130-
MEC Application instance 1 on MEC Platform mep1 coverage area: zone01 (PoA:4g-macro-cell-1)
131-
MEC Application instance 2 on MEC Platform mep2 coverage area: zone2, zone3 (PoA: 4g1 & wifi1)
132-
133-
The scenario is composed of the following components:
134-
135-
- 2 instance of the same edge application: demo-app and demo-app2
136-
- 1 MNO that has 3 Zones
137-
- Zone1 has 1 Edge node
138-
- Zone2&3 has 1 Edge node
139-
- 3 UEs with pre-defined route will move interchangeably from mep 1 to mep2
4+
For more details, check out the [Demo3 Documentation](https://interdigitalinc.github.io/AdvantEDGE/docs/usage/usage-demo3)
File renamed without changes.

examples/demo3/demo3-scenario.yaml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
version: 1.8.0
2-
name: demo3-single-mep
2+
name: demo3
33
deployment:
44
netChar:
55
latency: 50

0 commit comments

Comments
 (0)