| [/queries/uu_unicast_provisioning_info](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/raw/v2.2.1/MEC030_V2XInformationService.yaml#/queries/prov_info_uu_unicastGET) | GET - Retrieve provisioning information for V2X communication over Uu unicast.| As a MEC Sandbox user, I use this endpoint to retrieve provisioning information required for V2X communication over Uu unicast based on the _location_info_.
| [/provide_predicted_qos](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/raw/v2.2.1/MEC030_V2XInformationService.yaml#/QoS/predicted_qosPOST)<br><br>This resource is queried to provide predicted QoS of a vehicular UE based on potential route information. Each UE may have different potential routes under consideration. Route information includes route origin and destination; intermediate waypoints may also be provided. Estimated journey start time and arrival time at each location may also be provided. | Input is a set of potential routes that a vehicle may consider for a journey. <br><br> Note: potential routes having the same origin and destination, journey start time and differing intermediate waypoints may be considered as alternatives of a specific journey. <br><br> Output is the predicted QoS, in the form of Reference Signal Received Power (RSRP) and/or Reference Signal Received Quality (RSRQ), as defined in ETSI TS 136 214. The network emulation algorithms used to calculate RSRP and RSRQ for MEC 012 RNIS are used to caluclate perdicted QoS for MEC 030. | As a Sandbox user, I can use this call to receive predictions of the radio signal conditions expected to be experienced during journey time for different potential routes I may consider (for the same trip or for different planned trips). <br><br> The Sandbox has an internal Prediction Function (PF) which receives route information (route locations, optionally with visiting time information) as input and provides predicted RSRP and RSRQ values for each location of the communicated potential route as output. <br><br> The Prediction Function considers diurnal traffic patterns for each zone based on estimated user activity in those areas throughout the day and the predicted QoS values are adjusted accordingly if the visiting time information is also provided in the request depending on the congestion status in those areas around the requested time.
| [/publish_v2x_message](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/raw/v2.2.1/MEC030_V2XInformationService.yaml#/V2X_msg/v2x_messagePOST) | POST - Used to publish a V2X message by a service consumer (e.g. a MEC application or a MEC platform) to VIS to notify the subscribed service consumers. | As a MEC Sandbox user, I use this endpoint to publish a V2X message to VIS who will then notify the subscribed service consumers.
| [/subscriptions](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/raw/v2.2.1/MEC030_V2XInformationService.yaml#/subscription) | GET - Retrieve information about a list of subscriptions. <br><br> Query input: <ul><li> subscription_type: Query parameter to filter on a specific subscription type (supported values are prov_chg_uu_uni and v2x_msg). <li> If query parameter is not passed, it returns with the list of all the subscriptions. </ul><br> POST - Create a specific subscription type (supported subscription types are ProvChgUuUniSubscription, and V2xMsgSubscription). <br><br> Returns subscriptions along with _href_ which identifies each subscription uniquely. | As a MEC Sandbox user, I use this endpoint to list down all the subscriotions with/without using query parameters. <br><br> As a MEC Sandbox user, I use this endpoint to create a subscription based on subscription type (supported values are ProvChgUuUniSubscription, and V2xMsgSubscription), callbackReference, and filterCriteria. |
| [/subscriptions/{subscriptionId}](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/raw/v2.2.1/MEC030_V2XInformationService.yaml#/subscription) | GET - Retrieve information about a specific subscription. <br><br> Returns specific subscription resource. <br><br> PUT - Update the information about a specific subscription. <br><br> Returns an updated subscription resource. <br><br> DELETE - Remove a specific subscription | <br><br>**As a MEC Sandbox user, I use this endpoint to retrieve/update/delete a specific subscription resource**<br><br> As a MEC Sandbox user, I use this endpoint to retrieve subscription resource by providing a specific subscriptionId. <br><br> As a MEC Sandbox user, I use this endpoint to update/replace a subscription by providing a specific subscriptionId with the requested changes of supported subscription type. <br><br> As a MEC Sandbox user, I use this endpoint to delete subscription resource of specific subscriptionId.
No newline at end of file
| [/queries/uu_unicast_provisioning_info](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/-/blob/master/MEC030_V2XInformationServices.yaml#/queries/prov_info_uu_unicastGET) | GET - Retrieve provisioning information for V2X communication over Uu unicast.| As a MEC Sandbox user, I use this endpoint to retrieve provisioning information required for V2X communication over Uu unicast based on the _location_info_.
| [/queries/uu_mbms_provisioning_info](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/-/blob/master/MEC030_V2XInformationServices.yaml#/queries/prov_info_uu_mbmsGET) | GET - Retrieve provisioning information for V2X communication over Uu unicast.| As a MEC Sandbox user, I use this endpoint to retrieve provisioning information required for V2X communication over MBMS based on the _location_info_.
| [/queries/pc5_provisioning_info](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/-/blob/master/MEC030_V2XInformationServices.yaml#/queries/prov_infoGET) | GET - Retrieve provisioning information for V2X communication over Uu unicast.| As a MEC Sandbox user, I use this endpoint to retrieve provisioning information required for V2X communication over PC5 based on the _location_info_.
| [/provide_v2x_msg_distribution_server_info](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/-/blob/master/MEC030_V2XInformationServices.yaml#/queries/v2xMsg_distributionServerPost) | POST - Request the information about available V2X Message Distribution Servers that can be supported by the service consumer (e.g. a MEC application).
| [/provide_predicted_qos](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/-/blob/master/MEC030_V2XInformationServices.yaml#/QoS/predicted_qosPOST)<br><br>This resource is queried to provide predicted QoS of a vehicular UE based on potential route information. Each UE may have different potential routes under consideration. Route information includes route origin and destination; intermediate waypoints may also be provided. Estimated journey start time and arrival time at each location may also be provided. | Input is a set of potential routes that a vehicle may consider for a journey. <br><br> Note: potential routes having the same origin and destination, journey start time and differing intermediate waypoints may be considered as alternatives of a specific journey. <br><br> Output is the predicted QoS, in the form of Reference Signal Received Power (RSRP) and/or Reference Signal Received Quality (RSRQ), as defined in ETSI TS 136 214. The network emulation algorithms used to calculate RSRP and RSRQ for MEC 012 RNIS are used to caluclate perdicted QoS for MEC 030. | As a Sandbox user, I can use this call to receive predictions of the radio signal conditions expected to be experienced during journey time for different potential routes I may consider (for the same trip or for different planned trips). <br><br> The Sandbox has an internal Prediction Function (PF) which receives route information (route locations, optionally with visiting time information) as input and provides predicted RSRP and RSRQ values for each location of the communicated potential route as output. <br><br> The Prediction Function considers diurnal traffic patterns for each zone based on estimated user activity in those areas throughout the day and the predicted QoS values are adjusted accordingly if the visiting time information is also provided in the request depending on the congestion status in those areas around the requested time.
| [/publish_v2x_message](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/-/blob/master/MEC030_V2XInformationServices.yaml#/V2X_msg/v2x_messagePOST) | POST - Used to publish a V2X message by a service consumer (e.g. a MEC application or a MEC platform) to VIS to notify the subscribed service consumers. | As a MEC Sandbox user, I use this endpoint to publish a V2X message to VIS who will then notify the subscribed service consumers.
| [/subscriptions](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/-/blob/master/MEC030_V2XInformationServices.yaml#/subscription) | GET - Retrieve information about a list of subscriptions. <br><br> Query input: <ul><li> subscription_type: Query parameter to filter on a specific subscription type (supported values are prov_chg_uu_uni and v2x_msg). <li> If query parameter is not passed, it returns with the list of all the subscriptions. </ul><br> POST - Create a specific subscription type (supported subscription types are ProvChgUuUniSubscription, and V2xMsgSubscription). <br><br> Returns subscriptions along with _href_ which identifies each subscription uniquely. | As a MEC Sandbox user, I use this endpoint to list down all the subscriotions with/without using query parameters. <br><br> As a MEC Sandbox user, I use this endpoint to create a subscription based on subscription type (supported values are ProvChgUuUniSubscription, and V2xMsgSubscription), callbackReference, and filterCriteria. |
| [/subscriptions/{subscriptionId}](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/rep/mec/gs030-vis-api/-/blob/master/MEC030_V2XInformationServices.yaml#/subscription) | GET - Retrieve information about a specific subscription. <br><br> Returns specific subscription resource. <br><br> PUT - Update the information about a specific subscription. <br><br> Returns an updated subscription resource. <br><br> DELETE - Remove a specific subscription | <br><br>**As a MEC Sandbox user, I use this endpoint to retrieve/update/delete a specific subscription resource**<br><br> As a MEC Sandbox user, I use this endpoint to retrieve subscription resource by providing a specific subscriptionId. <br><br> As a MEC Sandbox user, I use this endpoint to update/replace a subscription by providing a specific subscriptionId with the requested changes of supported subscription type. <br><br> As a MEC Sandbox user, I use this endpoint to delete subscription resource of specific subscriptionId.
| 1. Login via the frontend & select Sandbox tab | |
| 2. Select a network to deploy in the user sandbox | |
| 3a. Pre-configure MEC 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` |
| 3a. Pre-configure MEC Application with Application Enablement service endpoints | Endpoints: <br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v2`<br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` |
| 3b. Pre-configure MEC 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 |
| 4a. Start MEC Application or environment | MEC Application knows nothing about available MEC services <br><br> In the following steps, MEC Application will learn MEC services availability via Mp1 interface |
| 4b. `POST .../applications/{appInstanceId}/confirm_ready` | MEC Application first needs to report that it is ready to Mp1, this is a pre-requisite to step 6 for creating a subscription. |
| 1. Login via the frontend & select Sandbox tab | |
| 2. Select a network to deploy in the user sandbox | |
| 3a. Pre-configure MEC 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` |
| 3a. Pre-configure MEC Application with Application Enablement service endpoints | Endpoints: <br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_app_support/v2`<br>- `https://try-mec.etsi.org/<my-sandbox-key>/mec_service_mgmt/v1` |
| 3b. Pre-configure MEC 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 MEC Application or environment | In the following steps, MEC Application will register a service via Mp1 interface |
| 5. `POST .../applications/{appInstanceId}/confirm_ready` | MEC Application indicates readiness to the MEC platform |
| 1. Login via the frontend & select Sandbox tab | _See [frontend](../Sandbox-User-Interface#sbox01)_ |
| 2. Select the `dual-mep` network to deploy in the user sandbox | `dual-mep` scenario has `mep1` for Zone 1, 2 & 3 locality and `mep2` for Zone 4 locality <br><br> Each node runs an instance of Location service with its own dataset; RNIS & WAIS are MEC system wide services.
| 3b. Pre-configure MEC 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](../Sandbox-User-Interface#sbox04)<br><br> Generating the `appInstanceId` asks for the locality of the MEC Application (e.g. `mep1` or `mep2`)|
| 4. Start MEC Application or environment | MEC Application knows nothing about available MEC services <br><br> In the following steps, MEC Application will learn MEC available services via Mp1 interface |
| 5. `GET .../services` | MEC Application discovers there are 3 services available (Location/RNIS/WAIS) with their respective URIs <br><br> Location service URI corresponds to the locality of the MEC Application<br><br> MEC Application starts using discovered Location service. |
| 1. Login via the frontend & select Sandbox tab | _See [frontend](../Sandbox-User-Interface#mec-sandbox-wireframe#SBox01)_ |
| 2. Select the `dual-mep` network to deploy in the user sandbox | `dual-mep` scenario has `mep1` for Zone 1, 2 & 3 locality and `mep2` for Zone 4 locality |
| 3b. Pre-configure MEC Applications with an Application Instance ID (e.g. `appInstanceId`) <br><br> The user shall register 2 MEC Applications of the same type; one per MEP.| 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](../Sandbox-User-Interface#mec-sandbox-wireframe#SBox04)<br><br> Generating the `appInstanceId` asks for the locality of the MEC Application (e.g. `mep1` or `mep2`)|
| 4. Start MEC Applications or environment | MEC Application knows nothing about available MEC services <br><br> In the following steps, MEC Applications will learn MEC available services via Mp1 interface |
| 5. `GET .../services` via Mp1 | MEC Applications discovers the available services; one of which is AMS <br><br> MEC Application can use other available services as required. |
