Review update

# MEC012 - Radio Network Information Service

> _The following query endpoints and subscriptions will be supported in STF587, based on v1:  (1) rab_info; (2) plmn_info; (3) cell_change; (4) rab_est; (5) rab_rel.  v2 changes for these endpoints are minor and may be considered during implementation or when v2 is available on Forge. The remaining endpoints are either marked for STF587 Milestone D consideration (depending on time and effort) or deferred for future consideration beyond STF587.  All RABs will have a consistent QCI value (e.g. non-GBR, QCI = 80 -- Low latency eMBB applications, TCP/UDP-based)_

This section describes how MEC012 has been integrated with the MEC Sandbox.

## MEC 012 v1.1.1 (available on forge)

References:

* https://www.etsi.org/deliver/etsi_gs/MEC/001_099/012/01.01.01_60/gs_MEC012v010101p.pdf

* https://forge.etsi.org/rep/mec/gs012-rnis-api

* https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/mec/gs012-rnis-api/raw/master/RniAPI.yaml#/

## MEC 012 v2.1.1 (published, not available on forge)

Minor changes to v1 endpoints:  

* Egci defined as a dedicated type;

* Subscription / Notification type string added to data model.  

Specific v2 additions annotated in the tables below.  

References:

* https://www.etsi.org/deliver/etsi_gs/MEC/001_099/012/02.01.01_60/gs_MEC012v020101p.pdf

### Query Endpoints

| Endpoint | Sandbox Usage |Notes |

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

