| Access | As a Sandbox User...<br><br> ...I want to access the sandbox in an isolated setting from other users, using my "Forge Dev" account to identify me. <br><br>...I can sign-in with my "Forge Dev" account from the Sandbox landing page. <br><br> ...I can start my user sandbox after I'm already signed-in to me "Forge Dev" account. <br><br> ...I can start my user sandbox immediately if I am already signed in to "Forge Dev" <br><br>...I want my sandbox instance to be terminated with no state retained when I sign-out from my "Forge Dev" account. | "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 | | |
| Control | | |
| External MEC Client | | |
| Browser-based MEC Client - "Try-it" | | |
| 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. |
