| Internet-Draft | Joint RAW and MEC selection | March 2022 |
| Bernardos & Mourad | Expires 22 September 2022 | [Page] |
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document discusses mechanisms to allow a terminal influencing the selection of a MEC host for instantiation of the terminal-targeted MEC applications and functions, and (re)configuring the RAW network lying in between the terminal and the selected MEC host. This document assumes IETF RAW and ETSI MEC integration, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 September 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [I-D.ietf-raw-architecture], 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 [I-D.ietf-raw-use-cases], 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.¶
-----------
| PCE |
-----+-----
|
--+--
( )
( )
( )
--+--
|
-----------
| RAW PSE |
-----+-----
|
____________________+__________________________________
| *( ( o ) ) |
| RAW * * ^ |
| network ****** * / \ |
| ******* * / \ ----- |
| * ** ------- |app| |
| * * | RAW | ------- |
| ( ( o ) )* * |node |-| MEC | |
| ----- ^ *( ( o ) ) ------- ------- |
| |app| / \ ^ * |
| ----- / \ / \ ** |
| |app| ------- / \ *( ( o ) ) |
| ------- | RAW | ------- ^ (o |
| | MEC |------|node | | RAW | / \ -\---- |
| ------- ------- |node | / \ |term| |
| o) o) ------- ------- -0--0- |
| ----/- ----/- | RAW | |
| |term| |term| |node | |
| -0--0- -0--0- ------- |
|_______________________________________________________|
Figure 1 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.¶
[I-D.bernardos-raw-mec] 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:¶
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.¶
Figure 2 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.¶
------------
| MEC host |
------+-----
------------ ---------- |
| User | | Mobile | ------+---------------------
| App. LCM +---+ edge | | MEC host |
| Proxy | | orch. | | ----------------- |
------------ ---------- | + ------ ------ | |
| RAW | | ----- | | ME | |RAW | | |
| ctrl| -----------+ |app+··+ |serv| |ctrl| | |
---+--- | | ----- | ------ ------ | |
| +--+--+ | |app+··+ MEC platform | |
| | RAW | | ----- ----------------- |
+-----.+ PSE | ----------------------------
+-+-+-+
| | ( ( o ) ) ( ( o ) )
| | ^ ^
| | / \ / \
| | / \ / \
| | ------- -------
| +-----------| RAW |-------+ RAW |
+-------------+node | |node |
------- -------
The RAW ctrl - RAW PSE interface was first introduced in [I-D.bernardos-raw-mec].¶
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.¶
Figure 3 shows an exemplary signaling flow diagram.¶
+--------------+
+----------+ | MEC host |
+--+ | UALCMP | +---+ +----+ +----+ +----+ | +----+ |
|UE| +---+----+-+ |RAW| |MEAO| |RAW | |RAW | | +---+ |RAW | |
+--+ | |RAW | |PSE| +----+ |node| |node| | |MEP| |ctrl| |
| | |ctrl| +---+ | +----+ +----+ | +---+ +----+ |
| | +----+ | | | | +---|------|---+
| | | |<···RAW········>| | | |
| | | |<···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:¶
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:¶
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.¶
+--------------+
+----------+ | MEC host |
+--+ | UALCMP | +---+ +----+ +----+ +----+ | +----+ |
|UE| +---+----+-+ |RAW| |MEAO| |RAW | |RAW | | +---+ |RAW | |
+--+ | |RAW | |PSE| +----+ |node| |node| | |MEP| |ctrl| |
| | |ctrl| +---+ | +----+ +----+ | +---+ +----+ |
| | +----+ | | | | +---|------|---+
| | | |<··RAW·········>| | | |
| | | |<··signalling··········>| | |
| | | | | | | | |
|1.POST ../app_context| | | | | |
|····>| | | | | | | |
| |··MEC signalling······>|··MEC signalling········>| |
| | | | | | | 2.MEC-to-RAW
| | | | | | | |·····>|
| | | |<··2.RAW································|
| | |<·········|····signalling·>| | | |
| | | |·······················>| | |
| | | | | | | |<·····|
| |<······MEC·signalling··|<········MEC signalling··| |
| | | | | | | | |
|3.201 Created | | | | | |
|(AppContext) | | | | | |
| | | | | | | | |
Figure 4 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 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.¶
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.¶
+--------------+
+----------+ | MEC host |
+--+ | UALCMP | +---+ +----+ +----+ +----+ | +----+ |
|UE| +---+----+-+ |RAW| |MEAO| |RAW | |RAW | | +---+ |RAW | |
+--+ | |RAW | |PSE| +----+ |node| |node| | |MEP| |ctrl| |
| | |ctrl| +---+ | +----+ +----+ | +---+ +----+ |
| | +----+ | | | | +---|------|---+
| | | |<··RAW·········>| | | |
| | | |<··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 | | | | | |
|<····| | | | | | | |
| | | | | | | | |
Figure 5 shows an exemplary signaling flow diagram. We next explain each of the steps illustrated in the figure:¶
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).¶
+--------------+
+----------+ | MEC host |
+--+ | UALCMP | +---+ +----+ +----+ +----+ | +----+ |
|UE| +---+----+-+ |RAW| |MEAO| |RAW | |RAW | | +---+ |RAW | |
+--+ | |RAW | |PSE| +----+ |node| |node| | |MEP| |ctrl| |
| | |ctrl| +---+ | +----+ +----+ | +---+ +----+ |
| | +----+ | | | | +---|------|---+
| | | |<··RAW·········>| | | |
| | | |<··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 | | | | | |
|····>| | | | | | | |
| | | | | | | | |
Figure 5 shows an exemplary signaling flow diagram. We next explain each of the steps illustrated in the figure:¶
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:¶
TBD.¶
The work in this draft will be further developed and explored under the framework of the H2020 5Growth (Grant 856709).¶