Terminal-based joint selection and configuration of MEC host and DETNET-RAW network

Wireless operates on a shared medium, and transmissions cannot be fully deterministic due to uncontrolled interferences, including self-induced multipath fading. RAW (Reliable and Available Wireless) is an effort to provide Deterministic Networking on across a path that include a wireless interface. RAW provides for high reliability and availability for IP connectivity over a wireless medium. The wireless medium presents significant challenges to achieve deterministic properties such as low packet error rate, bounded consecutive losses, and bounded latency. RAW extends the DetNet Working Group concepts to provide for high reliability and availability for an IP network utilizing scheduled wireless segments and other media, e.g., frequency/time-sharing physical media resources with stochastic traffic: IEEE Std. 802.15.4 timeslotted channel hopping (TSCH), 3GPP 5G ultra-reliable low latency communications (URLLC), IEEE 802.11ax/be, and L-band Digital Aeronautical Communications System (LDACS), etc. Similar to DetNet, RAW technologies aim at staying abstract to the radio layers underneath, addressing the Layer 3 aspects in support of applications requiring high reliability and availability. As introduced in , RAW separates the path computation time scale at which a complex path is recomputed from the path selection time scale at which the forwarding decision is taken for one or a few packets. RAW operates at the path selection time scale. The RAW problem is to decide, amongst the redundant solutions that are proposed by the Patch Computation Element (PCE), which one will be used for each packet to provide a Reliable and Available service while minimizing the waste of constrained resources. To that effect, RAW defines the Path Selection Engine (PSE) that is the counter-part of the PCE to perform rapid local adjustments of the forwarding tables within the diversity that the PCE has selected for the Track. The PSE enables to exploit the richer forwarding capabilities with Packet (hybrid) ARQ, Replication, Elimination and Ordering (PAREO), and scheduled transmissions at a faster time scale. Multi-access Edge Computing (MEC) -- formerly known as Mobile Edge Computing -- capabilities deployed in the edge of the mobile network can facilitate the efficient and dynamic provision of services to mobile users. The ETSI ISG MEC working group, operative from end of 2014, intends to specify an open environment for integrating MEC capabilities with service providers' networks, including also applications from 3rd parties. These distributed computing capabilities will make available IT infrastructure as in a cloud environment for the deployment of functions in mobile access networks. One relevant exemplary scenario showing the need for an integration of RAW and MEC is introduced next. One of the main (and distinct) use cases of 5G is Ultra Reliable and Low Latency Communications (URLLC). Among the many so-called "verticals" that require URLLC features, the Industry 4.0 (also referred to as Wireless for Industrial Applications) is probably the one with more short-term potential. As identified in , this scenario also calls for RAW solutions, as cables are not that suitable for the robots and mobile vehicles typically used in factories. This is also a very natural scenario for MEC deployments, as bounded, and very low latencies are needed between the robots and physical actuators and the control logic managing them. This scenario includes a wireless domain, involving multiple MEC platforms to ensure low latency to applications, by being able to host MEC applications in several locations, and dynamically migrate the apps as the terminals move around and the serving MEC platform might no longer be capable of meeting the latency requirements. This document discussess mechanisms to allow the UE to influence/control jointly the RAW and MEC components deployed in the end-to-end path.

depicts an exemplary scenario that integrates a 3GPP 5G network, with ETSI MEC deployed at the edge, and an IETF RAW-capable wireless multi-hop backhaul segment connecting the RAN and the MEC hosts and UPFs. This setup can be used for example in a factory where multiple robots and AGVs are wirelessly connected, and controlled via remote apps. Control applications running in the edge (implemented as MEC applications) require bounded low latencies and a guaranteed availability, despite the mobility of the terminals and the changing wireless conditions. An heterogeneous wireless mesh network is used to provide connectivity inside the factory. explores already the integration of RAW and MEC. The current document goes a bit further, proposing solutions to allow terminal-based selection of the MEC platform where to instantiate an app taking into account RAW aspects.

