Minor use cases fixes (a6cfeb65) · Commits · MEC - Multi-access Edge Computing / MEC Sandbox Scenarios

Macro-Network-Scenario/README.md

+5 −0

Original line number	Diff line number	Diff line
		@@ -15,6 +15,10 @@
		* [MEC Sandbox Use Cases](#mec-sandbox-use-cases)
		* Sandbox External ME App discovery of the Network and Tracking a Device via Location Service API
		* Browser based MEC client tracking the Location of a Device
		* Service consuming MEC application
		* Service offering MEC application
		* MEC application using "scope of locality"

		* [Assumptions and Limitations](#assumptions-and-limitations)


		@@ -54,6 +58,7 @@
		\|Browser \| [Tracking a terminal location](use-case2.md)
		\| External ME App \| [Use case for service consuming MEC application](use-case3.md)
		\| External ME App \| [Use case for service offering MEC application](use-case4.md)
		\| External ME App \| [Use case for MEC application using "scope of locality"](use-case5.md)

		## Assumptions and Limitations
		\| Category \| Assumptions/Limitations

Macro-Network-Scenario/use-case3.md

+1 −1

Original line number	Diff line number	Diff line
		@@ -16,7 +16,7 @@ Objective:
		\| --------- \| ------ \|
		\| 1. Login via the frontend & select Sandbox tab \| \|
		\| 2. Select a network to deploy in the user sandbox \| \|
		\| 3a. Pre-configure ME Application with Application Enablement service endpoints \| Endpoints: <li>`https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v1`<li>`https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` <br><br>_Note: for readability, endpoint URIs are replaced by `.../`_\|
		\| 3a. Pre-configure ME Application with Application Enablement service endpoints \| Endpoints: <br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v1`<br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` <br><br>_Note: for readability, endpoint URIs are replaced by `.../`_\|
		\| 3b. Pre-configure ME Application with an Application Instance ID (e.g. `appInstanceId`) \| MEC Platform Manager (MEPM) usually assigns `appInstanceId` to running applications <br><br> To support external user applications, the `appInstanceId` has to be generated from the frontend \|
		\| 4. Start ME App or environment \| ME App knows nothing about available MEC services <br><br> In the following steps, ME App will learn MEC services availability via Mp1 interface \|
		\| 5. `GET .../services` \| ME App discovers there are 3 services available (Location/RNIS/WAIS) with their respective URIs <br><br> ME App starts using discovered Location service. \|

Macro-Network-Scenario/use-case4.md

+1 −1

Original line number	Diff line number	Diff line
		@@ -15,7 +15,7 @@ Objective:
		\| --------- \| ------ \|
		\| 1. Login via the frontend & select Sandbox tab \| \|
		\| 2. Select a network to deploy in the user sandbox \| \|
		\| 3a. Pre-configure ME Application with Application Enablement service endpoints \| Endpoints: <li>`https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v1`<li>`https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` <br><br>_Note: for readability, endpoint URIs are replaced by `.../`_\|
		\| 3a. Pre-configure ME Application with Application Enablement service endpoints \| Endpoints: <br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v1`<br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` <br><br>_Note: for readability, endpoint URIs are replaced by `.../`_\|
		\| 3b. Pre-configure ME Application with an Application Instance ID (e.g. `appInstanceId`) \| MEC Platform Manager (MEPM) usually assigns `appInstanceId` to running applications <br><br> To support external user applications, the `appInstanceId` has to be generated from the frontend \|
		\| 4. Start ME App or environment \| In the following steps, ME App will register a service via Mp1 interface \|
		\| 5. `POST .../applications/{appInstanceId}/confirm_ready` \| ME App indicates readiness to the MEC platform \|

Macro-Network-Scenario/user-case5.md→Macro-Network-Scenario/use-case5.md

+2 −2

Original line number	Diff line number	Diff line
		@@ -20,11 +20,11 @@ Objective:
		\| --------- \| ------ \|
		\| 1. Login via the frontend & select Sandbox tab \| \|
		\| 2. Select the `dual-mep` network to deploy in the user sandbox \| `dual-mep` scenario has `mep1` for Zone 1 & 2 locality and `mep2` for Zone 3 & 4 locality <br><br> Each node runs an instance of Location service with its own dataset; RNIS & WAIS are MEC system wide services.
		\| 3a. Pre-configure ME Application with Application Enablement service endpoints \| Endpoints: <li>`https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v1`<li>`https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` <br><br>_Note: for readability, endpoint URIs are replaced by `.../`_\|
		\| 3a. Pre-configure ME Application with Application Enablement service endpoints \| Endpoints: <br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v1`<br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` <br><br>_Note: for readability, endpoint URIs are replaced by `.../`_\|
		\| 3b. Pre-configure ME Application with an Application Instance ID (e.g. `appInstanceId`) \| MEC Platform Manager (MEPM) usually assigns `appInstanceId` to running applications <br><br> To support external user applications, the `appInstanceId` has to be generated from the frontend <br><br> Generating the `appInstanceId` asks for the locality of the ME App (e.g. `mep1` or `mep2`)\|
		\| 4. Start ME App or environment \| ME App knows nothing about available MEC services <br><br> In the following steps, ME App will learn MEC available services via Mp1 interface \|
		\| 5. `GET .../services` \| ME App discovers there are 3 services available (Location/RNIS/WAIS) with their respective URIs <br><br> Location service URI corresponds to the locality of the ME App<br><br> ME App starts using discovered Location service. \|
		\| 6. `POST .../applications/{appInstanceId}/subscriptions` \| ME App wants to learn about service availability changes for Location service <br><br> ME App stores the returned subscription id for future subscription management
		\| 6. `POST .../applications/{appInstanceId}/subscriptions` \| ME App wants to learn about service availability changes for Location service <br><br> The subscription filter has `isLocal=true`, indicating same locality service events only <br><br> ME App stores the returned subscription id for future subscription management
		\| 7a. Disable Location (same locality as ME App) from the frontend \| ME App is notified of Location service un-availability and stops using it \|
		\| 7b. Disable Location (different locality as ME App) from the frontend \| ME App is not notified of Location service un-availability \|
		\| 8. Enable Location service (same locality as ME App) from the frontend \| ME App is notified of Location service availability and starts using it

Sandbox-User-Interface/README.md

+12 −13

Original line number	Diff line number	Diff line
		@@ -4,14 +4,13 @@
		This section describes the main type of interactions that a user may have with the MEC Sandbox

		##### 1. User Access and Authentication
		> _User accounts are expected to be managed on ETSI side & tied to ETSI Forge Dev, EOL or other accounts<br>
		Integration details between the MEC Sandbox & ETSI user accounts are expected from ETSI_
		* Sign in/out of MEC Sandbox portal

		##### 2. Configuration, Control & State
		> _Scenario configuration, control & state happens from the browser portal_
		* Configure Sandbox Scenario (see scenario definitions for specific configuration points)
		* Start, pause, terminate, and restart Sandbox Scenario
		* Configure terminal number and movement
		* Start, terminate Sandbox Scenario
		* Observe Sandbox Scenario state (terminals, map, PoA location, UE location, etc.)

		##### 3. "Try-it" from External MEC Client application
		@@ -30,18 +29,18 @@ It is expected that user manually configures its ME App with MEC Service endpoin

		\| Operation \| User Story(s) \| Notes \|
		\|---------- \| --------------------------------------- \| ----- \|
		\| Access \| As a Sandbox User...<br><br>...I can learn about ETSI MEC Services and the MEC Sandbox without having to sign in my "ETSI Forge Dev"<br><br>... I can sign-in with my "ETSI Forge Dev" account from the sandbox portal to start my user sandbox instance<br><br> ... I can access my user sandbox instance in isolation from other users after I have signed in to my "ETSI Forge Dev" account<br><br>... I can sign out from my "ETSI Forge Dev" account to terminate my sandbox instance\| OPEN --> "ETSI Forge Dev" account integration information needed. <br><br>STF assumes that Forge will provide:<br>- HTTPS certificate<br>- Global DNS MEC Sandbox registration<br>- user signup & authentication code/integration instructions<br>- authentication token (TBD - required?)
		\| Access \| As a Sandbox User...<br><br>...I can learn about ETSI MEC Services and the MEC Sandbox without having to sign in my "ETSI Forge Dev"<br><br>... I can sign-in with my "ETSI Forge Dev" account from the sandbox portal to start my user sandbox instance<br><br> ... I can access my user sandbox instance in isolation from other users after I have signed in to my "ETSI Forge Dev" account<br><br>... I can sign out from my "ETSI Forge Dev" account to terminate my sandbox instance\| <br>- Authentication using GitHub and Forge GitLab (EOL account) OAuth providers <br>- User signup handled by OAuth providers <br>- HTTPS certificate provided via Let's Encrypt technology (free) <br>- Global DNS provided by ETSI \|
		\| Configuration \| As a Sandbox User...<br><br>... I can select the scenario that is executed in my sandbox instance<br><br>... I can configure execution parameters for the selected scenario \| See [MEC Sandbox Wireframe](#mec-sandbox-wireframe) for configuration points\|
		\| Control \| As a Sandbox User...<br><br>... I can start my sandbox scenario<br>- emulated terminals start moving<br>- MEC Service APIs endpoints return valid data<br>- etc.<br><br>... I can observe execution state of my scenario in real-time<br>- UE location on the map<br>- PoA location on the map<br>- etc.<br><br>... I can pause scenario execution at any moment to statically observe MEC Service API endpoint results<br>- UEs stop moving<br>- MEC Service endpoints return valid data<br><br>... I can resume scenario execution<br>- terminals start moving from their current position<br><br>... I can restart scenario execution<br>- UEs return to their initial position<br>- no state is retained & scenario starts"fresh"<br><br>... I can terminate scenario execution<br>- no state is retained<br>- selecting another scenario terminates current\| See [MEC Sandbox Wireframe](#mec-sandbox-wireframe) for more information. \|
		\| External MEC Client application \| As a Sandbox User... <br><br>... I can configure my ME App using sandbox specific endpoint information presented to me<br><br>... I can observe, in my ME App, valid response & notifications received from MEC Services<br>- reflecting state of selected scenario<br><br>... I can observe, in the browser, all requests/responses/notifications exchanged between my ME App and the MEC Services<br>- REST request/responses/notifications<br>- facilitate debugging/observability<br>- useful if user cannot provide callback URL<br><br>... I can compare API response/notifications shown in the browser or in my ME App with the current state of my scenario\| Questions: <br><br> <br>- Should sandbox API endpoints stay consistent across sandbox access (i.e. log-in sessions)?<br>- We want to differentiate sandbox endpoints using a path parameter (UUID/access token) and an Ingress Controller for L7 HTTP request routing - any issue with this?<br>- Subscription Notifications will require user to provide callback URLs that the Sandbox can call (e.g. users may be behind firewalls, NAT's, etc.)<br><br> OPEN --> Support for External MEC Clients and requirements to put on Sandbox Users. \|
		\| Browser MEC Client application \| As a Sandbox User...<br><br>... I can exercise MEC Service API endpoints without having to create my own environment (i.e. ME App)<br><br>... I can observe, in the browser, all requests/responses/notifications exchanged between the browser client and MEC Services<br>- REST request/responses/notifications<br>- facilitate observability<br><br>... I can compare API response/notifications shown in the browser with the current state of my scenario\|<br>- Swagger UI client (same as Forge) to trigger requests & responses<br>- SwaggerUI client configured to communicate with user sandbox<br>- Notification callbacks can be observed in UI Notifications window\|
		\| External MEC Client application \| As a Sandbox User... <br><br>... I can configure my ME App using sandbox specific endpoint information presented to me<br><br>... I can observe, in my ME App, valid response & notifications received from MEC Services<br>- reflecting state of selected scenario<br><br>... I can observe, in the browser, all requests/responses/notifications exchanged between my ME App and the MEC Services<br>- REST request/responses/notifications<br>- facilitate debugging/observability<br>- useful if user cannot provide callback URL<br><br>... I can compare API response/notifications shown in the browser or in my ME App with the current state of my scenario\| - Notification callbacks require user to provide a valid callback URLs (e.g. that the Sandbox can reach) to succeed \|
		\| Browser MEC Client application \| As a Sandbox User...<br><br>... I can exercise MEC Service API endpoints without having to create my own environment (i.e. ME App)<br><br>... I can observe, in the browser, all requests/responses/notifications exchanged between the browser client and MEC Services<br>- REST request/responses/notifications<br>- facilitate observability<br><br>... I can compare API response/notifications shown in the browser with the current state of my scenario\|- Swagger UI client used to send requests & receive responses to/from the user sandbox <br>- SwaggerUI client pre-configured to communicate with user sandbox<br>- Notification callbacks can be observed in UI Notifications window \|

		## MEC Sandbox Wireframe
		\| Id \| Description \| Wireframe\|
		\|---------- \| --------------------------------------- \| ----- \|
		\| SBox01 \| Landing page<br>- Presents information about the MEC sandbox & opportunity to sign in<br>- User Sandbox is disabled on the sidebar<br>- Clicking on ETSI logo: redirects to `https://forge.etsi.org/`<br>- Clicking on sign in: user is redirected to the "ETSI Forge Dev" sign in page -- TBD<br>- Footer is the same as the one seen on `https://forge.etsi.org/` \|Click to enlarge<br>![SBox01](SBox01.png)
		\| SBox02 \| Landing Page - Post sign in<br>- Sign in button changes to sign out<br>- User sandbox link in the sidebar becomes activated<br>- User Sandbox is automatically selected & transitions to SBox03 \|Click to enlarge<br>![SBox02](SBox02.png)
		\| SBox03 \| User Sandbox<br>- Sandbox is shown in main area - with a Map, Configuration and API Console area<br>- Map Area: shows a default location (Monaco / ETSI headquarters - TBD)<br>- Configuration area: Network drop-down is enabled (no network selected), all other controls disabled<br>- API Console: MEC API dropdown is enabled, selecting another API updates the "Try-It from your MEC Application" URL \|Click to enlarge<br>![SBox03](SBox03.png)
		\| SBox04 \| User Sandbox - Configuration Area<br>- Selecting a scenario starts the execution & enables other controls<br>- _Pause_ - Dinamically start/stop UE movement<br>- _Stationary UE selector_ - Dynamically pick number of UEs (camera,sensor,etc.)- Default 1, Max TBD<br>- _Low Velocity UE_- Dynamically pick number UEs (pedestrian) - Default 1, Max TBD<br>- _High Velocity UE_- Pick number UEs (car) - Default 1, Max TBD\|Click to enlarge<br>![SBox04](SBox04.png)
		\| SBox05a \| User Sandbox - API Console - Try-It portion<br>- _MEC API dropdown_ select a supported MEC API - influence both Try-it links<br>- _Try-It in the browser_ - Link opens a Swagger UI window configured for the current user sandbox<br>- _Try-It in your MEC Application_ - Shows the link to use from the ME App to reach the selected service in the user sandbox\|Click to enlarge<br>![SBox05a](SBox05a.png)
		\| SBox05b \| User Sandbox - API Console - Monitoring portion<br>- _MEC API dropdown_ filters content of Query & Notification monitoring windows<br>- _Query/Response area_ - shows query/responses of the selected MEC Service<br>- _Notification Area_ - shows notification callbacks sent by the selected MEC Service<br>- _View Data_ - message is shown in JSON format \|Click to enlarge<br>![SBox05b](SBox05b.png)
		\| SBox01 \| Landing page<br>- Presents information about the MEC sandbox (Home - default), Help and Sign In buttons<br>- Sandbox is disabled<br>- Clicking on ETSI logo: redirects to `https://forge.etsi.org/`<br>- clicking on Help: provides help options (Webinar, Wiki, Slack, Report an Issue) <br>- Clicking on Sign In: user is presented with choice of GitHub or GitLab (EOL Account) OAuth provider & redirected to the selected provider sign in page \|Click to enlarge<br>![SBox01](SBox01.png)
		\| SBox02 \| Landing Page - Post sign in<br>- Sign in button changes to "user meatball"<br>- Clicking on meatball allows to sign out <br>- Sandbox menu is activated<br>- User Sandbox is automatically selected & transitions to SBox03 \|Click to enlarge<br>![SBox02](SBox02.png#)
		\| SBox03 \| User Sandbox<br>- Sandbox is shown in main area - with a Map, Configuration and API Console area<br>- Map Area: shows a default location (Monaco)<br>- Configuration area: Network drop-down is enabled (no network selected), all other controls disabled<br>- API Console: MEC API dropdown is enabled, selecting another API updates the "Try-It from your MEC Application" URL \|Click to enlarge<br>![SBox03](SBox03.png#)
		\| SBox04 \| User Sandbox - Configuration Area<br>- Selecting a scenario starts the execution & enables other controls<br>- _Pause_ - Dinamically start/stop UE movement<br>- _Stationary UE selector_ - Dynamically pick number of UEs (camera,sensor,etc.)- Default 1, Max 4<br>- _Low Velocity UE_- Dynamically pick number UEs (pedestrian) - Default 1, Max 4<br>- _High Velocity UE_- Pick number UEs (car) - Default 1, Max 4 <br><br>New STF599 <br>- `Dual-MEP` scenario includes two MEC Platforms each running a localized one instance of Location service (MEC013) <br>- Application Instance ID controls: user creates Application Instance ID(s) for its ME App(s) _(needed for MEC011 API)_\| Click to enlarge<br>![SBox04](SBox04.png)
		\| SBox05a \| User Sandbox - API Console - Try-It portion<br>- _MEC API dropdown_ select a supported MEC API - influence both Try-it links<br>- _Try-It in the browser_ - Link opens a Swagger UI window configured for the current user sandbox<br>- _Try-It in your MEC Application_ - Shows the link to use from the ME App to reach the selected service in the user sandbox <br><br>New STF599 <br>- Application Support API (MEC011) <br> - Service Management API (MEC011)\|Click to enlarge<br>![SBox05a](SBox05a.png##)
		\| SBox05b \| User Sandbox - API Console - Monitoring portion<br>- _API Console messages area_ - shows query/responses/notifications of all services<br>- Clicking on amessage shows it in JSON format \|Click to enlarge<br>![SBox05b](SBox05b.png##)

Original line number	Diff line number	Diff line
		@@ -16,7 +16,7 @@ Objective:
		\| --------- \| ------ \|
		\| 1. Login via the frontend & select Sandbox tab \| \|
		\| 2. Select a network to deploy in the user sandbox \| \|
		\| 3a. Pre-configure ME Application with Application Enablement service endpoints \| Endpoints: <li>`https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v1`<li>`https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` <br><br>_Note: for readability, endpoint URIs are replaced by `.../`_\|
		\| 3a. Pre-configure ME Application with Application Enablement service endpoints \| Endpoints: <br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v1`<br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` <br><br>_Note: for readability, endpoint URIs are replaced by `.../`_\|
		\| 3b. Pre-configure ME Application with an Application Instance ID (e.g. `appInstanceId`) \| MEC Platform Manager (MEPM) usually assigns `appInstanceId` to running applications <br><br> To support external user applications, the `appInstanceId` has to be generated from the frontend \|
		\| 4. Start ME App or environment \| ME App knows nothing about available MEC services <br><br> In the following steps, ME App will learn MEC services availability via Mp1 interface \|
		\| 5. `GET .../services` \| ME App discovers there are 3 services available (Location/RNIS/WAIS) with their respective URIs <br><br> ME App starts using discovered Location service. \|

Original line number	Diff line number	Diff line
		@@ -15,7 +15,7 @@ Objective:
		\| --------- \| ------ \|
		\| 1. Login via the frontend & select Sandbox tab \| \|
		\| 2. Select a network to deploy in the user sandbox \| \|
		\| 3a. Pre-configure ME Application with Application Enablement service endpoints \| Endpoints: <li>`https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v1`<li>`https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` <br><br>_Note: for readability, endpoint URIs are replaced by `.../`_\|
		\| 3a. Pre-configure ME Application with Application Enablement service endpoints \| Endpoints: <br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v1`<br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` <br><br>_Note: for readability, endpoint URIs are replaced by `.../`_\|
		\| 3b. Pre-configure ME Application with an Application Instance ID (e.g. `appInstanceId`) \| MEC Platform Manager (MEPM) usually assigns `appInstanceId` to running applications <br><br> To support external user applications, the `appInstanceId` has to be generated from the frontend \|
		\| 4. Start ME App or environment \| In the following steps, ME App will register a service via Mp1 interface \|
		\| 5. `POST .../applications/{appInstanceId}/confirm_ready` \| ME App indicates readiness to the MEC platform \|

Original line number	Diff line number	Diff line
		@@ -20,11 +20,11 @@ Objective:
		\| --------- \| ------ \|
		\| 1. Login via the frontend & select Sandbox tab \| \|
		\| 2. Select the `dual-mep` network to deploy in the user sandbox \| `dual-mep` scenario has `mep1` for Zone 1 & 2 locality and `mep2` for Zone 3 & 4 locality <br><br> Each node runs an instance of Location service with its own dataset; RNIS & WAIS are MEC system wide services.
		\| 3a. Pre-configure ME Application with Application Enablement service endpoints \| Endpoints: <li>`https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v1`<li>`https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` <br><br>_Note: for readability, endpoint URIs are replaced by `.../`_\|
		\| 3a. Pre-configure ME Application with Application Enablement service endpoints \| Endpoints: <br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v1`<br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` <br><br>_Note: for readability, endpoint URIs are replaced by `.../`_\|
		\| 3b. Pre-configure ME Application with an Application Instance ID (e.g. `appInstanceId`) \| MEC Platform Manager (MEPM) usually assigns `appInstanceId` to running applications <br><br> To support external user applications, the `appInstanceId` has to be generated from the frontend <br><br> Generating the `appInstanceId` asks for the locality of the ME App (e.g. `mep1` or `mep2`)\|
		\| 4. Start ME App or environment \| ME App knows nothing about available MEC services <br><br> In the following steps, ME App will learn MEC available services via Mp1 interface \|
		\| 5. `GET .../services` \| ME App discovers there are 3 services available (Location/RNIS/WAIS) with their respective URIs <br><br> Location service URI corresponds to the locality of the ME App<br><br> ME App starts using discovered Location service. \|
		\| 6. `POST .../applications/{appInstanceId}/subscriptions` \| ME App wants to learn about service availability changes for Location service <br><br> ME App stores the returned subscription id for future subscription management
		\| 6. `POST .../applications/{appInstanceId}/subscriptions` \| ME App wants to learn about service availability changes for Location service <br><br> The subscription filter has `isLocal=true`, indicating same locality service events only <br><br> ME App stores the returned subscription id for future subscription management
		\| 7a. Disable Location (same locality as ME App) from the frontend \| ME App is notified of Location service un-availability and stops using it \|
		\| 7b. Disable Location (different locality as ME App) from the frontend \| ME App is not notified of Location service un-availability \|
		\| 8. Enable Location service (same locality as ME App) from the frontend \| ME App is notified of Location service availability and starts using it

Original line number	Diff line number	Diff line
		@@ -4,14 +4,13 @@
		This section describes the main type of interactions that a user may have with the MEC Sandbox

		##### 1. User Access and Authentication
		> _User accounts are expected to be managed on ETSI side & tied to ETSI Forge Dev, EOL or other accounts<br>
		Integration details between the MEC Sandbox & ETSI user accounts are expected from ETSI_
		* Sign in/out of MEC Sandbox portal

		##### 2. Configuration, Control & State
		> _Scenario configuration, control & state happens from the browser portal_
		* Configure Sandbox Scenario (see scenario definitions for specific configuration points)
		* Start, pause, terminate, and restart Sandbox Scenario
		* Configure terminal number and movement
		* Start, terminate Sandbox Scenario
		* Observe Sandbox Scenario state (terminals, map, PoA location, UE location, etc.)

		##### 3. "Try-it" from External MEC Client application
		@@ -30,18 +29,18 @@ It is expected that user manually configures its ME App with MEC Service endpoin

		\| Operation \| User Story(s) \| Notes \|
		\|---------- \| --------------------------------------- \| ----- \|
		\| Access \| As a Sandbox User...<br><br>...I can learn about ETSI MEC Services and the MEC Sandbox without having to sign in my "ETSI Forge Dev"<br><br>... I can sign-in with my "ETSI Forge Dev" account from the sandbox portal to start my user sandbox instance<br><br> ... I can access my user sandbox instance in isolation from other users after I have signed in to my "ETSI Forge Dev" account<br><br>... I can sign out from my "ETSI Forge Dev" account to terminate my sandbox instance\| OPEN --> "ETSI Forge Dev" account integration information needed. <br><br>STF assumes that Forge will provide:<br>- HTTPS certificate<br>- Global DNS MEC Sandbox registration<br>- user signup & authentication code/integration instructions<br>- authentication token (TBD - required?)
		\| Access \| As a Sandbox User...<br><br>...I can learn about ETSI MEC Services and the MEC Sandbox without having to sign in my "ETSI Forge Dev"<br><br>... I can sign-in with my "ETSI Forge Dev" account from the sandbox portal to start my user sandbox instance<br><br> ... I can access my user sandbox instance in isolation from other users after I have signed in to my "ETSI Forge Dev" account<br><br>... I can sign out from my "ETSI Forge Dev" account to terminate my sandbox instance\| <br>- Authentication using GitHub and Forge GitLab (EOL account) OAuth providers <br>- User signup handled by OAuth providers <br>- HTTPS certificate provided via Let's Encrypt technology (free) <br>- Global DNS provided by ETSI \|
		\| Configuration \| As a Sandbox User...<br><br>... I can select the scenario that is executed in my sandbox instance<br><br>... I can configure execution parameters for the selected scenario \| See [MEC Sandbox Wireframe](#mec-sandbox-wireframe) for configuration points\|
		\| Control \| As a Sandbox User...<br><br>... I can start my sandbox scenario<br>- emulated terminals start moving<br>- MEC Service APIs endpoints return valid data<br>- etc.<br><br>... I can observe execution state of my scenario in real-time<br>- UE location on the map<br>- PoA location on the map<br>- etc.<br><br>... I can pause scenario execution at any moment to statically observe MEC Service API endpoint results<br>- UEs stop moving<br>- MEC Service endpoints return valid data<br><br>... I can resume scenario execution<br>- terminals start moving from their current position<br><br>... I can restart scenario execution<br>- UEs return to their initial position<br>- no state is retained & scenario starts"fresh"<br><br>... I can terminate scenario execution<br>- no state is retained<br>- selecting another scenario terminates current\| See [MEC Sandbox Wireframe](#mec-sandbox-wireframe) for more information. \|
		\| External MEC Client application \| As a Sandbox User... <br><br>... I can configure my ME App using sandbox specific endpoint information presented to me<br><br>... I can observe, in my ME App, valid response & notifications received from MEC Services<br>- reflecting state of selected scenario<br><br>... I can observe, in the browser, all requests/responses/notifications exchanged between my ME App and the MEC Services<br>- REST request/responses/notifications<br>- facilitate debugging/observability<br>- useful if user cannot provide callback URL<br><br>... I can compare API response/notifications shown in the browser or in my ME App with the current state of my scenario\| Questions: <br><br> <br>- Should sandbox API endpoints stay consistent across sandbox access (i.e. log-in sessions)?<br>- We want to differentiate sandbox endpoints using a path parameter (UUID/access token) and an Ingress Controller for L7 HTTP request routing - any issue with this?<br>- Subscription Notifications will require user to provide callback URLs that the Sandbox can call (e.g. users may be behind firewalls, NAT's, etc.)<br><br> OPEN --> Support for External MEC Clients and requirements to put on Sandbox Users. \|
		\| Browser MEC Client application \| As a Sandbox User...<br><br>... I can exercise MEC Service API endpoints without having to create my own environment (i.e. ME App)<br><br>... I can observe, in the browser, all requests/responses/notifications exchanged between the browser client and MEC Services<br>- REST request/responses/notifications<br>- facilitate observability<br><br>... I can compare API response/notifications shown in the browser with the current state of my scenario\|<br>- Swagger UI client (same as Forge) to trigger requests & responses<br>- SwaggerUI client configured to communicate with user sandbox<br>- Notification callbacks can be observed in UI Notifications window\|
		\| External MEC Client application \| As a Sandbox User... <br><br>... I can configure my ME App using sandbox specific endpoint information presented to me<br><br>... I can observe, in my ME App, valid response & notifications received from MEC Services<br>- reflecting state of selected scenario<br><br>... I can observe, in the browser, all requests/responses/notifications exchanged between my ME App and the MEC Services<br>- REST request/responses/notifications<br>- facilitate debugging/observability<br>- useful if user cannot provide callback URL<br><br>... I can compare API response/notifications shown in the browser or in my ME App with the current state of my scenario\| - Notification callbacks require user to provide a valid callback URLs (e.g. that the Sandbox can reach) to succeed \|
		\| Browser MEC Client application \| As a Sandbox User...<br><br>... I can exercise MEC Service API endpoints without having to create my own environment (i.e. ME App)<br><br>... I can observe, in the browser, all requests/responses/notifications exchanged between the browser client and MEC Services<br>- REST request/responses/notifications<br>- facilitate observability<br><br>... I can compare API response/notifications shown in the browser with the current state of my scenario\|- Swagger UI client used to send requests & receive responses to/from the user sandbox <br>- SwaggerUI client pre-configured to communicate with user sandbox<br>- Notification callbacks can be observed in UI Notifications window \|

		## MEC Sandbox Wireframe
		\| Id \| Description \| Wireframe\|
		\|---------- \| --------------------------------------- \| ----- \|
		\| SBox01 \| Landing page<br>- Presents information about the MEC sandbox & opportunity to sign in<br>- User Sandbox is disabled on the sidebar<br>- Clicking on ETSI logo: redirects to `https://forge.etsi.org/`<br>- Clicking on sign in: user is redirected to the "ETSI Forge Dev" sign in page -- TBD<br>- Footer is the same as the one seen on `https://forge.etsi.org/` \|Click to enlarge<br>![SBox01](SBox01.png)
		\| SBox02 \| Landing Page - Post sign in<br>- Sign in button changes to sign out<br>- User sandbox link in the sidebar becomes activated<br>- User Sandbox is automatically selected & transitions to SBox03 \|Click to enlarge<br>![SBox02](SBox02.png)
		\| SBox03 \| User Sandbox<br>- Sandbox is shown in main area - with a Map, Configuration and API Console area<br>- Map Area: shows a default location (Monaco / ETSI headquarters - TBD)<br>- Configuration area: Network drop-down is enabled (no network selected), all other controls disabled<br>- API Console: MEC API dropdown is enabled, selecting another API updates the "Try-It from your MEC Application" URL \|Click to enlarge<br>![SBox03](SBox03.png)
		\| SBox04 \| User Sandbox - Configuration Area<br>- Selecting a scenario starts the execution & enables other controls<br>- _Pause_ - Dinamically start/stop UE movement<br>- _Stationary UE selector_ - Dynamically pick number of UEs (camera,sensor,etc.)- Default 1, Max TBD<br>- _Low Velocity UE_- Dynamically pick number UEs (pedestrian) - Default 1, Max TBD<br>- _High Velocity UE_- Pick number UEs (car) - Default 1, Max TBD\|Click to enlarge<br>![SBox04](SBox04.png)
		\| SBox05a \| User Sandbox - API Console - Try-It portion<br>- _MEC API dropdown_ select a supported MEC API - influence both Try-it links<br>- _Try-It in the browser_ - Link opens a Swagger UI window configured for the current user sandbox<br>- _Try-It in your MEC Application_ - Shows the link to use from the ME App to reach the selected service in the user sandbox\|Click to enlarge<br>![SBox05a](SBox05a.png)
		\| SBox05b \| User Sandbox - API Console - Monitoring portion<br>- _MEC API dropdown_ filters content of Query & Notification monitoring windows<br>- _Query/Response area_ - shows query/responses of the selected MEC Service<br>- _Notification Area_ - shows notification callbacks sent by the selected MEC Service<br>- _View Data_ - message is shown in JSON format \|Click to enlarge<br>![SBox05b](SBox05b.png)
		\| SBox01 \| Landing page<br>- Presents information about the MEC sandbox (Home - default), Help and Sign In buttons<br>- Sandbox is disabled<br>- Clicking on ETSI logo: redirects to `https://forge.etsi.org/`<br>- clicking on Help: provides help options (Webinar, Wiki, Slack, Report an Issue) <br>- Clicking on Sign In: user is presented with choice of GitHub or GitLab (EOL Account) OAuth provider & redirected to the selected provider sign in page \|Click to enlarge<br>![SBox01](SBox01.png)
		\| SBox02 \| Landing Page - Post sign in<br>- Sign in button changes to "user meatball"<br>- Clicking on meatball allows to sign out <br>- Sandbox menu is activated<br>- User Sandbox is automatically selected & transitions to SBox03 \|Click to enlarge<br>![SBox02](SBox02.png#)
		\| SBox03 \| User Sandbox<br>- Sandbox is shown in main area - with a Map, Configuration and API Console area<br>- Map Area: shows a default location (Monaco)<br>- Configuration area: Network drop-down is enabled (no network selected), all other controls disabled<br>- API Console: MEC API dropdown is enabled, selecting another API updates the "Try-It from your MEC Application" URL \|Click to enlarge<br>![SBox03](SBox03.png#)
		\| SBox04 \| User Sandbox - Configuration Area<br>- Selecting a scenario starts the execution & enables other controls<br>- _Pause_ - Dinamically start/stop UE movement<br>- _Stationary UE selector_ - Dynamically pick number of UEs (camera,sensor,etc.)- Default 1, Max 4<br>- _Low Velocity UE_- Dynamically pick number UEs (pedestrian) - Default 1, Max 4<br>- _High Velocity UE_- Pick number UEs (car) - Default 1, Max 4 <br><br>New STF599 <br>- `Dual-MEP` scenario includes two MEC Platforms each running a localized one instance of Location service (MEC013) <br>- Application Instance ID controls: user creates Application Instance ID(s) for its ME App(s) _(needed for MEC011 API)_\| Click to enlarge<br>![SBox04](SBox04.png)
		\| SBox05a \| User Sandbox - API Console - Try-It portion<br>- _MEC API dropdown_ select a supported MEC API - influence both Try-it links<br>- _Try-It in the browser_ - Link opens a Swagger UI window configured for the current user sandbox<br>- _Try-It in your MEC Application_ - Shows the link to use from the ME App to reach the selected service in the user sandbox <br><br>New STF599 <br>- Application Support API (MEC011) <br> - Service Management API (MEC011)\|Click to enlarge<br>![SBox05a](SBox05a.png##)
		\| SBox05b \| User Sandbox - API Console - Monitoring portion<br>- _API Console messages area_ - shows query/responses/notifications of all services<br>- Clicking on amessage shows it in JSON format \|Click to enlarge<br>![SBox05b](SBox05b.png##)

Admin message