Internet-Draft Joint RAW and MEC selection September 2023
Bernardos & Mourad Expires 14 March 2024 [Page]
Workgroup:
RAW WG
Internet-Draft:
draft-bernardos-detnet-raw-joint-selection-raw-mec-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
CJ. Bernardos
UC3M
A. Mourad
InterDigital

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

Abstract

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.

Status of This Memo

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 14 March 2024.

Table of Contents

1. Introduction and Problem Statement

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 [RFC9450], 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: Exemplary scenario depicting MEC and RAW in an industrial environments

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.

2. Terminology

The following terms used in this document are defined by the ETSI MEC ISG, and the IETF:

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

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 |
                               -------       -------
Figure 2: Block diagram

The RAW ctrl - RAW PSE interface was first introduced in [I-D.bernardos-raw-mec].

3.1. Extended User application look-up to support reliability and availability information/capabilities

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)   |       |        |       |        |      |
 |     |    |          |       |        |       |        |      |
Figure 3: Extended User application look-up

We next explain each of the steps illustrated in the figure:

  1. 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).
  2. The UALCMP requests information related to reliability and availability from the RAW PSE through the RAW ctrl logical component.
  3. 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.

3.2. Extended Application context create to support reliability and availability information/capabilities

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: Application context create

Figure 4 shows an exemplary signaling flow diagram. We next explain each of the steps illustrated in the figure:

  1. 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.

  2. 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 [I-D.bernardos-raw-mec].
  3. The UALCMP returns the 201 Created response to the UE with the message body containing the data structure of the created application context.

3.3. Extended Application context update to support reliability and availability information/capabilities

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: Application context update

Figure 5 shows an exemplary signaling flow diagram. We next explain each of the steps illustrated in the figure:

  1. 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.
  2. 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).
  3. The UALCMP returns a "204 No Content" response.

3.4. Receiving extended notification events

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 6: Receiving notification events

Figure 5 shows an exemplary signaling flow diagram. We next explain each of the steps illustrated in the figure:

  1. 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.
  2. 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.
  3. The device application sends a "204 No Content" response to the UALCMP.

4. IANA Considerations

TBD.

5. Security Considerations

TBD.

6. Acknowledgments

The work of Carlos J. Bernardos in this document has been partially supported by the Horizon Europe PREDICT-6G (Grant 101095890) and UNICO I+D 6G-DATADRIVEN-04 project.

7. Informative References

[I-D.bernardos-raw-mec]
Bernardos, C. J. and A. Mourad, "Extensions to enable wireless reliability and availability in multi-access edge deployments", Work in Progress, Internet-Draft, draft-bernardos-raw-mec-05, , <https://datatracker.ietf.org/doc/html/draft-bernardos-raw-mec-05>.
[I-D.ietf-raw-architecture]
Thubert, P., "Reliable and Available Wireless Architecture", Work in Progress, Internet-Draft, draft-ietf-raw-architecture-15, , <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-15>.
[RFC9450]
Bernardos, CJ., Ed., Papadopoulos, G., Thubert, P., and F. Theoleyre, "Reliable and Available Wireless (RAW) Use Cases", RFC 9450, DOI 10.17487/RFC9450, , <https://www.rfc-editor.org/info/rfc9450>.

Authors' Addresses

Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes, Madrid
Spain
Alain Mourad
InterDigital Europe