The following terms used in this document are defined by the ETSI MEC ISG, and the IETF: MEC host. The mobile edge host is an entity that contains a mobile edge platform and a virtualization infrastructure which provides compute, storage, and network resources, for the purpose of running mobile edge applications. MEC platform. The mobile edge platform is the collection of essential functionalities required to run mobile edge applications on a particular virtualization infrastructure and enable them to provide and consume mobile edge services. MEPM. MEC Platform Manager. MEC applications. Mobile edge applications are instantiated on the virtualization infrastructure of the mobile edge host based on configuration requests validated by the mobile edge management. PAREO. Packet (hybrid) ARQ, Replication, Elimination and Ordering. PAREO is a superset Of DetNet's PREOF that includes radio-specific techniques such as short range broadcast, MUMIMO, constructive interference and overhearing, which can be leveraged separately or combined to increase the reliability. PSE. The Path Selection Engine (PSE) is the counter-part of the PCE to perform rapid local adjustments of the forwarding tables within the diversity that the PCE has selected for the Track. The PSE enables to exploit the richer forwarding capabilities with PAREO and scheduled transmissions at a faster time scale over the smaller domain that is the Track, in either a loose or a strict fashion. UALCMP. The User Application LifeCycle Management Proxy (UALCMP) exposes the Mx2 API to the device application. It allows the device application to request the following application lifecycle management operations from the MEC system: query the available applications, instantiation and deletion of an application and update of an existing application context.

This document defines extensions to: (i) enable a terminal to discover any RAW-enabled network on the path between the terminal and the MEC app host, and the RAW network associated capabilities; (ii) enable the terminal to request desired reliability and availability requirements to be met simultaneously by the MEC+RAW system; and, (iii) enable direct notifications from the RAW network to the terminal, to help with end-to-end application-level optimization. Most of the required extensions are related to ETSI MEC components and interfaces, and therefore are out of the scope of the IETF. However, we still briefly describe them for completeness, putting the main focus on the IETF RAW components and interactions. shows the components and interfaces impacted by the extensions described in this document. The MEC UALCMP is logically extended with a RAW controller (RAW ctrl) functionality, to enable a terminal to learn about the RAW and MEC capabilities of the 5G network it is attached to, and specify its requirements in terms of availability and reliability for joint MEC app instantiation and RAW network configuration.

The RAW ctrl - RAW PSE interface was first introduced in .

Here we specify how the terminal/UE is augmented with the additional capability of discovering a RAW network on the path to the hosts of its target MEC applications, and obtaining information about reliability and availability configuration in the RAW network. shows an exemplary signaling flow diagram.

| | | | | | | |<···signalling·········>| | | | | | | | | | | | |1.GET ../app_list | | | | | | |····>| | | | | | | | | |········MEC···········>|·····MEC················>| | | |<·······signalling·····|<····signalling··········| | | | | | | | | | | | |2.RAW info req.| | | | | | | |···>|·········>| | | | | | | |<···|<·········| | | | | | | | | | | | | | | |2.200 OK | | | | | | | |(Application List) | | | | | | | | | | | | | | | ]]> We next explain each of the steps illustrated in the figure: An application that requires use of a MEC app with specific reliability/availability requirements is started at the UE. The UE can either make use of a GET request to the MEC UALCMP extended to indicate that the UE is interested in reliability and availability information, or the UALCMP can decide to include this information based on policies. Either way, the UALCMP authorizes the request from the UE. The MEC system retrieves the list of UE applications available to the requesting UE (this might require interaction with other MEC system level components such as MEAO as depicted optionally in the figure). The UALCMP requests information related to reliability and availability from the RAW PSE through the RAW ctrl logical component. The UALCMP returns the 200 OK response to the device application, following ETSI MEC standards, but with its message body extended to include RAW parameters (namely, Reliability and availability characteristics of the application and its connectivity), such as: The assured round trip time in milliseconds supported by the MEC system for the MEC application instance. The assured connection bandwidth in kbit/s for the use of the MEC application instance. The assured jitter in milliseconds supported by the MEC system for the MEC application instance. The maximum percentage of packets failed. The assured number of redundant paths supported by the MEC system for the MEC application instance.

Here we specify how the UE is augmented with the capability to request the creation of a MEC app including requirements about reliability and availability.

