Update README.md

# Sandbox User Interface

## User interaction definition

This section describes the type of interactions that a user may have with the MEC Sandbox

## High Level User Interactions

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>

> _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

_Sandbox Scenario configuration & control happens from the browser portal_

> _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

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

#####  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_

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

It is expected that user manually configures its ME App with MEC Service endpoints path_

* Present MEC Service endpoint configuration information to the user

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

#####  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_

> _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

## User Interaction Stories

| 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:<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. |

| 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<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 [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<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|