 illustrated in the Figure 6.4.4. 1. If a MEC application needs periodic UE location reports, the application sends the "cre- ate UE Location subscription" message to the Location Service, indicating UE(s). 2. The Location Service responds with a resource URI containing the subscription ID. API client Location Service 1. POST: create UE Location subscription 2. Response: subscription created with subscription ID 3. POST: UE Location notification API client Location Service Figure 6.4.4 UE location subscribe procedure (Source: Reproduced with permission from © ETSI). 6 Enabling Technologies 3. The Location Service periodically reports the requested UE(s) location. ETSI MEC API's data model is based on JavaScript Object Notation (JSON), which uses HTTP over TLS, also known as HTTPS, defined in IETF RFC 2818. Usage of HTTP without TLS is not recommended. 6.4.4 ETSI MEC Deployment in 3GPP 5G Systems Even though the ETSI MEC standard is access-agnostic (and thus applicable to any kind of network), deployment in 5G systems is a key aspect in the success of this technology. Figure 6.4.5 illustrates an NG-RAN, in which multiple base stations (gNBs and ng-eNBs) are connected to the AMF/UPF elements in the 5GC through NG interfaces (for further details about NG-RAN architecture, refer to Chapter 4). Even though MEC is expected to be deployed close to edge (i.e. in NG-RAN), formally it is not part of the NG-RAN architecture (and thus is not shown in Figure 6.4.5). In this architecture the user-plane data coming from terminals (and base stations) are forwarded to UPF, and the control plane to AMF elements. As the MEC data plane needs to be able to route user-plane packets to the MEC system, it can only be connected to a UPF. This, however, is not explicitly defined in the standard. Having said that, according to 3GPP TS 23.501, the 5G system may also include non-3GPP Network Elements, one of which can be MEC. The following mapping between ETSI MEC entities and 3GPP entities can be envisioned: UPFs handle the user plane of Pr