| | | | | | | |<··signalling··········>| | | | | | | | | | | | |1.POST ../app_context| | | | | | |····>| | | | | | | | | |··MEC signalling······>|··MEC signalling········>| | | | | | | | | 2.MEC-to-RAW | | | | | | | |·····>| | | | |<··2.RAW································| | | |<·········|····signalling·>| | | | | | | |·······················>| | | | | | | | | | |<·····| | |<······MEC·signalling··|<········MEC signalling··| | | | | | | | | | | |3.201 Created | | | | | | |(AppContext) | | | | | | | | | | | | | | | ]]> shows an exemplary signaling flow diagram. We next explain each of the steps illustrated in the figure: The UE submits the POST request to the UALCMP. The message body contains the data structure for the application context to be created, which is extended to include reliability and availability attributes: The assured round trip time in milliseconds supported by the MEC system for the MEC application instance. The assured connection bandwidth in kbit/s for the use of the MEC application instance. The assured jitter in milliseconds supported by the MEC system for the MEC application instance. The maximum percentage of packets failed. The assured number of redundant paths supported by the MEC system for the MEC application instance. The UALCMP authorizes the request from the device application. The request is forwarded to the MEC system level management, which makes the decision on granting the context creation request. The MEC orchestrator triggers the creation of the application context in the MEC system, including the information about reliability and availability requirements. The UALCMP request the context creation to the MEAO, this request including the reliability and availability requirements of the application. The MEAO selects where to instantiate the application (meaning the MEC host and MEC platform), so it can meet all the requirements. The MEP request to the local RAW ctrl to establish the connectivity between the app and the UE meeting the indicated reliability and availability requirements. This involves additional steps between the RAW ctrl, the RAW PSE and the RAW nodes that are part of the established path(s), as described in . The UALCMP returns the 201 Created response to the UE with the message body containing the data structure of the created application context.

Here we specify how the UE is augmented with the capability to request the update of the context of a MEC app including requirements about reliability and availability. One example would be communicating new reliability/availability requirements.

| | | | | | | |<··signalling··········>| | | | | | | | | | | | |1.PUT ../app_contexts| | | | | | | {contextID} (AppContext) | | | | | |····>| | | | | | | | | |··MEC signalling······>|··MEC signalling········>| | | | | | | | | 2.MEC-to-RAW | | | | | | | |·····>| | | | |<··2.RAW································| | | |<·········|···signalling··>| | | | | | | |·······················>| | | | | | | | | | |<·····| | |<······MEC·signalling··|<········MEC signalling··| | | | | | | | | | | |3.204 No Content | | | | | | |<····| | | | | | | | | | | | | | | | | ]]> shows an exemplary signaling flow diagram. We next explain each of the steps illustrated in the figure: An application running on the UE making use of a MEC app might change its requirements for the MEC app and associated reliability and availability (for example, in an Industry 4.0 scenario, a robot control app might be required less latency to improve its precision). The UE updates a specific application context by sending a PUT request to the resource within the MEC system that represents it, with the message body containing the modified data structure of AppContext in which only the callback reference and/or application location constraints, and/or the application reliability and availability requirements (e.g., assured bandwidth, latency and reliability) may be updated. Through interactions with the RAW ctrl, the RAW PSE is indicated to perform the required updates in the RAW network (via signalling with RAW nodes). The UALCMP returns a "204 No Content" response.

Here we specify how the UE can receive updates about the RAW connectivity experienced by a MEC application, so it can react in time (e.g., implementing changes at the application level or selecting another point of attachment/slice).

| | | | | | | |<··signalling··········>| | | | | | | | | | | | | | | Event occurs (e.g., it is no longer | | | | | to keep assured RAW conditions) | | | | | | | | | | | | | | |1.MEC-to-RAW | | | | | | | |·······································>| | | | | | | | |<·····| | |<······MEC signalling··|<········MEC signalling··| | | | | | | | | | | |2.POST ../callback_ref | | | | | | ({Notification}) | | | | | | |<····| | | | | | | | |3.204 No Content | | | | | | |····>| | | | | | | | | | | | | | | | | ]]> shows an exemplary signaling flow diagram. We next explain each of the steps illustrated in the figure: If a change of the assured RAW conditions happens (which is detected via RAW OAM mechanisms, out of the scope of this document, and then notified to the MEC platform), this event reaches the MEC orchestrator, and finally the UALCMP. The UALCMP sends a POST message to the callback reference address provided by the device application as part of application context creation, with the message body containing the {Notification} data structure. The variable {Notification} is replaced with the data type specified for different notification events as specified in ETSI MEC standards, extended to include a modification to the RAW conditions offered to the user application instance: Updated assured round trip time in milliseconds supported by the MEC system for the MEC application instance. Updated assured connection bandwidth in kbit/s for the use of the MEC application instance. Updated maximum percentage of packets failed. Updated assured jitter in milliseconds supported by the MEC system for the MEC application instance. Updated assured number of redundant paths supported by the MEC system for the MEC application instance. The device application sends a "204 No Content" response to the UALCMP.

TBD.

The work of Carlos J. Bernardos in this document has been partially supported by the Horizon Europe PREDICT-6G (Grant 101095890), Hexa-X-II (101095759) and UNICO I+D 6G-DATADRIVEN-04 project (TSI-063000-2021-132).