MECwiki - User contributions [en]

MEC Ecosystem

2021-05-13T09:19:31Z

Carignani:

This page provides information very much related to the work of the ETSI ISG MEC Deployment and ECOsystem DEvelopment ([https://portal.etsi.org//tb.aspx?tbid=874&SubTB=874#/ DECODE]) Working Group, whose aim is to accelerate the development of the MEC ecosystem:
*[https://forge.etsi.org/ '''Forge Projects''']: Includes OpenAPI/Swagger & Protobuf descriptions of the APIs specified by ISG MEC.
**[https://mecwiki.etsi.org/index.php?title=OpenAPI_development_guidelines OpenAPI development guidelines]: How can I contribute to the API development?
*'''[https://try-mec.etsi.org/ MEC Sandbox]''': MEC Service API playground
**[https://forge.etsi.org/rep/stf-587/mec-sandbox-scenarios MEC Sandbox Scenarios] (EOL account required): Macro/micro network emulation scenarios
*'''[https://mecwiki.etsi.org/index.php?title=MEC_Ecosystem#MEC_Applications MEC Applications]''': 3rd party solutions
*'''[[MEC Ecosystem#MEC Solutions|MEC Solutions]]''': 3rd party solutions

== MEC Applications ==
List of MEC Applications made available by third parties
{| class="wikitable"
|+
!Name of the App & logo
!Description
!MEC Consumed APIs
!MEC API provided
!Link
!Contact
|-
|'''Unibo MEC API Tester'''[[File:Unibo mec api tester.png|center|frameless|200x200px]]
|The Unibo MEC API Tester is a web-based application that can be used to test the capability of a MEC Platform to support the MEC 011 defined APIs (mec_app_support & mec_service_mgmt).
|MEC 011 (Mp1)
|NA
|[https://github.com/berdav/unibo-test-mec Link]
|[mailto:davide.berardi6@unibo.it Davide Berardi]
|}

== MEC Solutions ==

List of MEC Solutions made available by third parties (in alphabetical order). Such solutions may offer all components (functional entities) of the [https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/02.01.01_60/gs_MEC003v020101p.pdf MEC architecture], or a subset (for instance a MEC Platform, or API implementation).

{| class="wikitable"
|+
!Name of the project & logo
!Description
!MEC Components provided
!MEC APIs supported
!Link
!Contact
|-
|'''AdvantEdge''' [[File:advantedge.png|center|frameless|200x200px]]
|AdvantEDGE is a Mobile Edge Emulation Platform (MEEP) that runs on Docker & Kubernetes. AdvantEDGE provides an emulation environment, enabling experimentation with Edge Computing Technologies, Applications, and Services. The platform facilitates exploring edge / fog deployment models and their impact on applications and services in short and agile iterations.
|MEC Platform
| MEC 012 Radio Network Information<br />MEC 013 Location<br />MEC 028 WLAN Information
|[https://github.com/InterDigitalInc/AdvantEDGE Link]
|[mailto:AdvantEDGE@InterDigital.com AdvantEDGE]
|-
|'''Connected Vehicle Blueprint (Aka CVB)''' [[File:akraino.png|center|frameless|200x200px]]
|CVB provides a V2X focused MEC platform, which offers services to connected vehicles. These services are delivered to applications hosted on vehicles based on a set of policies for data dispatch and response. As the blueprint continues to be developed, further connected-vehicle applications and services are being incorporated into the blueprint.
|MEC Platform(s), MEC Platform Manager
|MEC 011 Mp1 & Mm5
|[https://wiki.akraino.org/pages/viewpage.action?pageId=9601601 Link]
|[mailto:yargyang@tencent.com Yarg Yang]
|-
|'''Eclipse zenoh''' [[File:zenoh.png|center|frameless|200x200px]]
|Eclipse zenoh unifies data in motion, data in-use, data at rest and computations. It carefully blends traditional pub/sub with geo-distributed storages, queries and computations, while retaining a level of time and space efficiency that is well beyond any of the mainstream stacks. It is a perfect fit as an alternative transport protocol for MEC applications as well as technological stack to build distributed MEC platforms.
|Alternative transport protocol for MEC Platform
|MEC 011 Mp1
|[http://zenoh.io/ Link]
|[https://gitter.im/atolab/zenoh Gitter community channel]
|-
|'''EdgeGallery''' [[File:Edgegallery.png|center|frameless|200x200px]]
|The EdgeGallery community focuses on providing a MEC platform framework at a carrier’s network edge, whilst adopting the de facto standard of network service openness through open source collaboration. The framework enables MEC edge resources and applications, whilst providing both security and management capabilities. It also offers interconnectivity with the public cloud. The result is the creation of unified MEC application ecosystem, which is designed to be compatible across a carrier’s heterogeneous edge infrastructure.
|MEC Open Source Platform
|MEC 010-2，MEC 011，MEC 009，and will support more ETSI APIs in further releases
|[https://www.edgegallery.org/en/ Link]
|[https://edgegallery.groups.io/g/main Maillist]
|-
|'''Enterprise Applications on Lightweight 5G Telco Edge (EALTEdge)''' [[File:akraino.png|center|frameless|200x200px]]
|Lightweight telco edge platform, enabling Enterprise applications on telco edge. Offering a: Unified Portal for platform management and for App developers; Sandbox with SDKs and tools chains for MEC app developers; Heterogeneous deployment on Multi-Arch; ETSI MEC Compliance.
|MEC Platform(s), MEC Platform Manager
|MEC 011 Mp1 & Mm3
|[https://wiki.akraino.org/display/AK/Enterprise+Applications+on+Lightweight+5G+Telco+Edge Link]
|[Mailto:gaurav.agrawal@huawei.com Gaurav Agrawal]
|-
|'''i-MEC''' [[File:Italtel RGB.jpg|center|frameless|200x200px]]
|Italtel MEC platform i-MEC brings high value in the network enabling a wide set of services which leverage reduced end-to-end latency (uRLLC), pre-processing at the edge (mMTC) and broadband services (eMBB). i-MEC contributes to reduce the traffic load on the backhauling transport network with relevant saving of cost for the Service Operator.
|MEC Platform
|MEC011 Mp1, Mm5 proprietary API, Mp2 proprietary API (OpenFlow based)
|[https://www.italtel.com/products/multi-access-edge-computing-mec-platform/ Link]
|[Mailto:marketing_technology@italtel.com Italtel]
|-
|'''LightEdge''' [[File:lightedge-logo.png|center|frameless|150x150px]]
|LightEdge is a lightweight, ETSI-compliant MEC solution for 4G and 5G networks. It is designed to work natively on top of Kubernetes and is transparent to the existing components of a 4G network, therefore requiring zero modifications to the MNO’s environment.
| MEC Platform
| RNI (MEC-012), WIA (MEC-028), partially Application Enablement (MEC-011)
|[http://lightedge.github.io/ Link]
|[mailto:roberto.riggio@gmail.com Roberto Riggio]
|-
|'''MEC Location API Simulator''' [[File:LINKS_Logo.png|center|frameless|200x200px]]
|The Location API simulator helps developers to create applications that use MEC Location API. It provides a MEC Location Service accessible via Location API as specified in the ETSI GS MEC013 document, available as a RESTful web service. It has a Graphical User Interface enabling developers to simulate mobile users' movements by feeding the simulator with a GPS track in .gpx format. The first release implements a subset of MEC013 API but the full set of APIs and an improved engine to simulate cars, VRU and more will be part of future releases.
| MEC013 accessible APIs (with an engine to simulate mobile users’ movement)
| MEC 013 Location
|[https://networkbuilders.intel.com/commercial-applications/links-foundation Link]
|[mailto:daniele.brevi@linksfoundation.com Daniele Brevi]
|-
|'''Public Cloud Edge Interface (PCEI)''' [[File:akraino.png|center|frameless|200x200px]]
|The purpose of Public Cloud Edge Interface (PCEI) Blueprint family is to specify a set of open APIs for enabling Multi-Domain Inter-working across functional domains that provide Edge capabilities/applications and require close cooperation between the Mobile Edge, the Public Cloud Core and Edge, the 3rd-Party Edge functions as well as the underlying infrastructure such as Data Centers and Networks.
|Provides an enabler layer that facilitates interworking between Edge Computing platforms, including Multi-Access Edge Compute, Public Cloud and 3rd-Party Edge Compute, and Mobile Networks
|MEC 013 Location API
|[https://wiki.akraino.org/display/AK/Public+Cloud+Edge+Interface+%28PCEI%29+Blueprint+Family Link]
|[mailto:oberzin@equinix.com Oleg Berzin]
|-
|'''ServerlessOnEdge'''[[File:Logo-small.png|center|frameless|200x200px]]
|Decentralized framework for the distribution of lambda functions to multiple serverless platforms, with Apache OpenWhisk connectors, supporting the ETSI MEC Device application interface (MEC 016).
|User app LCM proxy
|MEC 016 Device application interface (Mx2)
|[https://github.com/ccicconetti/serverlessonedge Link]
|[Mailto:c.cicconetti@iit.cnr.it Claudio Cicconetti]
|-
|}

=== Request your project to be listed ===

<big>
A request to add a new entry to either the MEC Applications or MEC Solutions should be sent to please [Mailto:CTI_support@etsi.org?Subject=ISG+MEC+WIKI+Ecosystem+request contact ETSI CTI], with title "ISG MEC WIKI Ecosystem request".
<u>'''Any'''</u> organization (ETSI member or not) is entitled to send the request.
</big>

The request should contain the information to be included in the table. "Contact" in the table is not mandatory, but a contact point is required to allow communication of changes or future developments on the page.

The chairman of DECODE WG and ETSI Secretariat will review the proposal and publish it.

Criteria for the inclusion into the Ecosystem page are:
* The referenced activity is relevant to ETSI MEC i.e. it claims to implement at least one MEC Component from the MEC Architecture as defined in [https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/02.01.01_60/gs_MEC003v020101p.pdf ETSI GS MEC 003].
* The proposed description or text is not offensive and is fit for publication, in line with the purpose of the MEC wiki.

File:Edgegallery.png

2021-05-13T09:17:15Z

Carignani:

2021-04-01T08:24:39Z

Carignani:

MEC Sandbox Help

2021-03-12T09:41:23Z

Carignani: /* Discussion Board (Slack channels) */

= Platform Concepts =
MEC Sandbox is an interactive environment that enables users to learn & experiment with ETSI MEC Service APIs. These standardized RESTful APIs are targeted towards MEC application developers to expose the value added services offered by MEC, including real time access to network and context information, as well as location awareness. The design principles for developing the APIs have also been specified in ETSI GS MEC 009, along with http methods, templates, conventions and patterns. The MEC service APIs are available in YAML and JSON format at https://forge.etsi.org, presented via OpenAPI compliant descriptions.

MEC Sandbox provides the user with a choice of scenarios combining different network technologies (4G, 5G, Wi-Fi) and terminal types. Combining these assets in a geolocated environment, a user can gain hands-on experience on the behavior and capabilities of the Location (MEC013), Radio Network Information (MEC012) and WLAN Information (MEC028) service APIs. Such contextual information can offer significant differential performance for edge based MEC applications.

== MEC Sandbox Concepts & Usage ==
An introduction to MEC Sandbox concepts and usage was presented in a webinar (February 2021). The recording and related Q&A are available here:
* [https://www.etsi.org/events/1869-2021-01-webinar-getting-started-with-the-etsi-mec-sandbox MEC Sandbox Webinar]
* [https://mecsandbox.slack.com/archives/C01NBU36DU4 Q&A]

To access the Q&A users must first join the MEC Sandbox [[#Discussion_Board_.28Slack_channels.29|Discussion Board]].

== Web UI ==
MEC Sandbox Portal is a single page web application that provides an interactive interface; once signed in, it allows a user to experiment with an individual sandbox.

{| style="margin-top: 20px" |
|+
| style="width: 40%; min-width: 400px; vertical-align: top; padding-right: 20px;" |
'''Home Page'''

The home page provides:
* A brief description of the platform
* Links and references to learn more about ETSI MEC
* Control to:
** Navigate through the MEC Sandbox pages
** Open the help menu to get started or access this wiki page
** Sign in to the platform
| style="width: 60%; text-align: left;" |
[[File:Page-home.png|border|750px]]
|+
| style="width: 40%; min-width: 400px; vertical-align: top; padding-right: 20px;" |
'''Sandbox Dashboard'''

When a user signs in, the MEC Sandbox creates the necessary backend resources and opens a user-specific sandbox dashboard that allows to:
* Deploy pre-defined network scenarios in the city of Monaco
* Configure terminal devices within the network (add/remove/pause)
* Experiment with the MEC Service APIs by opening a MEC client directly in the browser
* Alternatively, experiment MEC Services directly from an external application ''(your own or a third party application)''
In both cases, MEC Sandbox APIs respond according to the current state of the network scenario.

More details about the MEC Sandbox UI are provided in the [[#Usage|platform usage]] section of this wiki.
| style="width: 60%; text-align: left;" |
[[File:Page-sandbox.png|border|750px]]
|}

== Terminology ==

==== Point of Access (POA) ====
A point of attachment to access a network; MEC Sandbox networks supports 4G, 5G and WiFi POAs.
* Each POA has coverage range within which a terminal may attach to the network.
* The PoA range is represented by a circle and its the range varies depending on the network technology
* Both the PoAs and their associated range can be shown or hidden by selecting the appropriate layers on the map.

==== User Equipment (UE) / Terminal Device ====
A end user devices equipped with a wireless radio that allows to connect to a PoA.
* MEC Sandbox supports three types of UEs; stationary, low-velocity and high-velocity
** UE types are described in more detail in [[#UE_Types|this]] wiki section.
* Number of UEs present in a scenario can be configured
* Each UE has an associated velocity and path that defines how they move on the map; these are fixed in a scenario.
* UEs have their preferred access network types with their preferred order of connection
* Preferred connectivity order is (1) WiFi, (2) 5G and (3) 4G
* The default UE behavior is to remain connected to a POA as long as it is in range unless a higher priority network access becomes available.

==== Zone ====
A zone is a logical grouping of one or more PoAs, irrespective of their wireless technologies.
* On the map, zones are represented by using color coding.
* The definition of zones help structure the network.
* MEC Location Service (MEC013) can be used to discover zones or UEs present in a zone.

==== Network Scenario ====
A simulated network of geo-located UEs and POAs that are grouped in Zones.
* One network scenario can be deployed at a time in a MEC Sandbox instance.
* At any time a user can terminate a scenario or select a new one without requiring to re-create a new sandbox.
* While a network scenario is deployed, requests can be sent to the MEC Service APIs which will return a response
* MEC Services may also generate notifications depending on the subscriptions created by the user
* Both responses and notifications reflect the state of the network at the moment they were generated

= Network Scenarios =

{| style="margin-top: 20px" |
|+
| style="width: 40%; min-width: 400px; vertical-align: top; padding-right: 20px;" |
MEC Sandbox currently provides three network scenarios with different assortments of technologies.
These scenarios were designed to simulate an urban environment using a single mobile network operator with combinations of 4G, 5G and WiFi PoAs.

UEs move along their pre-defined path, triggering changes in connectivity and in MEC Service outputs (responses & notifications).

The city of Monaco was chosen as the simulated location as shown on right.

'''NOTE:''' PoA position and range values are simulated and do not reproduce a real operator deployment in Monaco; they were chosen to optimize scenario coverage and zone transitions for simulation purposes.
| style="width: 60%; text-align: left;" |[[File:Monaco-3D-Satellite.png|border|750px]]
|}

== Networks ==
MEC Sandbox provides the following simulated networks

{|
|+
| style="width: 410px; vertical-align: top; padding: 20px;" |
==== 4G Macro Network ====
* Contains 10 4G-PoAs grouped into 4 different zones; together, these PoAs cover the entire Monaco area
| style="width: 410px; vertical-align: top; padding: 20px;" |
==== 4G-WiFi Macro Network ====
* Builds on 4G Macro Network by adding 11 WiFi-PoAs distributed throughout the city
| style="width: 410px; vertical-align: top; padding: 20px;" |
==== 4G-5G-WiFi Macro Network ====
* Builds on 4G-WiFi Macro Network by adding 19 small cell 5G-PoAs distributed throughout the city
|+
| style="width: 410px; vertical-align: top; text-align: left; padding-right: 8px;" |
[[File:Network-4g.png|border|395px]]
| style="width: 410px; vertical-align: top; text-align: left; padding-right: 8px;" |
[[File:Network-4g-wifi.png|border|395px]]
| style="width: 410px; vertical-align: top; text-align: left;" |
[[File:Network-4g-5g-wifi.png|border|395px]]
|}

== UE Types ==
UEs are divided into the following categories:

{|
|+
| style="width: 410px; vertical-align: top; padding: 20px;" |
==== Stationary UE ====
* They have a static geo location
* They represent smart city IoT connected devices such as street cameras, smart sensors, etc.
| style="width: 410px; vertical-align: top; padding: 20px;" |
==== Low Velocity UE ====
* They change location relatively slowly
* They represent leisure cyclists or pedestrians moving through the city
| style="width: 410px; vertical-align: top; padding: 20px;" |
==== High Velocity UE ====
* They change location quickly
* They represent motorized vehicles moving along the main city roads
|+
| style="width: 410px; vertical-align: top; text-align: left; padding-right: 8px;" |
[[File:Ue-stationary.png|border|395px]]
| style="width: 410px; vertical-align: top; text-align: left; padding-right: 8px;" |
[[File:Ue-low-velocity.png|border|395px]]
| style="width: 410px; vertical-align: top; text-align: left;" |
[[File:Ue-high-velocity.png|border|395px]]
|}

NOTE: The number of UEs in a network scenario is dynamically configurable, however the positions and paths are the same for all scenarios.

= MEC Services =

== MEC012 - Radio Network Information Service (RNIS) ==
MEC Sandbox supports version v02.01.01 of the MEC012 specification, available on [https://www.etsi.org/deliver/etsi_gs/MEC/001_099/012/02.01.01_60/gs_mec012v020101p.pdf ETSI website]

RNIS provides cellular radio network information to edge applications, such as:
* Radio network conditions
* Measurements related to user plane
* Information about UEs connected to the radio network (context, Radio Access Bearers (RAB))
* Notification events such as cell change, RAB establishment and RAB release
MEC Sandbox supports a subset of RNI API endpoints and subscription types; for more details on the supported endpoints access the SwaggerUI client in a MEC Sandbox.

== MEC013 - Location Service ==
MEC Sandbox supports version v02.01.01 of the MEC013 specification, available on [https://www.etsi.org/deliver/etsi_gs/MEC/001_099/013/02.01.01_60/gs_mec013v020101p.pdf ETSI website]

Location Service provides geospatial and network location information to edge applications, such as:
* Location information related to user and zones
* Notification events such as user tracking, zonal status or traffic
MEC Sandbox supports a subset of the Location API endpoints and subscription types; for more details on the supported endpoints access the SwaggerUI client in a MEC Sandbox.

== MEC028 - WLAN Access Information Service (WAIS) ==
MEC Sandbox supports version v02.01.01 of the MEC028 specifications, available on [https://www.etsi.org/deliver/etsi_gs/MEC/001_099/028/02.01.01_60/gs_mec028v020101p.pdf ETSI website]

WAIS provides WLAN radio network information to edge applications, such as:
* Access point conditions
* Information about terminals connected to the network
* Notification events such as terminal connectivity
MEC Sandbox supports a subset of the WAI API endpoints and subscription types. for more details on the supported endpoints access the SwaggerUI client in a MEC Sandbox.

= Usage =
The following section provides MEC Sandbox usage guidelines.

== Sign In ==

{| style="margin-top: 20px" |
|+
| style="width: 40%; min-width: 400px; vertical-align: top; padding-right: 20px;" |
The MEC Sandbox home page provides a ''Sign In'' button to initiate a user session.
When clicked, the user is prompted to authenticate with one of the following external OAuth 2.0 providers:
* GitHub: Sign in with a public GitHub account
* GitLab (ETSI): Sign in with an ETSI-On-Line (EOL) GitLab account

To successfully sign in to the MEC Sandbox, the user must have a valid account with one of the above providers,
must successfully sign in, and must accept an authorization request for access to public profile information.
Once signed in and after successful backend resource allocation, the user is redirected to the MEC Sandbox dashboard.
NOTE: External OAuth provider login and authorization may be seamless if they have already been performed
| style="width: 60%; text-align: left;" |
[[File:Sign-in.PNG|border|500px]]
|}

== MEC Sandbox Dashboard ==
The dashboard is the main screen of the MEC Sandbox; it is divided in 4 main areas that are explained below:
* Map area: Observe physical assets on the map
* Configuration area: Select networks and UEs
* API Console: Investigate MEC API communication
* Try-it area: Details about accessing MEC Service APIs

{| style="margin-top: 20px" |
|+
| style="width: 40%; min-width: 400px; vertical-align: top; padding-right: 20px;" |
==== Map Area ====
Map area allows to observe the location of different assets; it provides the following information and capabilities:
* Zoom control
* Layer selection - display or hide assets
* PoAs
** Icon shows the type of PoA (4G/5G/WiFi)
** Clicking provides details
** PoAs are color coded according to their zone
** Circle surrounding the PoA represents the signal range - also color coded to the zone
* UEs
** Icon shows UE type (stationary/low/high velocity)
** Clicking provides details
** UEs are red when disconnected, blue otherwise
| style="width: 60%; text-align: left;" |
[[File:Map.png|border|750px]]
|+
| style="width: 40%; min-width: 400px; vertical-align: top; padding-right: 20px;" |
==== Configuration area ====
Configuration area allows dynamic configuration of the MEC Sandbox; it provides the following capabilities:
* Network selection - deploy/terminate network scenarios
* Pause terminal movement - dynamically start/stop UE movement
* Set the number of terminals - dynamically add/remove UEs by type
| style="width: 60%; text-align: left;" |
[[File:Configuration.png|border|500px]]
|+
| style="width: 40%; min-width: 400px; vertical-align: top; padding-right: 20px;" |
==== API Console ====
API console displays a table of real-time requests and notifications that the MEC Service APIs receive and generate.

The table provides a summary of the communication messages, including type (request/notification), service involved, endpoint, HTTP method, time and response code.

Requests are HTTP messages received by the MEC Service
* Click on the request line in the table to see the response returned by the MEC Service

Notifications are HTTP message sent by the MEC Service
* These are generated only if a subscription was created in the MEC Service
* Click on the notification line in the table to see details about notification and received response
| style="width: 60%; text-align: left;" |
[[File:Api-console.png|border|750px]]
|+
| style="width: 40%; min-width: 400px; vertical-align: top; padding-right: 20px;" |
==== Try-it area ====
Try-it area provides information on how to access a specific MEC Service API in the MEC Sandbox; a drop down allows to select the desired MEC API.
Note: MEC Services are always running (from MEC Sandbox creation); selecting a MEC API only changes the displayed information in the dashboard
Try-it in the browser allows to launch a SwaggerUI client for the selected MEC API; from the client a user can send requests to the MEC Services.

Try-it from your MEC application provides the link to use to reach the selected MEC API from an external application.
Note: the provided link needs to be provisioned in an application client to access the MEC Service running in the sandbox.
| style="width: 60%; text-align: left;" |
[[File:Try-it.png|border|500px]]
|}

== Swagger UI ==
The Swagger UI client is a powerful tool to learn about MEC APIs as it provides curated & browsable information about the API endpoints - but it also serves as an API client allowing to send requests and observe responses.

{| style="margin-top: 20px" |
|+
| style="width: 35%; min-width: 300px; vertical-align: top; padding-right: 20px;" |
The figure on right shows Swagger UI for the MEC Location Service.
* A header provides API name and details with links to related specifications
* The client is configured to communicate with your own sandbox
* API endpoints are listed along with their HTTP verb - clicking on an endpoint provides more details
| style="width: 65%; text-align: left;" |
[[File:Swagger1.png|border|850px]]
|+
| style="width: 35%; min-width: 300px; vertical-align: top; padding-right: 20px;" |
The figure on right shows the documentation details available at the endpoint level:
* A description of the endpoint
* Parameters that may be required when invoking the endpoint
* Possible responses that the endpoint may return
* The <code>Try it out</code> button enables the client mode
| style="width: 65%; text-align: left;" |
[[File:Swagger2.png|border|850px]]
|+
| style="width: 35%; min-width: 300px; vertical-align: top; padding-right: 20px;" |
The figure on right shows how a request can be sent to the MEC service running in the MEC Sandbox.

After clicking <code>Try it out</code>, the documentation page changes as follows:
* The parameters area allows to enter values if required; in this example, no parameters are needed
* An Execute button appears; clicking sends the request to the MEC API
* An informational window shows the request and parameters sent using the curl command
** Note that this command can be copied and sent from a Command line terminal
* The server response area shows the values received from the MEC Service API
** Responses can be downloaded
| style="width: 65%; text-align: left;" |
[[File:Swagger3.png|border|850px]]
|}

== MEC Application ==
MEC Application developers can access MEC Services running in the MEC Sandbox using the base path URL provided in the <code>Try-it</code> area of the Sandbox dashboard. This link routes requests for the selected MEC API to a specific user sandbox.

NOTE: Any external application or process with HTTP client capabilities and access to the MEC Sandbox can be used to send requests to the MEC Services (for example ''curl'')

MEC applications must use the provided link as a base path for API requests and must append the desired endpoint path. MEC applications must also provide path, query and body parameters when necessary. For more details on the supported endpoint paths and parameters, access the Swagger UI client in a MEC Sandbox.

For notification subscriptions, MEC applications must provide notification URLs where MEC Service notifications should be sent. If a notification URL points to a publicly accessible endpoint, the API Console will show the request and response data and codes; otherwise, the request will fail and the API console will display a 500 Internal error.

== Examples ==
This section provides some common usage examples.

{| style="margin-top: 20px" |
|+
| style="width: 35%; min-width: 300px; vertical-align: top; padding-right: 20px;" |
=== Subscriptions ===

The subscription endpoints available in each service are used to register for specific event notifications.

To subscribe for event notifications, a user may use the provided Swagger UI Try it out feature or may directly post a subscription request from a MEC application. In both cases, the subscription request body must contain the following:
* Notification URL where notifications will be sent
* Filter criteria to specify which events to register to

A successful subscription response includes the following:
* Subscription request data
* Subscription resource URL

The resource URL contains a unique subscription identifier that must be provided when updating or deleting a subscription.
| style="width: 65%; text-align: left;" |
[[File:Example-subscription.png|border|850px]]
|}

'''Location Subscriptions'''

To register for user location change events, set the following subscription request body:

{
"userTrackingSubscription": {
"clientCorrelator": "0123",
"callbackReference": {
"notifyURL": "http://my.callback.com/location-user-tracking/some-id"
},
"address": "10.100.0.1",
"userEventCriteria": [
"Entering",
"Leaving",
"Transferring"
]
}
}

A successful response for the above subscription request creates a new subscription with and ID of '2', as shows in the following response body:

{
"userTrackingSubscription": {
"address": "10.100.0.1",
"callbackReference": {
"notifyURL": "http://my.callback.com/location-user-tracking/some-id"
},
"clientCorrelator": "0123",
"resourceURL": "https://try-mec.testfqdn.dev/sbx123456/location/v2/subscriptions/userTracking/2",
"userEventCriteria": [
"Entering",
"Leaving",
"Transferring"
]
}
}

'''RNI & WAI Subscriptions'''

The same subscription procedure applies for RNIS and WAIS, with the exception of the resource URL response format. The subscription identifier can be found at the following location:

{
"_links": {
"self": {
"href": "https://try-mec.testfqdn.dev/sbx123456/rni/v2/subscriptions/1"
}
},
...
}

=== MEC013 Location API Common Examples ===

'''User Tracking'''

Track UE ''10.100.0.1'' as it moves across PoAs & zones:

{
"userTrackingSubscription": {
"callbackReference": {
"notifyURL": "http://my.callback.com/location_notifications/userTracking"
},
"address": "10.100.0.1",
"userEventCriteria": [
"Entering", "Leaving", "Transferring"
]
}
}

A ''ZonalPresenceNotification'' notification will be sent when UE ''10.100.0.1'' does the following:
* Enters a new zone
* Leaves its current zone
* Attaches to a different PoA within the same zone

NOTE: If a UE switches from a PoA in one zone to a PoA in a different zone, then 2 separate notifications are sent, one for leaving the old zone and another for entering a new zone.

'''Zonal Traffic'''

Track all UE location changes within ''zone01'':

{
"zonalTrafficSubscription": {
"callbackReference": {
"notifyURL": "http://my.callback.com/location_notifications/zonalTraffic"
},
"zoneId": "zone01",
"userEventCriteria": [
"Entering", "Leaving", "Transferring"
]
}
}

A ''ZonalPresenceNotification'' notification will be sent when any UE does the following:
* Enters ''zone01''
* Leaves ''zone01''
* Attaches to a different PoA within ''zone01''

'''Zonal Status'''

Track UE number thresholds within ''zone01'':

{
"zoneStatusSubscription": {
"callbackReference": {
"notifyURL": "http://my.callback.com/location_notifications/zonalStatus"
},
"zoneId": "zone01",
"numberOfUsersAPThreshold": 2,
"numberOfUsersZoneThreshold": 3
}
}

A ''ZoneStatusNotification'' notification will be sent on every change in UE connection count in ''zone01'' where:
* Number of UEs attached to a single PoA is greater than or equal to 2
* Number of UEs in zone is greater than or equal to 3

=== MEC012 RNI API Common Examples ===

'''Cell Change'''

Track UE ''10.100.0.1'' cell changes:

{
"subscriptionType": "CellChangeSubscription",
"callbackReference": "http://my.callback.com/rni/cellChange",
"filterCriteriaAssocHo": {
"associateId": [
{
"type": 1,
"value": "10.100.0.1"
}
],
"ecgi": [
{
"plmn": {
"mnc": "001",
"mcc": "001"
},
"cellId": "1010101"
}
]
}
}

A ''CellChangeNotification'' notification will be sent when UE ''10.100.0.1'' does the following:
* Moves from a 4G PoA to another 4G POA with cell ID ''1010101'', MNC ''001'' & MCC ''001''
* Moves from a 4G PoA with cell ID ''1010101'', MNC ''001'' & MCC ''001'' to another 4G POA

NOTE: Moving between a 4G and a non 4G POA will not trigger a cell change notification.

'''RAB Establishment'''

Track UE connections to cell ID ''1010101'':

{
"subscriptionType": "RabEstSubscription",
"callbackReference": "http://my.callback.com/rni/rabEst",
"filterCriteriaQci": {
"ecgi": [
{
"plmn": {
"mnc": "001",
"mcc": "001"
},
"cellId": "1010101"
}
],
"qci": 80
}
}

A ''RabEstNotification'' notification will be sent when any UE does the following:
* Moves from a non 4G PoA to a 4G PoA with cell ID ''1010101'', MNC ''001'', MCC ''001'' & QCI ''80''

NOTE: MEC Sandbox currently uses a constant QCI value of ''80''.

'''RAB Release'''

Track UE disconnections from cell ID ''1010101'':

{
"subscriptionType": "RabRelSubscription",
"callbackReference": "http://my.callback.com/rni/rabRel",
"filterCriteriaQci": {
"ecgi": [
{
"plmn": {
"mnc": "001",
"mcc": "001"
},
"cellId": "1010101"
}
],
"erabId": 6,
"qci": 80
}
}

A ''RabRelNotification'' notification will be sent when a UE with an Erabid of ''6'' does the following:
* Moves from a 4G PoA with cell ID ''1010101'', MNC ''001'', MCC ''001'' & QCI ''80'' to a non 4G PoA

NOTE: A new ErabId is allocated every time a UE connects to a 4G POA and stays unchanged until the UE disconnects from any 4G POA. The RAB Release notification can therefore only be seen once. The ECGI is an optional parameter, omitting it will allow less constraints on the conditions to see the notification.

=== MEC028 WAI API Common Examples ===

'''Associated Stations'''

Track stations associated to Wifi PoA with MAC ID ''005C02020202'':

{
"subscriptionType": "AssocStaSubscription",
"callbackReference": "http://my.callback.com/wai/assocSta",
"apId": {
"macId": "005C02020202"
}
}

A ''AssocStaNotification'' notification will be sent when any UE does the following:
* Connects to a Wifi PoA with MAC ID ''005C02020202'';
* Disconnected from a Wifi PoA with MAC ID ''005C02020202'';

= Discussion Board (Slack channels) =

{| style="margin-top: 20px" |
|+
| style="width: 40%; min-width: 400px; vertical-align: top; padding-right: 20px;" |
MEC Sandbox questions, feedback and discussions are tracked using slack channels in the '''MEC Sandbox Slack Workspace'''. The workspace is available here:

* [https://mecsandbox.slack.com/ MEC Sandbox Slack Workspace]

New users first need to join the MEC Sandbox slack workspace by creating a new account using the invitation link provided here:

* [https://join.slack.com/t/mecsandbox/shared_invite/zt-npe5mxvk-eOIHwrxtNbYG1OiwavHHDg Join the MEC Sandbox Slack Workspace]
| style="width: 60%; text-align: left;" |
[[File:slack-workspace.png|border|500px]]
|}

= Reporting Issues =

{| style="margin-top: 20px" |
|+
| style="width: 40%; min-width: 400px; vertical-align: top; padding-right: 20px;" |
MEC Sandbox issues are tracked using ETSI's bug-tracking system '''Bugzilla'''. The issue database is available here:

* [https://forge.etsi.org/bugzilla/buglist.cgi?component=MEC%20Sandbox MEC Sandbox issue database]

Users with an EOL account may report issues directly in the issue database.

All other users should report issues using the MEC Sandbox [[#Discussion_Board_.28Slack_channels.29|Discussion Board]].
| style="width: 60%; text-align: left;" |
[[File:bugzilla-issues.png|border|500px]]
|}

OpenAPI development guidelines

2021-02-23T07:53:27Z

Carignani:

OpenAPI Specification (OAS) development guidelines for ETSI MEC ISG API specifications.

''(More general recommendations can be found at [https://forge.etsi.org/wiki/index.php/Main_Page Forge OpenAPI Guidelines])''

= Latest versions =

Latest versions of the OAS representations are available in their respective repositories ([https://forge.etsi.org/rep/mec here])

Latest CI test results of the OAS representations are available [https://forge.etsi.org/jenkins/view/all/job/MEC%20-%20Multi-access%20Edge%20Computing/ here]

= Contributing =

If you are willing to contribute or if you want more information, contact [mailto:cti_support@etsi.org?subject=MEC%20openapis%20development: ETSI CTI].

ETSI CTI has also made a [https://www.youtube.com/watch?v=YXO0R61Dcg8 YouTube] tutorial available (based on NFV) that provides guidance on how to contribute for MEC.

= API development =

== General guidelines ==

As of January 2021, OAS representations have been updated to reflect the latest released versions of their corresponding GS (e.g. v2.1.x); the representations follow [https://swagger.io/specification/ OpenAPI 3.0 specification] language.

The following figure provides a high level overview of the OAS creation and usage.
[[File:ToolchainOverview.png|center|thumb|500x500px]]

As shown on the figure, OAS YAML file is used in 3 different contexts:
# To accurately reflect the GS API as released by ETSI MEC ISG
# To provide graphical UI documentation as an input to SwaggerUI JS Application
# To provide out-of-the-box API client library/package or server stub as an input to code generation tools

As such, when developing or updating the OAS YAML representations, the 3 usage described above should be considered.

The following sections provide guidelines on how to develop and validate OAS represnetaions.

== OAS YAML Generation ==
Initial OAS generation involves using the ETSI maintained doc2oas tool; the figure below shows the steps involved in using this tool.

The following figure outlines doc2oas usage.
[[File:Doc2oasToolchain.png|center|thumb]]

Step 1 - Create <code>MEC-XYZ_config.yaml</code> file
* this file contains all external types not defined in the GS in (OAS language)

* existing config files can be used as a template, types can be re-used from existing config files
* to quickly identify external types, Step2 can be performed with an empty config file - the resulting yaml file will show all unresolved types in the Swagger Editor

Step 2 - Use the <code>doc2oas.sh</code> script to generate <code>MEC-XYZ.yaml</code>
* the new specification must first be added to <code>doc2oas.sh</code> script

Step 3 - Add endpoints as per the GS specification
* follow the model from existing specifications
* the end result should not show any error in Swagger Editor

== OAS YAML Validation ==
Once the YAML file is available, the following validation steps should be performed to verify the validity in the different usage contexts

=== Level 1 Validation - OAS syntax ===
{| class="wikitable"
|+
!Validation Tool
!Validation Criteria
|-
|Swagger-Editor
|<nowiki>- No remaining warning or errors when opening OAS YAML</nowiki>
|-
|Swagger-CLI
| - Part of CI validation done via Jenkins in the repository
- Swagger-CLI reports no error/warnings

- <code>swagger-cli validate <oas-file.yaml></code>
|-
|Speccy
| - Part of CI validation done via Jenkins in the repository
- Speccy reports no error/warnings

- <code>speccy lint "<oas-file.yaml>"</code>
|}

=== Level 2 Validation - Swagger UI ===
{| class="wikitable"
!Validation Tool
!Validation Criteria
|-
|Swagger-UI
|<nowiki>- No error when viewing the file via Swagger UI</nowiki>

- Thorough visual inspection of endpoints and data model
|}

=== Level 3 Validation - Code Generation ===
{| class="wikitable"
!Validation Tool
!Validation Criteria
|-
|swagger-codegen-cli-v3
|<nowiki>- From CLI tool: generate client API library/package and server stub for Java and Golang</nowiki>

- Code generation succeeds

- Extra: execute server stub without crash

- Example Golang Server & Client

<code>java -jar swagger-codegen-cli-v3.jar generate -i <oas-file.yaml> -l go-server -o ./server-gen -DpackageName=server</code>

<code>java -jar swagger-codegen-cli-v3.jar generate -i <oas-file.yaml> -l go -o ./client-gen -DpackageName=client</code>
|}

== Proto3 Generation & Validation ==
Some API representations include a Protobuf representation along with the OAS3 representation; this representation is generated using the tool Open API Generator

=== Proto3 Generation ===
{| class="wikitable"
!Generation Tool
!Generation Criteria
|-
|openapi-generator-cli-5.0.0-beta2
|<nowiki>- From CLI: generate Proto3 representation</nowiki>

- Proto3 generation succeeds

- <code>java -jar openapi-generator-cli-5.0.0-beta2.jar generate -i <oas-file.yaml> -g protobuf-schema -o proto/ --package-name <mec1234></code>

- Full inspection of the generated Proto3 is mandatory

- At the time of writing, some Proto3 generated files needs to be touched manually: enumerations, structures containing allOf, oneOf, anyOf
|}

=== Proto3 Validation ===
{| class="wikitable"
!Validation Tool
!Validation Criteria
|-
|protoc
|<nowiki>- From CLI: generate source code from Proto3 representation</nowiki>

- Code generation succeeds

- Sometimes, when generating code, it may be necessary to include the file [https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/empty.proto empty.proto]

Example generate Go and Java
<pre>
mkdir go java

protoc --go_out=go --java_out=java services/*

protoc --go_out=go --java_out=java models/*
</pre>
|}

== Branching strategy ==
Development follows a simplified version of the popular [https://nvie.com/posts/a-successful-git-branching-model/ GitFlow]
* <code>master</code> - released version of the OAS representation
* <code>develop</code> - final versions of OAS representations development, before they are approved to be merged on master
* <code>feature branch</code> - work branch, the final result should be merged on develop

For example, work performed by a Specialist Task Force (stf123)
# STF - From <code>develop</code>, create a <code>stf123</code> <code>feature branch</code>
# STF - Once work is completed & validation pass, merge the <code>stf123</code> to <code>develop</code>
# STF - Create a Merge Request from <code>develop</code> to <code>master</code>
# SC - A member from the STF Steering Committee will perform the final merge
# SC - Apply a label corresponding the the GS version

== Folder structure and file names ==

=== Repository structure ===
<pre>
repository_root i.e. MEC
├── LICENSE
├── proto3 Protobuf representation generated from OAS yaml
│   ├── models Protobuf models
│   ├── README.md Protobuf general info
│   └── services Protobuf services
├── README.md General API information
├── MEC-XYZ.json Auto-generated JSON (From Swagger Editor -> Save As json)
└── MEC-XYZ.yaml Definition flat file used by Swagger-UI, Swagger-Editor, Swagger-CodeGen, etc.
</pre>''NOTE: Naming of of the JSON and YAML files is generally chosen by the DECODE group and does not necessarily follow the pattern outlined above.''

OpenAPI development guidelines

2021-02-23T07:51:30Z

Carignani: /* API development */

OpenAPI Specification (OAS) development guidelines for ETSI MEC ISG API specifications.

''(More general recommendations can be found at [https://forge.etsi.org/wiki/index.php/Main_Page Forge OpenAPI Guidelines])''

= Latest versions =

Latest versions of the OAS representations are available in their respective repositories ([https://forge.etsi.org/rep/mec here])

Latest CI test results of the OAS representations are available [https://forge.etsi.org/jenkins/view/all/job/MEC%20-%20Multi-access%20Edge%20Computing/ here]

= Contributing =

If you are willing to contribute or if you want more information, contact [mailto:cti_support@etsi.org?subject=MEC%20openapis%20development: ETSI CTI].

ETSI CTI has also made a [https://www.youtube.com/watch?v=YXO0R61Dcg8 YouTube] tutorial available (based on NFV) that provides guidance on how to contribute for MEC.

= API development =

== General guidelines ==

As of January 2021, OAS representations have been updated to reflect the latest released versions of their corresponding GS (e.g. v2.1.x); the representations follow [https://swagger.io/specification/ OpenAPI 3.0 specification] language.

The following figure provides a high level overview of the OAS creation and usage.

[[File:ToolchainOverview.png]]

As shown on the figure, OAS YAML file is used in 3 different contexts:
# To accurately reflect the GS API as released by ETSI MEC ISG
# To provide graphical UI documentation as an input to SwaggerUI JS Application
# To provide out-of-the-box API client library/package or server stub as an input to code generation tools

As such, when developing or updating the OAS YAML representations, the 3 usage described above should be considered.

The following sections provide guidelines on how to develop and validate OAS represnetaions.

== OAS YAML Generation ==
Initial OAS generation involves using the ETSI maintained doc2oas tool; the figure below shows the steps involved in using this tool.

The following figure outlines doc2oas usage.

[[File:Doc2oasToolchain.png]]

Step 1 - Create <code>MEC-XYZ_config.yaml</code> file
* this file contains all external types not defined in the GS in (OAS language)

* existing config files can be used as a template, types can be re-used from existing config files
* to quickly identify external types, Step2 can be performed with an empty config file - the resulting yaml file will show all unresolved types in the Swagger Editor

Step 2 - Use the <code>doc2oas.sh</code> script to generate <code>MEC-XYZ.yaml</code>
* the new specification must first be added to <code>doc2oas.sh</code> script

Step 3 - Add endpoints as per the GS specification
* follow the model from existing specifications
* the end result should not show any error in Swagger Editor

== OAS YAML Validation ==
Once the YAML file is available, the following validation steps should be performed to verify the validity in the different usage contexts

=== Level 1 Validation - OAS syntax ===
{| class="wikitable"
|+
!Validation Tool
!Validation Criteria
|-
|Swagger-Editor
|<nowiki>- No remaining warning or errors when opening OAS YAML</nowiki>
|-
|Swagger-CLI
| - Part of CI validation done via Jenkins in the repository
- Swagger-CLI reports no error/warnings

- <code>swagger-cli validate <oas-file.yaml></code>
|-
|Speccy
| - Part of CI validation done via Jenkins in the repository
- Speccy reports no error/warnings

- <code>speccy lint "<oas-file.yaml>"</code>
|}

=== Level 2 Validation - Swagger UI ===
{| class="wikitable"
!Validation Tool
!Validation Criteria
|-
|Swagger-UI
|<nowiki>- No error when viewing the file via Swagger UI</nowiki>

- Thorough visual inspection of endpoints and data model
|}

=== Level 3 Validation - Code Generation ===
{| class="wikitable"
!Validation Tool
!Validation Criteria
|-
|swagger-codegen-cli-v3
|<nowiki>- From CLI tool: generate client API library/package and server stub for Java and Golang</nowiki>

- Code generation succeeds

- Extra: execute server stub without crash

- Example Golang Server & Client

<code>java -jar swagger-codegen-cli-v3.jar generate -i <oas-file.yaml> -l go-server -o ./server-gen -DpackageName=server</code>

<code>java -jar swagger-codegen-cli-v3.jar generate -i <oas-file.yaml> -l go -o ./client-gen -DpackageName=client</code>
|}

== Proto3 Generation & Validation ==
Some API representations include a Protobuf representation along with the OAS3 representation; this representation is generated using the tool Open API Generator

=== Proto3 Generation ===
{| class="wikitable"
!Generation Tool
!Generation Criteria
|-
|openapi-generator-cli-5.0.0-beta2
|<nowiki>- From CLI: generate Proto3 representation</nowiki>

- Proto3 generation succeeds

- <code>java -jar openapi-generator-cli-5.0.0-beta2.jar generate -i <oas-file.yaml> -g protobuf-schema -o proto/ --package-name <mec1234></code>

- Full inspection of the generated Proto3 is mandatory

- At the time of writing, some Proto3 generated files needs to be touched manually: enumerations, structures containing allOf, oneOf, anyOf
|}

=== Proto3 Validation ===
{| class="wikitable"
!Validation Tool
!Validation Criteria
|-
|protoc
|<nowiki>- From CLI: generate source code from Proto3 representation</nowiki>

- Code generation succeeds

- Sometimes, when generating code, it may be necessary to include the file [https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/empty.proto empty.proto]

Example generate Go and Java
<pre>
mkdir go java

protoc --go_out=go --java_out=java services/*

protoc --go_out=go --java_out=java models/*
</pre>
|}

== Branching strategy ==
Development follows a simplified version of the popular [https://nvie.com/posts/a-successful-git-branching-model/ GitFlow]
* <code>master</code> - released version of the OAS representation
* <code>develop</code> - final versions of OAS representations development, before they are approved to be merged on master
* <code>feature branch</code> - work branch, the final result should be merged on develop

For example, work performed by a Specialist Task Force (stf123)
# STF - From <code>develop</code>, create a <code>stf123</code> <code>feature branch</code>
# STF - Once work is completed & validation pass, merge the <code>stf123</code> to <code>develop</code>
# STF - Create a Merge Request from <code>develop</code> to <code>master</code>
# SC - A member from the STF Steering Committee will perform the final merge
# SC - Apply a label corresponding the the GS version

== Folder structure and file names ==

=== Repository structure ===
<pre>
repository_root i.e. MEC
├── LICENSE
├── proto3 Protobuf representation generated from OAS yaml
│   ├── models Protobuf models
│   ├── README.md Protobuf general info
│   └── services Protobuf services
├── README.md General API information
├── MEC-XYZ.json Auto-generated JSON (From Swagger Editor -> Save As json)
└── MEC-XYZ.yaml Definition flat file used by Swagger-UI, Swagger-Editor, Swagger-CodeGen, etc.
</pre>''NOTE: Naming of of the JSON and YAML files is generally chosen by the DECODE group and does not necessarily follow the pattern outlined above.''

OpenAPI development guidelines

2021-02-23T07:51:11Z

Carignani: /* OAS YAML Validation */

OpenAPI Specification (OAS) development guidelines for ETSI MEC ISG API specifications.

''(More general recommendations can be found at [https://forge.etsi.org/wiki/index.php/Main_Page Forge OpenAPI Guidelines])''

= Latest versions =

Latest versions of the OAS representations are available in their respective repositories ([https://forge.etsi.org/rep/mec here])

Latest CI test results of the OAS representations are available [https://forge.etsi.org/jenkins/view/all/job/MEC%20-%20Multi-access%20Edge%20Computing/ here]

= Contributing =

If you are willing to contribute or if you want more information, contact [mailto:cti_support@etsi.org?subject=MEC%20openapis%20development: ETSI CTI].

ETSI CTI has also made a [https://www.youtube.com/watch?v=YXO0R61Dcg8 YouTube] tutorial available (based on NFV) that provides guidance on how to contribute for MEC.

= API development =

== General guidelines ==

As of January 2021, OAS representations have been updated to reflect the latest released versions of their corresponding GS (e.g. v2.1.x); the representations follow [https://swagger.io/specification/ OpenAPI 3.0 specification] language.

The following figure provides a high level overview of the OAS creation and usage.

[File:ToolchainOverview.png]

As shown on the figure, OAS YAML file is used in 3 different contexts:
# To accurately reflect the GS API as released by ETSI MEC ISG
# To provide graphical UI documentation as an input to SwaggerUI JS Application
# To provide out-of-the-box API client library/package or server stub as an input to code generation tools

As such, when developing or updating the OAS YAML representations, the 3 usage described above should be considered.

The following sections provide guidelines on how to develop and validate OAS represnetaions.

== OAS YAML Generation ==
Initial OAS generation involves using the ETSI maintained doc2oas tool; the figure below shows the steps involved in using this tool.

The following figure outlines doc2oas usage.

[File:Doc2oasToolchain.png]

Step 1 - Create <code>MEC-XYZ_config.yaml</code> file
* this file contains all external types not defined in the GS in (OAS language)

* existing config files can be used as a template, types can be re-used from existing config files
* to quickly identify external types, Step2 can be performed with an empty config file - the resulting yaml file will show all unresolved types in the Swagger Editor

Step 2 - Use the <code>doc2oas.sh</code> script to generate <code>MEC-XYZ.yaml</code>
* the new specification must first be added to <code>doc2oas.sh</code> script

Step 3 - Add endpoints as per the GS specification
* follow the model from existing specifications
* the end result should not show any error in Swagger Editor

== OAS YAML Validation ==
Once the YAML file is available, the following validation steps should be performed to verify the validity in the different usage contexts

=== Level 1 Validation - OAS syntax ===
{| class="wikitable"
|+
!Validation Tool
!Validation Criteria
|-
|Swagger-Editor
|<nowiki>- No remaining warning or errors when opening OAS YAML</nowiki>
|-
|Swagger-CLI
| - Part of CI validation done via Jenkins in the repository
- Swagger-CLI reports no error/warnings

- <code>swagger-cli validate <oas-file.yaml></code>
|-
|Speccy
| - Part of CI validation done via Jenkins in the repository
- Speccy reports no error/warnings

- <code>speccy lint "<oas-file.yaml>"</code>
|}

=== Level 2 Validation - Swagger UI ===
{| class="wikitable"
!Validation Tool
!Validation Criteria
|-
|Swagger-UI
|<nowiki>- No error when viewing the file via Swagger UI</nowiki>

- Thorough visual inspection of endpoints and data model
|}

=== Level 3 Validation - Code Generation ===
{| class="wikitable"
!Validation Tool
!Validation Criteria
|-
|swagger-codegen-cli-v3
|<nowiki>- From CLI tool: generate client API library/package and server stub for Java and Golang</nowiki>

- Code generation succeeds

- Extra: execute server stub without crash

- Example Golang Server & Client

<code>java -jar swagger-codegen-cli-v3.jar generate -i <oas-file.yaml> -l go-server -o ./server-gen -DpackageName=server</code>

<code>java -jar swagger-codegen-cli-v3.jar generate -i <oas-file.yaml> -l go -o ./client-gen -DpackageName=client</code>
|}

== Proto3 Generation & Validation ==
Some API representations include a Protobuf representation along with the OAS3 representation; this representation is generated using the tool Open API Generator

=== Proto3 Generation ===
{| class="wikitable"
!Generation Tool
!Generation Criteria
|-
|openapi-generator-cli-5.0.0-beta2
|<nowiki>- From CLI: generate Proto3 representation</nowiki>

- Proto3 generation succeeds

- <code>java -jar openapi-generator-cli-5.0.0-beta2.jar generate -i <oas-file.yaml> -g protobuf-schema -o proto/ --package-name <mec1234></code>

- Full inspection of the generated Proto3 is mandatory

- At the time of writing, some Proto3 generated files needs to be touched manually: enumerations, structures containing allOf, oneOf, anyOf
|}

=== Proto3 Validation ===
{| class="wikitable"
!Validation Tool
!Validation Criteria
|-
|protoc
|<nowiki>- From CLI: generate source code from Proto3 representation</nowiki>

- Code generation succeeds

- Sometimes, when generating code, it may be necessary to include the file [https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/empty.proto empty.proto]

Example generate Go and Java
<pre>
mkdir go java

protoc --go_out=go --java_out=java services/*

protoc --go_out=go --java_out=java models/*
</pre>
|}

== Branching strategy ==
Development follows a simplified version of the popular [https://nvie.com/posts/a-successful-git-branching-model/ GitFlow]
* <code>master</code> - released version of the OAS representation
* <code>develop</code> - final versions of OAS representations development, before they are approved to be merged on master
* <code>feature branch</code> - work branch, the final result should be merged on develop

For example, work performed by a Specialist Task Force (stf123)
# STF - From <code>develop</code>, create a <code>stf123</code> <code>feature branch</code>
# STF - Once work is completed & validation pass, merge the <code>stf123</code> to <code>develop</code>
# STF - Create a Merge Request from <code>develop</code> to <code>master</code>
# SC - A member from the STF Steering Committee will perform the final merge
# SC - Apply a label corresponding the the GS version

== Folder structure and file names ==

=== Repository structure ===
<pre>
repository_root i.e. MEC
├── LICENSE
├── proto3 Protobuf representation generated from OAS yaml
│   ├── models Protobuf models
│   ├── README.md Protobuf general info
│   └── services Protobuf services
├── README.md General API information
├── MEC-XYZ.json Auto-generated JSON (From Swagger Editor -> Save As json)
└── MEC-XYZ.yaml Definition flat file used by Swagger-UI, Swagger-Editor, Swagger-CodeGen, etc.
</pre>''NOTE: Naming of of the JSON and YAML files is generally chosen by the DECODE group and does not necessarily follow the pattern outlined above.''

File:Doc2oasToolchain.png

2021-02-23T07:50:43Z

Carignani:

2021-01-12T14:02:08Z

Carignani:

MEC Ecosystem

2021-01-12T12:10:59Z

Carignani:

This page provides information very much related to the work of the ETSI ISG MEC Deployment and ECOsystem DEvelopment ([https://portal.etsi.org//tb.aspx?tbid=874&SubTB=874#/ DECODE]) Working Group, whose aim is to accelerate the development of the MEC ecosystem:
*[https://forge.etsi.org/ '''Forge Projects''']: Includes OpenAPI/Swagger & Protobuf descriptions of the APIs specified by ISG MEC.
**[https://mecwiki.etsi.org/index.php?title=OpenAPI_development_guidelines OpenAPI development guidelines]: How can I contribute to the API development?
*'''[https://try-mec.etsi.org/ MEC Sandbox]''': MEC Service API playground
**[https://forge.etsi.org/rep/stf-587/mec-sandbox-scenarios MEC Sandbox Scenarios] (EOL account required): Macro/micro network emulation scenarios
*'''[https://mecwiki.etsi.org/index.php?title=MEC_Ecosystem#MEC_Applications MEC Applications]''': 3rd party solutions
*'''[[MEC Ecosystem#MEC Solutions|MEC Solutions]]''': 3rd party solutions

== MEC Applications ==
List of MEC Applications made available by third parties
{| class="wikitable"
|+
!Name of the App & logo
!Description
!MEC Consumed APIs
!MEC API provided
!Link
!Contact
|-
|'''Unibo MEC API Tester'''[[File:Unibo mec api tester.png|center|frameless|200x200px]]
|The Unibo MEC API Tester is a web-based application that can be used to test the capability of a MEC Platform to support the MEC 011 defined APIs (mec_app_support & mec_service_mgmt).
|MEC 011 (Mp1)
|NA
|[https://github.com/berdav/unibo-test-mec Link]
|[mailto:davide.berardi6@unibo.it Davide Berardi]
|}

== MEC Solutions ==

List of MEC Solutions made available by third parties (in alphabetical order). Such solutions may offer all components (functional entities) of the [https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/02.01.01_60/gs_MEC003v020101p.pdf MEC architecture], or a subset (for instance a MEC Platform, or API implementation).

{| class="wikitable"
|+
!Name of the project & logo
!Description
!MEC Components provided
!MEC APIs supported
!Link
!Contact
|-
|'''AdvantEdge''' [[File:advantedge.png|center|frameless|200x200px]]
|AdvantEDGE is a Mobile Edge Emulation Platform (MEEP) that runs on Docker & Kubernetes. AdvantEDGE provides an emulation environment, enabling experimentation with Edge Computing Technologies, Applications, and Services. The platform facilitates exploring edge / fog deployment models and their impact on applications and services in short and agile iterations.
|MEC Platform
| MEC 012 Radio Network Information<br />MEC 013 Location<br />MEC 028 WLAN Information
|[https://github.com/InterDigitalInc/AdvantEDGE Link]
|[mailto:AdvantEDGE@InterDigital.com AdvantEDGE@InterDigital.com]
|-
|'''Connected Vehicle Blueprint (Aka CVB)''' [[File:akraino.png|center|frameless|200x200px]]
|CVB provides a V2X focused MEC platform, which offers services to connected vehicles. These services are delivered to applications hosted on vehicles based on a set of policies for data dispatch and response. As the blueprint continues to be developed, further connected-vehicle applications and services are being incorporated into the blueprint.
|MEC Platform(s), MEC Platform Manager
|MEC 011 Mp1 & Mm5
|[https://wiki.akraino.org/pages/viewpage.action?pageId=9601601 Link]
|[mailto:yargyang@tencent.com Yarg Yang]
|-
|'''Enterprise Applications on Lightweight 5G Telco Edge (EALTEdge)''' [[File:akraino.png|center|frameless|200x200px]]
|Lightweight telco edge platform, enabling Enterprise applications on telco edge. Offering a: Unified Portal for platform management and for App developers; Sandbox with SDKs and tools chains for MEC app developers; Heterogeneous deployment on Multi-Arch; ETSI MEC Compliance.
|MEC Platform(s), MEC Platform Manager
|MEC 011 Mp1 & Mm3
|[https://wiki.akraino.org/display/AK/Enterprise+Applications+on+Lightweight+5G+Telco+Edge Link]
|[Mailto:gaurav.agrawal@huawei.com Gaurav Agrawal]
|-
|'''i-MEC''' [[File:Italtel RGB.jpg|center|frameless|200x200px]]
|Italtel MEC platform i-MEC brings high value in the network enabling a wide set of services which leverage reduced end-to-end latency (uRLLC), pre-processing at the edge (mMTC) and broadband services (eMBB). i-MEC contributes to reduce the traffic load on the backhauling transport network with relevant saving of cost for the Service Operator.
|MEC Platform
|MEC011 Mp1, Mm5 proprietary API, Mp2 proprietary API (OpenFlow based)
|[https://www.italtel.com/products/multi-access-edge-computing-mec-platform/ Link]
|[Mailto:marketing_technology@italtel.com Italtel]
|-
|'''MEC Location API Simulator''' [[File:LINKS_Logo.png|center|frameless|200x200px]]
|The Location API simulator helps developers to create applications that use MEC Location API. It provides a MEC Location Service accessible via Location API as specified in the ETSI GS MEC013 document, available as a RESTful web service. It has a Graphical User Interface enabling developers to simulate mobile users' movements by feeding the simulator with a GPS track in .gpx format. The first release implements a subset of MEC013 API but the full set of APIs and an improved engine to simulate cars, VRU and more will be part of future releases.
| MEC013 accessible APIs (with an engine to simulate mobile users’ movement)
| MEC 013 Location
|[https://networkbuilders.intel.com/commercial-applications/links-foundation Link]
|[mailto:daniele.brevi@linksfoundation.com daniele.brevi@linksfoundation.com]
|-
|'''Public Cloud Edge Interface (PCEI)''' [[File:akraino.png|center|frameless|200x200px]]
|The purpose of Public Cloud Edge Interface (PCEI) Blueprint family is to specify a set of open APIs for enabling Multi-Domain Inter-working across functional domains that provide Edge capabilities/applications and require close cooperation between the Mobile Edge, the Public Cloud Core and Edge, the 3rd-Party Edge functions as well as the underlying infrastructure such as Data Centers and Networks.
|Provides an enabler layer that facilitates interworking between Edge Computing platforms, including Multi-Access Edge Compute, Public Cloud and 3rd-Party Edge Compute, and Mobile Networks
|MEC 013 Location API
|[https://wiki.akraino.org/display/AK/Public+Cloud+Edge+Interface+%28PCEI%29+Blueprint+Family Link]
|[mailto:oberzin@equinix.com Oleg Berzin]
|-
|'''ServerlessOnEdge'''[[File:Logo-small.png|center|frameless|200x200px]]
|Decentralized framework for the distribution of lambda functions to multiple serverless platforms, with Apache OpenWhisk connectors, supporting the ETSI MEC Device application interface (MEC 016).
|User app LCM proxy
|MEC 016 Device application interface (Mx2)
|[https://github.com/ccicconetti/serverlessonedge Link]
|[Mailto:c.cicconetti@iit.cnr.it Claudio Cicconetti]
|-
|}

=== Request your project to be listed ===

<big>
A request to add a new entry to either the MEC Applications or MEC Solutions should be sent to please [Mailto:CTI_support@etsi.org?Subject=ISG+MEC+WIKI+Ecosystem+request contact ETSI CTI], with title "ISG MEC WIKI Ecosystem request".
<u>'''Any'''</u> organization (ETSI member or not) is entitled to send the request.
</big>

The request should contain the information to be included in the table. "Contact" in the table is not mandatory, but a contact point is required to allow communication of changes or future developments on the page.

The chairman of DECODE WG and ETSI Secretariat will review the proposal and publish it.

Criteria for the inclusion into the Ecosystem page are:
* The referenced activity is relevant to ETSI MEC i.e. it claims to implement at least one MEC Component from the MEC Architecture as defined in [https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/02.01.01_60/gs_MEC003v020101p.pdf ETSI GS MEC 003].
* The proposed description or text is not offensive and is fit for publication, in line with the purpose of the MEC wiki.

File:LINKS Logo.png

2021-01-12T12:10:13Z

Carignani:

MEC Ecosystem

Ongoing PoCs

2020-03-23T09:09:03Z

Carignani:

==Overview of Reports==
<big>
{| class="wikitable center"
! #
! Description
! Final Report
|-
| PoC 1
| style="text-align:left;"| [http://mecwiki.etsi.org/index.php?title=PoC_1_Video_User_Experience_Optimization_via_MEC_-_A_Service_Aware_RAN_PoC Video User Experience Optimization via MEC - A Service Aware RAN PoC]
| Completed
|-
| PoC 2
| style="text-align:left;"| [http://mecwiki.etsi.org/index.php?title=PoC_2_Edge_Video_Orchestration_and_Video_Clip_Replay_via_MEC Edge Video Orchestration and Video Clip Replay via MEC]
| [https://docbox.etsi.org/ISG/MEC/05-CONTRIBUTIONS/2017//MEC(17)000193_PoC_2_Final_Report.zip PoC2_Final_Report]
|-
| PoC 3
| style="text-align:left;"| [http://mecwiki.etsi.org/index.php?title=PoC_3_Radio_aware_video_optimization_in_a_fully_virtualized_network Radio aware video optimization in a fully virtualized network]
| Completed
|-
| PoC 4
| style="text-align:left;"| [http://mecwiki.etsi.org/index.php?title=PoC_4_FLIPS_%E2%80%93_Flexible_IP-based_Services FLIPS – Flexible IP-based Services]
| Completed
|-
| PoC 5
| style="text-align:left;"| [http://mecwiki.etsi.org/index.php?title=PoC_5_Enterprise_Services Enterprise Services]
| Completed
|-
| PoC 6
| style="text-align:left;"| [http://mecwiki.etsi.org/index.php?title=PoC_6_Healthcare_%E2%80%93_Dynamic_Hospital_User,_IoT_and_Alert_Status_management Healthcare – Dynamic Hospital User, IoT and Alert Status management]
| Completed
|-
| PoC 7
| style="text-align:left;"| [http://mecwiki.etsi.org/index.php?title=PoC_7_Multi-Service_MEC_Platform_for_Advanced_Service_Delivery Multi-Service MEC Platform for Advanced Service Delivery]
| Completed
|-
| PoC 8
| style="text-align:left;"| [http://mecwiki.etsi.org/index.php?title=PoC_8_Video_Analytics Video Analytics]
| [https://docbox.etsi.org/ISG/MEC/05-CONTRIBUTIONS/2017//MEC(17)000194_PoC_8_Final_Report.zip PoC8_Final_Report]
|-
| PoC 9
| style="text-align:left;" | [http://mecwiki.etsi.org/index.php?title=PoC_9_MEC_platform_to_enable_low-latency_Industrial_IoT MEC platform to enable low-latency Industrial IoT]
| Completed
|-
| PoC 10
| style="text-align:left;" | [https://mecwiki.etsi.org/index.php?title=PoC_10_Service-Aware_MEC_Platform_to_Enable_Bandwidth_Management_of_RAN Service-Aware MEC Platform to Enable Bandwidth Management of RAN]
| Completed
|-
| PoC 11
| style="text-align:left;" | [https://mecwiki.etsi.org/index.php?title=PoC_11_Communication_Traffic_Management_for_V2X Communication Traffic Management for V2X]
| [https://docbox.etsi.org/ISG/MEC/05-CONTRIBUTIONS/2019//MEC(19)000243r2_MEC_PoC11_report.zip PoC11_Final_Report]
|-
| PoC 12
| style="text-align:left;" | [https://mecwiki.etsi.org/index.php?title=PoC_12_MEC_enabled_Over-The-Top_business MEC enabled OTT business]
| Completed
|-
| PoC 13
| style="text-align:left;" | [https://mecwiki.etsi.org/index.php?title=PoC_13_MEC_infotainment_for_smart_roads_and_city_hot_spots MEC infotainment for smart roads and city hot spots]
| Completed
|}
</big>

==List of PoCs==
This page provides the list of on-going ISG MEC PoCs. Click on them to learn further details.

The following MEC Proofs of Concept are developed according to the ETSI ISG MEC Proof of Concept Framework. MEC Proofs of Concept are intended to demonstrate MEC as a viable technology. Results are fed back to the Industry Specification Group on Mobile Edge Computing.

Neither ETSI, the ISG MEC, nor their members make any endorsement of any product or implementation claiming to demonstrate or conform to MEC. No verification or test has been performed by ETSI on any part of these MEC Proofs of Concept.

'''[[PoC 1 Video User Experience Optimization via MEC - A Service Aware RAN PoC]]'''
Intel - China Mobile - iQiYi

'''[[PoC 2 Edge Video Orchestration and Video Clip Replay via MEC]]'''
Nokia - EE - Smart Mobile Labs

'''[[PoC 3 Radio aware video optimization in a fully virtualized network]]'''
Telecom Italia - Intel UK Corporation - Eurecom - Politecnico di Torino

'''[[PoC 4 FLIPS – Flexible IP-based Services]]'''
InterDigital - Bristol is Open - Intracom - CVTC - Essex University

'''[[PoC 5 Enterprise Services]]'''
Saguna - Adva Optical Networking - Bezeq International

'''[[PoC 6 Healthcare – Dynamic Hospital User, IoT and Alert Status management]]'''
Quortus Ltd - Argela - Turk Telecom

'''[[PoC 7 Multi-Service MEC Platform for Advanced Service Delivery]]'''
Brocade - Gigaspaces - Advantech - Saguna - Vasona - Vodafone

'''[[PoC 8 Video Analytics]]'''
Nokia - Vodafone Hutchison Australia - SeeTec

'''[[PoC 9 MEC platform to enable low-latency Industrial IoT]]'''
Vasona Networks - RIFT.io - Xaptum - Oberthur Technologies - Intel Corporation - Vodafone

'''[[PoC 10 Service-Aware MEC Platform to Enable Bandwidth Management of RAN]]'''
Industry Technology Research Institute - Linker Network - FarEasTone

'''[[PoC 11 Communication Traffic Management for V2X]]'''
KDDI Corporation - Saguna Networks Ltd. - Hewlett Packard Enterprise

'''[[PoC 12 MEC enabled Over-The-Top business]]'''
China Unicom - ZTE - Intel - Tencent - Wo video - UnitedStack

'''[https://mecwiki.etsi.org/index.php?title=PoC_13_MEC_infotainment_for_smart_roads_and_city_hot_spots PoC 13 MEC infotainment for smart roads and city hot spots]'''
TIM - Intel - Vivida - ISMB - City of Turin

2019-02-24T02:38:22Z

Carignani: /* MEC Deployment Trials */

Main Page

2019-02-24T02:37:59Z

Carignani: /* MEC Deployment Trials */

__NOTOC__

<div style="width:100%;display:block; overflow: overlay">
<div style="width:45%; min-width: 100px; padding:20px;float:left; font-size:12pt">
== MEC API Activity ==
* ''' [[OpenAPI development guidelines]] ''' How can I contribute to the API development?
</div>

<div style="width:45%; min-width: 100px; padding:20px;float:left; font-size:12pt">
== MEC Proof of Concept Activity ==

* '''[[Ongoing PoCs]]''' Information about ongoing ISG MEC PoCs.
* '''[[PoC Topics]]''' Information about ISG MEC PoC Topics.
* '''[[PoC Framework]]''' Information about ISG MEC PoC Framework (process, criteria, templates....).
* '''[[Logos and guidelines]]''' Information and guidelines on the use of ETSI and MEC PoC logo.
* '''[[Q&A]]''' Usual questions (and answers) on ISG MEC PoCs.
</div>

<div style="width:45%; min-width: 100px; padding:20px;float:left; font-size:12pt">
== MEC Hackathons ==
* '''[[MEC Hackathon Framework]]''': Guidelines and call for proposals of hackathons for MEC
</div>

<div style="width:45%; min-width: 100px; padding:20px;float:left; font-size:12pt">
== MEC Deployment Trials ==
* '''[[MEC Deployment Trials Framework]]''': Discover MDTs and how to participate.
* [[Ongoing MDTs|Check the list of MDT]]

</div>
</div>

<div style="display:block; width:100%">
This Wiki is provided as a tool for the use of ISG MEC participants.
You may need to login to access some information

''' >>> ISG MEC participants can login with their ETSI OnLine (EOL) account <<<'''

If you are an ISG MEC participant and do not have an EOL account yet,
you can [http://webapp.etsi.org/createaccount apply for an EOL account], or send a request to [mailto:helpdesk@etsi.org ETSI helpdesk]

For any other wiki related request, please [mailto:CTI_support@etsi.org?Subject=ISG_MEC_WIKI_request contact ETSI CTI]

<center>
'''[http://mecwiki.etsi.org/index.php?title=Special%3AUserLogin&returnto=Main+Page Login with your EOL account!]'''
</center>

</div>

Ongoing MDTs

2019-02-21T15:45:28Z

Carignani:

==Overview of Reports==

{| class="wikitable center"
|+
!#
!Description
!MDT Proposal
!Final Report
|-
|MDT#1
|[[MDT 1 Deployment of CDN at the edge of the mobile network|Deployment of CDN at the edge of the mobile network]]
|[https://docbox.etsi.org/ISG/MEC/05-Contributions/2018/MEC(18)000422_The_deployment_of_CDN_at_the_edge_of_the_mobile_network_.docx LINK]
|Expected Q4 2018
|-
|MDT#2
|[[MDT 2 Introducing mobile edge computing in factory network|Introducing mobile edge computing in factory network]]
|[https://docbox.etsi.org/ISG/MEC/05-Contributions/2018/MEC(18)000423_Introducing_mobile_edge_computing_in_factory_network_.docx LINK]
|Expected Q4 2018
|-
|MDT#3
|[[MDT 3 Cloud game scheme based on 5G|Edge-Cloud VR cloud game scheme based on 5G network]]
|[https://docbox.etsi.org/ISG/MEC/05-Contributions/2018/MEC(18)000438r2_Edge_Cloud_platform_architecture_and_Experimental_deployment.doc LINK]
|Expected Q4 2018
|}

==List of MDTs==

This page provides the list of on-going ISG MEC MDTs. Click on them to learn further details.

The following MEC Proofs of Concept are developed according to the ETSI ISG MEC Proof of Concept Framework. MEC Proofs of Concept are intended to demonstrate MEC as a viable technology. Results are fed back to the Industry Specification Group on Mobile Edge Computing.

Neither ETSI, the ISG MEC, nor their members make any endorsement of any product or implementation claiming to demonstrate or conform to MEC. No verification or test has been performed by ETSI on any part of these MEC Proofs of Concept.

'''[[MDT 1 Deployment of CDN at the edge of the mobile network|MDT#1: Deployment of CDN at the edge of the mobile network]] '''
China Mobile - Nokia

'''[[MDT 2 Introducing mobile edge computing in factory network| MDT#2: Introducing mobile edge computing in factory network]]'''
China Mobile - Huawei

'''[[MDT 3 Cloud game scheme based on 5G| MDT#3: Edge-Cloud VR cloud game scheme based on 5G network]]'''
China Unicom - Huawei - Tencent - Intel

PoC 13 MEC infotainment for smart roads and city hot spots

2019-02-18T21:55:25Z

Carignani:

<div style="border: 2px solid red; text-align:center; color: red;">
The present PoC proposal is under approval process.
</div>

== PoC Team ==
* TIM
* Intel
* Vivida
* ISMB
* City of Turin

== Main Contact ==
Antonio Manzalini, TIM
[mailto:antonio.manzalini@telecomitalia.it antonio.manzalini@telecomitalia.it]

== Abstract ==

The use case aims at demonstrating innovative 4G/5G infotainment services for both pedestrians and car drivers/passengers in smart roads and city hot spots.

4G/5G infotainment services are seamlessly provided both to car drivers/passengers and to pedestrians in smart roads and city hot spots (e.g., commercial areas, Stadium, Stations, during events/concerts etc).

== PoC Proposal ==
[https://docbox.etsi.org/ISG/MEC/05-CONTRIBUTIONS/2019//MEC(18)000536r1_PoC_Proposal_for_MEC_infotainment_for_smart_roads_and_city_h.docx MEC infotainment for smart roads and city hot spots]

== PoC Topics ==

This PoC is WORKING on:

[[PT01 - Demonstration of MEC Service Scenarios]]

[[PT02 - MEC Metrics]]

[[PT04 MEC enabled vertical segments applications|PT04 - PT04 MEC enabled vertical segments applications]]

== PoC Report ==
PoC Report is expected by end of Q4 2019

PoC 13 MEC infotainment for smart roads and city hot spots

2019-02-18T21:53:29Z

Carignani:

== Notice ==

<divstyle="border: 2px solid red: text-align:center; color: red;">
The present PoC proposal is still under approval process.
</div>

== PoC Team ==
* TIM
* Intel
* Vivida
* ISMB
* City of Turin

== Main Contact ==
Antonio Manzalini, TIM
[mailto:antonio.manzalini@telecomitalia.it antonio.manzalini@telecomitalia.it]

== Abstract ==

The use case aims at demonstrating innovative 4G/5G infotainment services for both pedestrians and car drivers/passengers in smart roads and city hot spots.

4G/5G infotainment services are seamlessly provided both to car drivers/passengers and to pedestrians in smart roads and city hot spots (e.g., commercial areas, Stadium, Stations, during events/concerts etc).

== PoC Proposal ==
[https://docbox.etsi.org/ISG/MEC/05-CONTRIBUTIONS/2019//MEC(18)000536r1_PoC_Proposal_for_MEC_infotainment_for_smart_roads_and_city_h.docx MEC infotainment for smart roads and city hot spots]

== PoC Topics ==

This PoC is WORKING on:

[[PT01 - Demonstration of MEC Service Scenarios]]

[[PT02 - MEC Metrics]]

[[PT04 MEC enabled vertical segments applications|PT04 - PT04 MEC enabled vertical segments applications]]

== PoC Report ==
PoC Report is expected by end of Q4 2019