| /queries/rab_info <br><br>_This resource is queried to retrieve information on Radio Access Bearers_ | Terminals are identified via UE_IPV4_ADDRESS type in associateId <br><br> Sandbox query input utilizes: <ul><li> cell_id (array): returns RabInfo for all terminals connected within the input cells (RabInfo includes terminal's assoicateId = IP address) </li><li> ue_ipv4_address (array): returns RabInfo for all input terminal's based on IP address (RabInfo includes terminal's connected Cell Id) </li><li> If no parameters are included: returns all RabInfo for all connected terminals in all cells </li><li> Both parameters are considered an "and" </li></ul> <br> All other parameter are ignored, including MEC app instance ID <br>Note: in the Sandbox context, all Service API requests are modeled as coming from the same MEC App instance.  | Although the MEC Sandbox does not include data paths to terminals, the rab_info query can be used to discover terminals and their connected cells in the Sandbox.  <br><br> As a Sandbox user, I can use this call to learn about all terminals in the network connected to 3GPP PoAs. I do not need to know the Terminal Id or the Cell Id. Input = null.  <br><br> As a Sandbox user, if I know a Terminal's Id (IP address), I can use this call to determine if and where that terminal is 3GPP connected (input = terminal IP address)  <br><br> As a Sandbox user, if I know a Cell Id, I can use this call to learn what terminals may be connected in that cell (input = cell id in EGCI format). <br><br> RABs will have a consistent QCI value (e.g. non-GBR, QCI = 80 -- Low latency eMBB applications, TCP/UDP-based).

| /queries/plmn_info <br><br>_This resource is queried to retrieve information on the underlying Mobile Network that the mobile edge application is associated to._ | Returns Sandbox PLMN: <ul><li> MCC = 001; <li> MNC = 001</ul> | As a Sandbox user, I can use this query to learn the PLMN of the Sandbox Network. <br><br> RNIS v1: cellId set to static value <br><br> Application instance identifier is ignored. |

| /queries/s1_bearer_info <br><br>_This resource is queried to retrieve S1-U bearer information related to specific UE(s)_ |	Not supporting - future consideration beyond STF587 | S1 Bearer too detailed for MEC Sandbox |

| /queries/layer2_meas <br><br> *v2 addition* <br><br>_This resource is queried to obtained detailed cellular measurement information, filtered by all measurements, per UE, per Cell, etc.  <br><br> L2 measurement information includes:  <ul><li> Cell level information (PRB usage, # of active GBR and non-GBR terminals, packet discard rate, etc.); <li> UE level information (connected cell ID, packet delay, packet discard rate, throughput, data volume, etc.) </ul>_ | STF587 Milestone D consideration, depending on remaining time and effort | As a Sandbox user, I can use this query to learn latency, packet loss, and throughput information for terminals.  I can also learn where terminals are connected in the 3GPP network.  <br><br> *Sandbox scope does not include data traffic to/from emulated terminal devices.  However, measurements that are network configuration or cell connection related could be supported (i.e. not active measurements, e.g. data volume)* |  

### Subscription Endpoints

| Endpoint |  Sandbox Usage | Notes |

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

| /subscriptions <br><br>_The GET method is used to request information about the subscriptions for this requestor. Upon success, the response contains entity body with the list of links to the subscriptions that are present for the requestor_ | Return list of all RNIS subscriptions | Sandbox supports a single requester (i.e. single ME app calling MEC services)

| /subscriptions/cell_change	<br><br>_Cell change notifications_ |	Notifications report cell changes based on input filters <br><br> Supported filters include: <ul><li> associateId: list of terminals based on IP address <li> plmnId: ignored <li> cellId: list of cells (if not present, all cell changes) <li> hoStatus: ignored (notifications on COMPLETE) </ul> Filters are considered an "and" between types, then an "or" within the list of a type. For example: UEs (1,2,3) + Cells (a,b,c). Notification will trigger if any of the UEs handover with any of the cells; Otherwise not. UE1 handover with Cell4 for example. <br><br> Expiry Deadline is ignored. | As a Sandbox User, I can set a notification with no filters and I will get all cell change events that occur in the sandbox. <br><br> As a Sandbox User, I can set a notification for a specific terminal (or set) and monitor its handover changes across the 3GPP points of access. <br><br> As a Sandbox User, I can set a notification to monitor a specific cell (or set of cells) and monitor handover events for that cell.

| /subscriptions/rab_est	<br><br>_RAB establishment notification_	| Notifications report RAB establishments in the network, i.e. when a terminal connects to the 3GPP network. <br><br> Sandbox examples include: <ul> <li> Terminal is added to the Macro Network Scenario by the user <li> Terminal connects to a 3GPP PoA after being connected to WiFi </ul> <br>Supported filters include: <ul> <li> plmnId: ignored <li> cellId: list of cell (if not present, RAB establishment on any cell) <li> QCI: ignored </ul> <br> Expiry Deadline is ignored. <br> <br> Notification returns: <ul><li> associateId: IPv4 address of the terminal <li> erabId: RAB Id for the terminal's bearer </ul> | As a Sandbox User, I can set a notification with no filters and I will get all RAB establishment events on any cell (terminal connection to 3GPP anywhere in the network). <br><br> As a Sandbox User, I can set a notification for a specific cell (or set of cells) and monitor RAB establishments for those cells. |

| /subscriptions/rab_mod	<br><br>_RAB modification notification_ | Not supporting - future consideration beyond STF587 | Within the MEC Sandbox RABs will not change QCR, GBR or MBR. |

| /subscriptions/rab_rel	<br><br>_RAB release notification_ | Notifications report RAB releases in the network, i.e. when a terminal disconnects from the 3GPP network. Sandbox examples include: <ul><li> Terminal is removed from the Macro Network Scenario by the user <li> Terminal disconnects from a 3GPP PoA and connects to WiFi (RAB is released). </ul>  <br> Supported filters include: <ul><li> erabId: single value (or associateId, list of IP addresses) <li> plmnId: ignored <li> cellId: list of cell (if not present, RAB release on any cell) <li> QCI: ignored </ul> <br> Expiry Deadline is ignored. | As a Sandbox User, I can set a notification with no filters and I will get all RAB release events on any cell (terminal disconnect from 3GPP anywhere in the network - device removed or WiFi connection). <br><br> As a Sandbox User, I can get a RAB release notification for a specific terminal and I will get a notification, if that terminal disconnects from 3GPP. |

| subscriptions/meas_rep_ue <br><br>_Notification providing a UE measurement report (4G LTE), when available_ | *STF587 Milestone D consideration, depending on remaining time and effort* <br><br> Periodic events fit into MEC Sandbox scope (e.g. PERIODICAL_REPORT_STRONGEST_CELLS). Sandbox to trigger reports based on an internal period (not MEC app or Sandbox user configurable).  <br><br> Trigger-based events not supported.  | As a Sandbox user, I can set notifications to monitor UEs connected 4G LTE that include:  signal levels, cell connection, and neighbor cells. |

| subscriptions/ta <br><br>_Notification providing a UE timing advance report_ | *STF587 Milestone D consideration, depending on remaining time and effort*  <br><br>  Sandbox to trigger TA reports based on an internal period (not MEC app or Sandbox user configurable). | Timing advanced calculated based on terminal distance from 3GPP PoA.  <br><br> Applied to both 4G and 5G Cells. |

| subscriptions/ca_reconf <br><br>_Carrier aggregation reconfiguration notification_ | *Not supporting - future consideration beyond STF587* | Not supporting carrier aggregation emulation.  Too detailed for MEC Sandbox |

| subscriptions/s1_bearer <br><br>_S1 bearer modification notification_ | *Not supporting - future consideration beyond STF587*| S1 Bearer too detailed for MEC Sandbox |

| subscriptions/nr_meas_rep_ue <br><br>_Notification providing a UE measurement report (5G NR), when available_ | STF587 Milestone D consideration, depending on remaining time and effort <br><br> Periodic events fit into MEC Sandbox scope (e.g. NR_PERIODICAL). Sandbox to trigger reports based on an internal period (not MEC app or Sandbox user configurable). <br><br> Trigger-based events not supported. | As a Sandbox user, I can set notifications to monitor UE when connected to 5G NR that include:  signal levels, cell connection, and neighbor cells.  

> Other miscellaneous v2 differences:

| v1.1.1   | v2.1.1     | Notes         |

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

| PlmnInfo -- <br> includes Cell ID | Modified. <br><br> Cell ID removed from PlmnInfo | v1 Sandbox implementation setting Cell ID to static value |

# MEC013 - Location Service

> _All endpoints specified in v1 will be included in the MEC Sandbox as part of STF587.  v2 endpoints will be considered for Milestone D, depending availability in Forge and remaining STF587 effort.  No change in scenario specification since Milestone A._

This section describes how MEC013 has been integrated with the MEC Sandbox.

## MEC013 v1.1.1 - (available on Forge)

References:

* https://www.etsi.org/deliver/etsi_gs/MEC/001_099/013/01.01.01_60/gs_MEC013v010101p.pdf

* https://forge.etsi.org/rep/mec/gs013-location-api

* https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/mec/gs013-location-api/raw/master/LocationAPI.yaml

| Endpoint | Sandbox Usage        | Notes         |

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

| [/zones](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/mec/gs013-location-api/raw/master/LocationAPI.yaml#/operations/zones/zonesGet) | Discover the layout of the network – # of zones and their id's.  <br><br>List of Zones: zone id with number of access points and users in a zone. | As a user, I use this call to learn the number of zones and their id's. <br> <br>  I can use the zone information to learn more information about the network.  <br><br> **If I know nothing about the network, this end-point is a good API to first learn how the network is organized in zones, how many access points are in a zone, and where concentrations (#) of users may be.**

| [/zones/{zoneId}](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/mec/gs013-location-api/raw/master/LocationAPI.yaml#/operations/zones/zonesGetById)| Discover the Number of access points and users in a zone | Returns same data as /zones without an id. |

| [/zones/{zoneId}/accessPoints](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/mec/gs013-location-api/raw/master/LocationAPI.yaml#/operations/zones/zonesByIdGetAps)| Discover layout of points of access within a zone.  <br><br> List of Access Points - assessPoint data:  <br> - Access Point Id <br>- Geo-location: latitude, longitude <br>- Connection type <br> - Operation status <br> - # Users on the access point <br> - interest realm | As a user, I use this call to learn about points of access in the network, needing to reference by specific zones.  <br><br> **This is a point to first learn details of Access Points, for example their location and number of connected users.** |

| [/zones/{zoneId}<br>  /accessPoints/{accessPointId}](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/mec/gs013-location-api/raw/master/LocationAPI.yaml#/operations/zones/zonesByIdGetApsById) | accessPoint data for a single PoA |  |

| [/users](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/mec/gs013-location-api/raw/master/LocationAPI.yaml#/operations/users/usersGet) ?zoneId=<...>| Input = zoneID, optional accessPointId <br><br> Discover information of users within a zone.  <br><br> List of users in the zone (or PoA), including:  <br> - address <br>- connected accessPointId <br>- connected zoneId | As a user, I use this call to find users (devices) and their identifiers (addresses).  <br><br> **This is a point to first learn of a user, for example their address (i.e. id).** |

| [/users/{userId}](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/mec/gs013-location-api/raw/master/LocationAPI.yaml#/operations/users/usersGetById) | Input == userId (address) <br><br> Returns: <br>- address (same as input) <br>- accessPointId <br>- zoneId <br>- Geo-location: latitude, longitude | As a user after I know a user id (address), I use this call to find a users status: connected access point, connected zone, and geo-location.  <br><br> **This is a query to first learn a user's geo-location.** |

| [/subscriptions/zonalTraffic](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/mec/gs013-location-api/raw/master/LocationAPI.yaml#/operations/subscriptions/zonalTrafficSubGet) | Subscription related to changes for a zone:  users (devices) entering zone, exiting zone, transition across access points within a zone. <br><br>  Input = zoneId; interestRealm; userEventCriteria; duration | Notification == Zonal Presence Notification <br><br> As a Sandbox User or ME App, I use this notification to monitor changes in a zone.   |

| [/subscriptions/userTracking](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/mec/gs013-location-api/raw/master/LocationAPI.yaml#/operations/subscriptions/userTrackingSubGet) | Subscription related to changes of a specific user:  zone enter, zone exit, transition across points of access. <br><br> Input = address (device id), userEventCriteria | Notification == Zonal Presence Notification <br><br> As a Sandbox User or ME App, I use this notification to track location changes for a specific user (or device). |

| [/subscriptions/zonalStatus](https://forge.etsi.org/swagger/ui/?url=https://forge.etsi.org/gitlab/mec/gs013-location-api/raw/master/LocationAPI.yaml#/operations/subscriptions/zoneStatusGet) | Subscription related to changes in zone status:  # of users in a zone, # of users per AP in a zone, etc. <br><br> Input = zoneId; numberOfUsersZoneThreshold; numberOfUsersAPThreshold  | Notification == Zonal Status Notification <br><br> As a Sandbox User or ME App, I use this notification to monitor changes in a zone. |

## MEC 013 v2.1.1 - (published, not available on forge)

> v2 differences:  modifications, additions, etc.

References:

* https://www.etsi.org/deliver/etsi_gs/MEC/001_099/013/02.01.01_60/gs_MEC013v020101p.pdf

| v1.1.1   | v2.1.1     | Notes         |

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

| Timestamp == string (date and time)	| Timestamp == <br>- Uint32 seconds in Unix-time since Jan 1 1970 <br>- Uint32 nanoseconds in Unix-time | Modified - change in format |

| Location Info ==	| - latitude <br>- longitude <br>- altitude <br>- accuracy | Modified - much more complex type. See Section 6.5.3. Includes v.1.1.1 parameters, plus: shape information, velocity, etc. |

| /users/{userId} <br><br> UE Location Look-up of a single UE | /v2/users  <br><br> UE Location Lookup for a specific UE **or a group of UEs** | Modified  <br><br> Query input: <br>- zoneId(s) <br>- accessPointId(s)<br>-  UE address(s) |

|- | /v2/queries/distance | Addition – user can query the distance between a terminal an either a geo-location or another terminal (need to know addresses for both terminals) <br><br> Query input:  <br>-Parameter 1 == UE address <br>-Parameter 2 == geo-location (distance between UE and this point), <br>or UE address (distance between two UEs <br><br> *STF587 Milestone D consideration, depending on remaining time and effort* |

|- | /v2/subscriptions/periodic | Addition - user can subscribe notifications to periodic location notifications <br><br> Subscription input:  <br>- address of terminal to report <br>- accuracy <br>- frequency of reporting (period) <br>- duration <br><br> Notification (Subscription Notification) – issued periodically: <br>- UE address <br>- Current UE location: accuracy, altitude, latitude, longitude, time-stamp <br><br> *STF587 Milestone D consideration, depending on remaining time and effort* |

|- | /v2/subscriptions/distance |	Addition - user can subscribe to changes in distance between a UE (or set of UEs) and a reference UE (or set) <br><br> Subscription input: <br>- reference address(s) <br>- monitored address(s) <br>- distance <br>- accuracy <br>- criteria: all within, any within, all beyond, all beyond<br>-  check immediately on subscription <br>- max frequency of reporting <br>- duration <br>- max count - number of notifications <br><br>Notification (Subscription Notification) – issued on criteria: <br>- address and current Location for all UEs: reference and monitored <br><br> *STF587 Milestone D consideration, depending on remaining time and effort* |

|- | /v2/subscriptions/area/circle |	 Addition - user can subscribe to user(s) location in relation to a geo-located circle (defined by coordinates and a radius)  <br><br> Subscription input: <br>- UE address(s) <br>- Circle info: latitude, longitude, radius <br>- accuracy <br>- criteria: entering, leaving <br>- check immediately on subscription <br>- max frequency of reporting <br>- duration <br>- max count - number of notifications  <br><br>Notification (Subscription Notification) – – issued on criteria: <br>- UE address <br>- Current UE Location <br><br> *STF587 Milestone D consideration, depending on remaining time and effort* |

# MEC028 - WLAN Access Network Information Service

> _The MEC028 specification study was performed with the specification document only.  When the OpenAPI representation is available on Forge, this study will be revisited.  Note, the WLAN API does not have a v1 version.  This study is for v2 only_

This section describes how MEC028 has been integrated with the MEC Sandbox.

References:

* https://www.etsi.org/deliver/etsi_gs/MEC/001_099/028/02.01.01_60/gs_mec028v020101p.pdf

## MEC 028 v2.1.1 (published, not available on forge)

### Query Endpoints

| Endpoint |  Sandbox Usage | Notes

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

| /queries/ap/ap_information <br><br>_This resource is queried to retrieve information on WLAN Access Points in the network.  It can be used to query for all access points in the network, or sub-sets based on Access Point identity (MAC Address), SSID, etc._ | WLAN AP's uniquely identified via MAC Address.  <br><br> All APs share the same SSID. <br><br> "filter" (attribute-based filtering pattern from MEC009) expression used to select queries for specific APs (based on MAC Address) or group of APs (based on SSID).    | As a Sandbox user, I can use this call to learn about all the WLAN Hotspots in the network, including for each AP:  identity (MAC Address and SSID), # of connected terminals, BSS Load, geolocation, etc.  I do not need to know anything about the AP's and I can discovery them.  Filter input = null. <br><br><br>  As a Sandbox user, I can use this call to query status of a specific AP (if I know the AP MAC Address). For example, to learn the AP's current BSS Load, including # of connected STAs. |

| /queries/sta/sta_information <br><br>_This resource is queried to retrieve information on terminals (STA) connected to WLAN Access Points in the network.  It can be used to query and discover all terminals connected to WLAN.  Or, it can be used to query the current status of a terminal (STA), based on MAC Address or IPV4 Address_  | Terminals maintain a consistent IPV4 Address between 3GPP cellular (4G or 5G) and WLAN access connections, following the 3GPP trusted non-3GPP access model. <br><br> "filter" (attribute-based filtering pattern from MEC009) expression used to select queries for specific STA's (based on MAC Address or IPV4 Address). | As a Sandbox user, I can use this call to learn about all the terminals that are connected to WLAN Hotspots in the network, including for each STA: it's identity (STA MAC Address and IPV4 Address), connected AP (AP MAC Address and SSID), signal level in RSSI (calculated based on distance from AP in Sandbox).  I do not need to know anything about the STA's and I can discover them. Filter input = null.   <br><br><br> As a Sandbox user, I can use this call to query status of a specific terminal (if I know the STA's MAC Address or IPV4 Address).  For example, to learn current RSSI signal level or connected AP status.

### Subscription Endpoints

| Endpoint | Sandbox Usage | Notes

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

| /subscriptions <br><br>_The GET method is used to request information about the subscriptions for this requestor. Upon success, the response contains entity body with the list of links to the subscriptions that are present for the requestor_ | Return list of all WAIS subscriptions | Sandbox supports a single requester (i.e. single MEC app calling MEC services). |

| /subscriptions/assoc_sta <br><br>_WLAN event notifications about associated stations (terminals).  <br><br> Notification providing STA connection status on a per AP basis.  Notification includes: <ul><li> AP Id (MAC Address and SSID) <li> List of connected terminals (STA Id - MAC address and IPV4 address) </ul> Subscriptions must be created individually on an AP by AP basis (one AP per subscription per the spec data model)_ | Sandbox issues this notification on a change in STA connections on an AP (whenever a STA connects or disconnects from the AP). | As a Sandbox user, I can use this notification subscription to monitor connections on WLAN access points of interest.  <br><br> After learning from this notification that a STA is connected to a specific AP, I can:  <ul><li> Query ap_information to see how busy the AP may be (via BSS Load); <li> Query sta_information to check the WLAN signal level (via RSSI) of the STA.

| /subscriptions/sta_data_rate <br><br>_WLAN event notification about STA (terminal data rates)_ | Not supporting - future consideration beyond STF587  <br><br> It is unclear in the specification when this notification should be issued.  Section 5.2.5 notes preconditions where the service consumer has an active subscription that is periodic (every x seconds) or event triggered.  However, there are no parameters in the API to signal this information (periodic or event). |