wireframe update

# MEC Sandbox Scenarios

This project includes material related to defining the MEC Sandbox Scenarios & User Interface.

This project includes material related to defining the MEC Sandbox Scenarios.  A Sandbox Scenario defines context, edge configuraiton, and behavior that a Sandbox user will experience in the MEC Sandbox (for example, context and configuration = Mobile Network Operator Macro Network in a city).

> _A Sandbox Scenario defines network context, edge configuration, and behavior that a Sandbox user will experience in the MEC Sandbox<br>

> for example, context & configuration = 5G Mobile Network Operator Macro Network in Monaco_

This material is intended to explore and refine how the MEC Sandbox will operate between the STF587 team and the STF Steering Committee, before committing development effort.

This material is intended to present, explore and refine MEC Sandbox direction between STF587 development team and the STF Steering Committee, before committing development effort.

Sandbox Scenarios are captured in dedicated sub-folders, named for the scenario.  Each scenario's root begins in the README.md file in each folder.  These include:

* [MEC Sandbox - Macro Network City Scenario - Monaco](https://forge.etsi.org/rep/stf-587/mec-sandbox-scenarios/blob/master/Macro-Network-Scenario/README.md)

* [MEC Sandbox - Micro Network Indoor Scenario - for future consideration](https://forge.etsi.org/rep/stf-587/mec-sandbox-scenarios/blob/master/Micro-Network-Scenario/README.md)

In addition to the scenario material, this project also includes other supporting information (e.g. MEC Sandbox UI wireframes).

Sandbox Scenarios and user interface details are captured in the following dedicated sub-folders.<br>

* [MEC Sandbox Scenario - Macro Network City Scenario - Monaco](https://forge.etsi.org/rep/stf-587/mec-sandbox-scenarios/blob/master/Macro-Network-Scenario/README.md)

* [MEC Sandbox Scenario - Micro Network Indoor Scenario - for future consideration](https://forge.etsi.org/rep/stf-587/mec-sandbox-scenarios/blob/master/Micro-Network-Scenario/README.md)

* [MEC Sandbox User Interface & Wireframe ](https://forge.etsi.org/rep/stf-587/mec-sandbox-scenarios/tree/master/Sandbox-User-Interface)

Please refer any questions to the STF587 team:  STF587@groups.etsi.org

# Sandbox User Interface

## What is type of activity is needed in the Sandbox User Interface?

## User interaction definition

This section describes the 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

##### 1. User Access and Authentication -__

   * Sign-up for the Sandbox

   * Log-in & Log-out of the Sandbox Portal

   * Starting & Terminating a Sandbox "Session"

##### 2. Configuration, Control & State

_Sandbox Scenario configuration & control happens from the browser portal_

* Configure Sandbox Scenario (see scenario definitions for specific configuration points)

* Start, pause, terminate, and restart Sandbox Scenario

* Observe Sandbox Scenario state (terminals, map, PoA location, UE location, etc.)

##### 2. Configuration & Control -__

   * Setting user sandbox configuration points (see scenario definitions for specific configuration points)

   * Starting, pausing, terminating (i.e. stopping), and restarting sandbox scenarios

   * Closing a user sandbox session   

#####  3. "Try-it" from External MEC Client application

_External MEC Client is a sandbox user's ME App executing in the user's own environment<br>

It is expected that a sandbox user manually configures the MEC Service endpoints information into their ME App_

* Present MEC Service endpoint configuration information to the user

* Observe MEC Service endpoint interactions from the portal (e.g. requests/responses/notifications)

#####  3. External MEC Client -

   * External MEC Client is a sandbox user's ME App in the user's own environment.  

   * The sandbox user's ME app client needs to be configured to access MEC Service API endpoints in their sandbox scenario.

   * Sandbox displays MEC Service endpoints information (URL/UUID); a Sandbox User can configure the endpoints into their environment (cut & paste)

   * Sandbox Configuration/Control endpoints are not exposed (e.g. start, pause, stop, restart) to external clients

#####  4. Browser-based MEC Client ("Try-It") -

   * The Browser-based Client allows a sandbox user to observe and learn about MEC Service API endpoints without providing a sandbox external MEC client.  

   *  Provides visibility on the scenario state:  number of terminals, current location, connection state, etc.

   * Sandbox User can invoke scenario endpoints from the browser (e.g. "Try-it" functionality)

   User can observe the MEC Service responses / notifications in the browser

   * Includes supporting graphics (e.g. map with PoA and terminal locations)

   * Sandbox User can correlate responses from their External MEC Client and the Browser-based client

#####  4. "Try-it" from Browser MEC Client application

_Browser can be used as a MEC Client to facilitate experimentation when an External MEC Client is not available_

* Exercise MEC Service endpoints from the browser

* Observe MEC Service endpoint interactions in the portal (e.g. requests/responses/notifications)

## UI Operation User Stories

| Operation | User Story(s) | Notes |

|---------- | --------------------------------------- | ----- |

| Access | As a Sandbox User...<br>   <br> ...I want to access the sandbox in an isolated setting from other users, using my "ETSI Forge Dev" account to identify me.   <br><br>... I can sign-in with my "ETSI Forge Dev" account from the Sandbox Landing Page.  <br><br> ... I can start my user sandbox after I have already signed-in to my "ETSI Forge Dev" account.  <br> <br> ... I can start my user sandbox immediately if I am already signed in to "ETSI Forge Dev" <br> <br>... I want my sandbox instance to be terminated with no state retained when I sign-out from my "ETSI Forge Dev" account. | **OPEN --> "ETSI Forge Dev" account information needed.** <br> <br>  STF assume that Forge will provide:  user signup, user authentication, HTTPS certificates, and authentication access tokens (that the Sandbox can use to identify and isolate users)  

| Configuration | As a Sandbox User... <br> <br>... I want to select a Sandbox Scenario (e.g. Macro Network - City Scenario vs. Micro Network - Indoor Scenario) that is executed in my sandbox.  <br> <br>... I want to configure my selected scenario (e.g. the  number and type of terminals that are present in my sandbox scenario).  | See Sandbox Scenario Definitions (and UI wireframes) for configuration points.  |

| Control | As a Sandbox User... <br><br>... I want to _**start**_ my sandbox scenario, i.e. emulated terminals placed their initial locations and start moving.  MEC Service API endpoints return valid data.  <br><br>... I want MEC Service API endpoints to return valid information reflecting the state of my sandbox scenario, as long as my sandbox is running.  <br><br>... I want to _**pause**_ my sandbox execution at any moment to observe MEC Service API endpoint results, while paused. All dynamic sandbox operation "pauses" (e.g. movement of terminals).  However, MEC Service endpoints continue to return valid data. I can _**resume**_ at any moment after pause and dynamic operation resumes (e.g. terminals start moving from their paused positions).  <br><br>... I want to _**restart**_ my sandbox scenario at any moment. My sandbox scenario returns to its initial state with no state retained and begins "fresh" as on first start.  <br><br>... I want _**terminate**_ my sandbox scenario.  No state is retained.  I can select a new scenario or re-configure my previously selected scenario.  <br><br>... I want all  MEC Service API endpoints & resources within my scenario to be destroyed when my user sandbox is terminated.| See Sandbox UI wireframes for more information. |

| External MEC Client | As a Sandbox User... <br><br>... I want to learn where to reach  MEC Service API endpoints within the sandbox when my user scenario (or session) is created.  So, I can program or configure the sandbox endpoints into my environment.  <br><br>... I want Sandbox MEC Service API endpoints to return valid information, reflecting the state of my selected scenario as long as my sandbox scenario is running.  <br><br>... I want the MEC Service API endpoints that the sandbox provides to remain consistent (i.e. URL, UUID): (1) within a MEC sandbox log-in session, (2) across MEC sandbox log-in sessions. So, I don't need to update my environment between sandbox sessions or scenario executions.| Questions:  <br><br> - Sandbox API endpoints consistent across sandbox access (i.e. log-in sessions)?  <br><br> - Can the endpoints be isolated with a UUID and access token or similar? <br><br> - Subscription Notifications will require the Sandbox User to provide input URLs that the Sandbox can call.  Users may be behind firewalls, NAT's, etc.  What can be expected or required of users to receive not in External MEC CLients?  <br><br>  **OPEN -->  Support for External MEC Clients and requirements to put on Sandbox Users.**    |

| Browser-based MEC Client - "Try-it" | As a Sandbox User... <br><br>... I want to exercise MEC Service API endpoints _**without having to create my own environment (i.e. ME App)**_ to learn how MEC Services APIs behave without requiring an External MEC Client (i.e. such as a "Try-it"-like browser interface).  <br><br>... I want to observe the current state of my sandbox scenario and compare it with values returned from Sandbox MEC Service API endpoints, which I observe in my External MEC Client.  <br><br>... I want to observe how notification endpoints work and the values that they return.| MEC Service Notifications could be supported with the notification endpoints hosted within the sandbox, when conditions make it impossible with External MEC Clients.  <br><br> MEC Sandbox users can observe notification in a browser interface, while simultaneously receiving the notifications in their External MEC Client.  <br><br>  Model or utilize a "swagger" type interface:  Sandbox User can enter parameter values and see API responses in "text windows"  <br><br>  Browser-based client includes supporting graphics.  See Concept - MEC "Try-It" Browser-based Client below.   |

| 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:<li>HTTPS certificate<li>Global DNS MEC Sandbox registration<li>user signup & authentication code/integration instructions<li>authentication token (TBD - required?)

| 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 Sandbox Scenario Definitions & UI wireframes for configuration points|

| Control | As a Sandbox User...<br><br>... I can **start** my sandbox scenario<li>emulated terminals start moving<li>MEC Service APIs endpoints return valid data<li>etc.<br><br>... I can **observe** execution state of my scenario in real-time<li>UE location on the map<li>PoA location on the map<li>etc.<br><br>... I can **pause** scenario execution at any moment to statically observe MEC Service API endpoint results<li>UEs stop moving<li>MEC Service endpoints return valid data<br><br>... I can **resume** scenario execution<li>terminals start moving from their current position<br><br>... I can **restart** scenario execution<li>UEs return to their initial position<li>no state is retained & scenario starts"fresh"<br><br>... I can **terminate** scenario execution<li>no state is retained<li>selecting another scenario terminates current| See Sandbox UI wireframes 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<li>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<li>REST request/responses/notifications<li>facilitate debugging/observability<li>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> <li>Should sandbox API endpoints stay consistent across sandbox access (i.e. log-in sessions)?<li>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?<li>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<li>REST request/responses/notifications<li>facilitate observability<br><br>... I can **compare** API response/notifications shown in the browser with the current state of my scenario|<li>Swagger UI client (same as Forge) to trigger requests & responses<li>SwaggerUI client configured to communicate with user sandbox<li>Notification callbacks can be observed in UI Notifications window|

## MEC Sandbox Wireframe

| Id | Notes | Wireframe|

|---------- | --------------------------------------- | ----- |

| SBox01 | MEC Sandbox landing page<li>Presents information about the MEC sandbox & opportunity to sign in<li>User Sandbox is disabled on the sidebar<li>Clicking on ETSI logo: redirects to `https://forge.etsi.org/`<li>Clicking on sign in:  user is redirected to the "ETSI Forge Dev" sign in page -- TBD<li>Footer is the same as the one seen on `https://forge.etsi.org/`  |![SBox01](SBox01.png)

| SBox02 | Post sign in<li>Sign in button changes to sign out<li>User sandbox link in the sidebar becomes activated | ![SBox02](SBox02.png)

| SBox03 | User selects the “User Sandbox” in the sidebar<li>Sandbox is shown in main area - with a Map, Configuration and API Console area<li>Map Area: shows a default location (Monaco / ETSI headquarters - TBD)<li>Configuration area: Network drop-down is enabled (no network selected), all other controls disabled<li>API Console: MEC API dropdown is enabled, selecting another API updates the "Try-It from your MEC Application" URL |![SBox03](SBox03.png)

| SBox04 | Configuration Area<li>Selecting a scenario starts the execution & enables other controls<li>**Pause** - Dinamically start/stop UE movement<li>**Stationary UE selector** - Dynamically pick number of UEs (camera,sensor,etc.)- Default 1, Max TBD<li>**Low Velocity UE**-  Dynamically pick number UEs (pedestrian) - Default 1, Max TBD<li>**High Velocity UE**- Pick number UEs (car) - Default 1, Max TBD|![SBox04](SBox04.png)

| SBox05a | API Console - Try-It portion<li>**MEC API dropdown** select a supported MEC API - influence both Try-it links<li>**Try-It in the browser** - Link opens a Swagger UI window configured for the current user sandbox<li>**Try-It in your MEC Application** - Shows the link to use from the ME App t reach the selected service in the user sandbox| ![SBox05a](SBox05a.png)

| SBox05b | API Console - Monitoring portion<li>**Query/Response area** - shows query/responses of the selected MEC Service<li>**Notification Area** - shows notification callbacks sent by the selected MEC Service<li>**View Data** -  Pop-up window shows the message body in JSON format (can be copied)| ![SBox05b](SBox05b.png)

## Concept - MEC "Try-It" Browser-based Client

## THIS NEEDS UPDATE -- Concept - MEC "Try-It" Browser-based Client

Macro Network Map

![Concept Map](Concept-MEC-TryIt-Client-Map.png)