idnits 2.17.00 (12 Aug 2021) /tmp/idnits6352/draft-bernardos-raw-joint-selection-raw-mec-02.txt: -(311): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(312): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(316): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(317): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(320): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(321): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(380): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(381): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(385): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(387): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(388): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(389): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(390): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(391): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(392): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(460): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(461): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(466): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(468): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(469): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(470): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(471): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(472): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(473): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(516): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(517): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(523): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(524): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(525): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 37 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (21 March 2022) is 54 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAW WG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Standards Track A. Mourad 5 Expires: 22 September 2022 InterDigital 6 21 March 2022 8 Terminal-based joint selection and configuration of MEC host and RAW 9 network 10 draft-bernardos-raw-joint-selection-raw-mec-02 12 Abstract 14 There are several scenarios involving multi-hop heterogeneous 15 wireless networks requiring reliable and available features combined 16 with multi-access edge computing, such as Industry 4.0. This 17 document discusses mechanisms to allow a terminal influencing the 18 selection of a MEC host for instantiation of the terminal-targeted 19 MEC applications and functions, and (re)configuring the RAW network 20 lying in between the terminal and the selected MEC host. This 21 document assumes IETF RAW and ETSI MEC integration, fostering 22 discussion about extensions at both IETF and ETSI MEC to better 23 support these scenarios. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 22 September 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction and Problem Statement . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Terminal-based joint selection and configuration of MEC host 61 and RAW network . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Extended User application look-up to support reliability 63 and availability information/capabilities . . . . . . . . 7 64 3.2. Extended Application context create to support reliability 65 and availability information/capabilities . . . . . . . . 9 66 3.3. Extended Application context update to support reliability 67 and availability information/capabilities . . . . . . . . 11 68 3.4. Receiving extended notification events . . . . . . . . . 12 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 72 7. Informative References . . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction and Problem Statement 77 Wireless operates on a shared medium, and transmissions cannot be 78 fully deterministic due to uncontrolled interferences, including 79 self-induced multipath fading. RAW (Reliable and Available Wireless) 80 is an effort to provide Deterministic Networking on across a path 81 that include a wireless interface. RAW provides for high reliability 82 and availability for IP connectivity over a wireless medium. The 83 wireless medium presents significant challenges to achieve 84 deterministic properties such as low packet error rate, bounded 85 consecutive losses, and bounded latency. RAW extends the DetNet 86 Working Group concepts to provide for high reliability and 87 availability for an IP network utilizing scheduled wireless segments 88 and other media, e.g., frequency/time-sharing physical media 89 resources with stochastic traffic: IEEE Std. 802.15.4 timeslotted 90 channel hopping (TSCH), 3GPP 5G ultra-reliable low latency 91 communications (URLLC), IEEE 802.11ax/be, and L-band Digital 92 Aeronautical Communications System (LDACS), etc. Similar to DetNet, 93 RAW technologies aim at staying abstract to the radio layers 94 underneath, addressing the Layer 3 aspects in support of applications 95 requiring high reliability and availability. 97 As introduced in [I-D.ietf-raw-architecture], RAW separates the path 98 computation time scale at which a complex path is recomputed from the 99 path selection time scale at which the forwarding decision is taken 100 for one or a few packets. RAW operates at the path selection time 101 scale. The RAW problem is to decide, amongst the redundant solutions 102 that are proposed by the Patch Computation Element (PCE), which one 103 will be used for each packet to provide a Reliable and Available 104 service while minimizing the waste of constrained resources. To that 105 effect, RAW defines the Path Selection Engine (PSE) that is the 106 counter-part of the PCE to perform rapid local adjustments of the 107 forwarding tables within the diversity that the PCE has selected for 108 the Track. The PSE enables to exploit the richer forwarding 109 capabilities with Packet (hybrid) ARQ, Replication, Elimination and 110 Ordering (PAREO), and scheduled transmissions at a faster time scale. 112 Multi-access Edge Computing (MEC) -- formerly known as Mobile Edge 113 Computing -- capabilities deployed in the edge of the mobile network 114 can facilitate the efficient and dynamic provision of services to 115 mobile users. The ETSI ISG MEC working group, operative from end of 116 2014, intends to specify an open environment for integrating MEC 117 capabilities with service providers' networks, including also 118 applications from 3rd parties. These distributed computing 119 capabilities will make available IT infrastructure as in a cloud 120 environment for the deployment of functions in mobile access 121 networks. 123 One relevant exemplary scenario showing the need for an integration 124 of RAW and MEC is introduced next. One of the main (and distinct) 125 use cases of 5G is Ultra Reliable and Low Latency Communications 126 (URLLC). Among the many so-called "verticals" that require URLLC 127 features, the Industry 4.0 (also referred to as Wireless for 128 Industrial Applications) is probably the one with more short-term 129 potential. As identified in [I-D.ietf-raw-use-cases], this scenario 130 also calls for RAW solutions, as cables are not that suitable for the 131 robots and mobile vehicles typically used in factories. This is also 132 a very natural scenario for MEC deployments, as bounded, and very low 133 latencies are needed between the robots and physical actuators and 134 the control logic managing them. 136 This scenario includes a wireless domain, involving multiple MEC 137 platforms to ensure low latency to applications, by being able to 138 host MEC applications in several locations, and dynamically migrate 139 the apps as the terminals move around and the serving MEC platform 140 might no longer be capable of meeting the latency requirements. 142 This document discussess mechanisms to allow the UE to influence/ 143 control jointly the RAW and MEC components deployed in the end-to-end 144 path. 146 ----------- 147 | PCE | 148 -----+----- 149 | 150 --+-- 151 ( ) 152 ( ) 153 ( ) 154 --+-- 155 | 156 ----------- 157 | RAW PSE | 158 -----+----- 159 | 160 ____________________+__________________________________ 161 | *( ( o ) ) | 162 | RAW * * ^ | 163 | network ****** * / \ | 164 | ******* * / \ ----- | 165 | * ** ------- |app| | 166 | * * | RAW | ------- | 167 | ( ( o ) )* * |node |-| MEC | | 168 | ----- ^ *( ( o ) ) ------- ------- | 169 | |app| / \ ^ * | 170 | ----- / \ / \ ** | 171 | |app| ------- / \ *( ( o ) ) | 172 | ------- | RAW | ------- ^ (o | 173 | | MEC |------|node | | RAW | / \ -\---- | 174 | ------- ------- |node | / \ |term| | 175 | o) o) ------- ------- -0--0- | 176 | ----/- ----/- | RAW | | 177 | |term| |term| |node | | 178 | -0--0- -0--0- ------- | 179 |_______________________________________________________| 181 Figure 1: Exemplary scenario depicting MEC and RAW in an industrial 182 environments 184 Figure 1 depicts an exemplary scenario that integrates a 3GPP 5G 185 network, with ETSI MEC deployed at the edge, and an IETF RAW-capable 186 wireless multi-hop backhaul segment connecting the RAN and the MEC 187 hosts and UPFs. This setup can be used for example in a factory 188 where multiple robots and AGVs are wirelessly connected, and 189 controlled via remote apps. Control applications running in the edge 190 (implemented as MEC applications) require bounded low latencies and a 191 guaranteed availability, despite the mobility of the terminals and 192 the changing wireless conditions. An heterogeneous wireless mesh 193 network is used to provide connectivity inside the factory. 195 [I-D.bernardos-raw-mec] explores already the integration of RAW and 196 MEC. The current document goes a bit further, proposing solutions to 197 allow terminal-based selection of the MEC platform where to 198 instantiate an app taking into account RAW aspects. 200 2. Terminology 202 The following terms used in this document are defined by the ETSI MEC 203 ISG, and the IETF: 205 MEC host. The mobile edge host is an entity that contains a 206 mobile edge platform and a virtualization infrastructure which 207 provides compute, storage, and network resources, for the purpose 208 of running mobile edge applications. 210 MEC platform. The mobile edge platform is the collection of 211 essential functionalities required to run mobile edge applications 212 on a particular virtualization infrastructure and enable them to 213 provide and consume mobile edge services. 215 MEPM. MEC Platform Manager. 217 MEC applications. Mobile edge applications are instantiated on 218 the virtualization infrastructure of the mobile edge host based on 219 configuration requests validated by the mobile edge management. 221 PAREO. Packet (hybrid) ARQ, Replication, Elimination and 222 Ordering. PAREO is a superset Of DetNet's PREOF that includes 223 radio-specific techniques such as short range broadcast, MUMIMO, 224 constructive interference and overhearing, which can be leveraged 225 separately or combined to increase the reliability. 227 PSE. The Path Selection Engine (PSE) is the counter-part of the 228 PCE to perform rapid local adjustments of the forwarding tables 229 within the diversity that the PCE has selected for the Track. The 230 PSE enables to exploit the richer forwarding capabilities with 231 PAREO and scheduled transmissions at a faster time scale over the 232 smaller domain that is the Track, in either a loose or a strict 233 fashion. 235 UALCMP. The User Application LifeCycle Management Proxy (UALCMP) 236 exposes the Mx2 API to the device application. It allows the 237 device application to request the following application lifecycle 238 management operations from the MEC system: query the available 239 applications, instantiation and deletion of an application and 240 update of an existing application context. 242 3. Terminal-based joint selection and configuration of MEC host and RAW 243 network 245 This document defines extensions to: (i) enable a terminal to 246 discover any RAW-enabled network on the path between the terminal and 247 the MEC app host, and the RAW network associated capabilities; (ii) 248 enable the terminal to request desired reliability and availability 249 requirements to be met simultaneously by the MEC+RAW system; and, 250 (iii) enable direct notifications from the RAW network to the 251 terminal, to help with end-to-end application-level optimization. 252 Most of the required extensions are related to ETSI MEC components 253 and interfaces, and therefore are out of the scope of the IETF. 254 However, we still briefly describe them for completeness, putting the 255 main focus on the IETF RAW components and interactions. 257 Figure 2 shows the components and interfaces impacted by the 258 extensions described in this document. The MEC UALCMP is logically 259 extended with a RAW controller (RAW ctrl) functionality, to enable a 260 terminal to learn about the RAW and MEC capabilities of the 5G 261 network it is attached to, and specify its requirements in terms of 262 availability and reliability for joint MEC app instantiation and RAW 263 network configuration. 265 ------------ 266 | MEC host | 267 ------+----- 268 ------------ ---------- | 269 | User | | Mobile | ------+--------------------- 270 | App. LCM +---+ edge | | MEC host | 271 | Proxy | | orch. | | ----------------- | 272 ------------ ---------- | + ------ ------ | | 273 | RAW | | ----- | | ME | |RAW | | | 274 | ctrl| -----------+ |app+··+ |serv| |ctrl| | | 275 ---+--- | | ----- | ------ ------ | | 276 | +--+--+ | |app+··+ MEC platform | | 277 | | RAW | | ----- ----------------- | 278 +-----.+ PSE | ---------------------------- 279 +-+-+-+ 280 | | ( ( o ) ) ( ( o ) ) 281 | | ^ ^ 282 | | / \ / \ 283 | | / \ / \ 284 | | ------- ------- 285 | +-----------| RAW |-------+ RAW | 286 +-------------+node | |node | 287 ------- ------- 289 Figure 2: Block diagram 291 The RAW ctrl - RAW PSE interface was first introduced in 292 [I-D.bernardos-raw-mec]. 294 3.1. Extended User application look-up to support reliability and 295 availability information/capabilities 297 Here we specify how the terminal/UE is augmented with the additional 298 capability of discovering a RAW network on the path to the hosts of 299 its target MEC applications, and obtaining information about 300 reliability and availability configuration in the RAW network. 302 Figure 3 shows an exemplary signaling flow diagram. 304 +--------------+ 305 +----------+ | MEC host | 306 +--+ | UALCMP | +---+ +----+ +----+ +----+ | +----+ | 307 |UE| +---+----+-+ |RAW| |MEAO| |RAW | |RAW | | +---+ |RAW | | 308 +--+ | |RAW | |PSE| +----+ |node| |node| | |MEP| |ctrl| | 309 | | |ctrl| +---+ | +----+ +----+ | +---+ +----+ | 310 | | +----+ | | | | +---|------|---+ 311 | | | |<···RAW········>| | | | 312 | | | |<···signalling·········>| | | 313 | | | | | | | | | 314 |1.GET ../app_list | | | | | | 315 |····>| | | | | | | | 316 | |········MEC···········>|·····MEC················>| | 317 | |<·······signalling·····|<····signalling··········| | 318 | | | | | | | | | 319 | |2.RAW info req.| | | | | | 320 | |···>|·········>| | | | | | 321 | |<···|<·········| | | | | | 322 | | | | | | | | | 323 |2.200 OK | | | | | | | 324 |(Application List) | | | | | | 325 | | | | | | | | | 327 Figure 3: Extended User application look-up 329 We next explain each of the steps illustrated in the figure: 331 1. An application that requires use of a MEC app with specific 332 reliability/availability requirements is started at the UE. The 333 UE can either make use of a GET request to the MEC UALCMP 334 extended to indicate that the UE is interested in reliability and 335 availability information, or the UALCMP can decide to include 336 this information based on policies. Either way, the UALCMP 337 authorizes the request from the UE. The MEC system retrieves the 338 list of UE applications available to the requesting UE (this 339 might require interaction with other MEC system level components 340 such as MEAO as depicted optionally in the figure). 342 2. The UALCMP requests information related to reliability and 343 availability from the RAW PSE through the RAW ctrl logical 344 component. 346 3. The UALCMP returns the 200 OK response to the device application, 347 following ETSI MEC standards, but with its message body extended 348 to include RAW parameters (namely, Reliability and availability 349 characteristics of the application and its connectivity), such 350 as: 352 * The assured round trip time in milliseconds supported by the 353 MEC system for the MEC application instance. 355 * The assured connection bandwidth in kbit/s for the use of the 356 MEC application instance. 358 * The assured jitter in milliseconds supported by the MEC system 359 for the MEC application instance. 361 * The maximum percentage of packets failed. 363 * The assured number of redundant paths supported by the MEC 364 system for the MEC application instance. 366 3.2. Extended Application context create to support reliability and 367 availability information/capabilities 369 Here we specify how the UE is augmented with the capability to 370 request the creation of a MEC app including requirements about 371 reliability and availability. 373 +--------------+ 374 +----------+ | MEC host | 375 +--+ | UALCMP | +---+ +----+ +----+ +----+ | +----+ | 376 |UE| +---+----+-+ |RAW| |MEAO| |RAW | |RAW | | +---+ |RAW | | 377 +--+ | |RAW | |PSE| +----+ |node| |node| | |MEP| |ctrl| | 378 | | |ctrl| +---+ | +----+ +----+ | +---+ +----+ | 379 | | +----+ | | | | +---|------|---+ 380 | | | |<··RAW·········>| | | | 381 | | | |<··signalling··········>| | | 382 | | | | | | | | | 383 |1.POST ../app_context| | | | | | 384 |····>| | | | | | | | 385 | |··MEC signalling······>|··MEC signalling········>| | 386 | | | | | | | 2.MEC-to-RAW 387 | | | | | | | |·····>| 388 | | | |<··2.RAW································| 389 | | |<·········|····signalling·>| | | | 390 | | | |·······················>| | | 391 | | | | | | | |<·····| 392 | |<······MEC·signalling··|<········MEC signalling··| | 393 | | | | | | | | | 394 |3.201 Created | | | | | | 395 |(AppContext) | | | | | | 396 | | | | | | | | | 398 Figure 4: Application context create 400 Figure 4 shows an exemplary signaling flow diagram. We next explain 401 each of the steps illustrated in the figure: 403 1. The UE submits the POST request to the UALCMP. The message body 404 contains the data structure for the application context to be 405 created, which is extended to include reliability and 406 availability attributes: 408 * The assured round trip time in milliseconds supported by the 409 MEC system for the MEC application instance. 411 * The assured connection bandwidth in kbit/s for the use of the 412 MEC application instance. 414 * The assured jitter in milliseconds supported by the MEC system 415 for the MEC application instance. 417 * The maximum percentage of packets failed. 419 * The assured number of redundant paths supported by the MEC 420 system for the MEC application instance. 422 The UALCMP authorizes the request from the device application. 423 The request is forwarded to the MEC system level management, 424 which makes the decision on granting the context creation 425 request. The MEC orchestrator triggers the creation of the 426 application context in the MEC system, including the information 427 about reliability and availability requirements. The UALCMP 428 request the context creation to the MEAO, this request including 429 the reliability and availability requirements of the application. 430 The MEAO selects where to instantiate the application (meaning 431 the MEC host and MEC platform), so it can meet all the 432 requirements. 434 2. The MEP request to the local RAW ctrl to establish the 435 connectivity between the app and the UE meeting the indicated 436 reliability and availability requirements. This involves 437 additional steps between the RAW ctrl, the RAW PSE and the RAW 438 nodes that are part of the established path(s), as described in 439 [I-D.bernardos-raw-mec]. 441 3. The UALCMP returns the 201 Created response to the UE with the 442 message body containing the data structure of the created 443 application context. 445 3.3. Extended Application context update to support reliability and 446 availability information/capabilities 448 Here we specify how the UE is augmented with the capability to 449 request the update of the context of a MEC app including requirements 450 about reliability and availability. One example would be 451 communicating new reliability/availability requirements. 453 +--------------+ 454 +----------+ | MEC host | 455 +--+ | UALCMP | +---+ +----+ +----+ +----+ | +----+ | 456 |UE| +---+----+-+ |RAW| |MEAO| |RAW | |RAW | | +---+ |RAW | | 457 +--+ | |RAW | |PSE| +----+ |node| |node| | |MEP| |ctrl| | 458 | | |ctrl| +---+ | +----+ +----+ | +---+ +----+ | 459 | | +----+ | | | | +---|------|---+ 460 | | | |<··RAW·········>| | | | 461 | | | |<··signalling··········>| | | 462 | | | | | | | | | 463 |1.PUT ../app_contexts| | | | | | 464 | {contextID} (AppContext) | | | | | 465 |····>| | | | | | | | 466 | |··MEC signalling······>|··MEC signalling········>| | 467 | | | | | | | 2.MEC-to-RAW 468 | | | | | | | |·····>| 469 | | | |<··2.RAW································| 470 | | |<·········|···signalling··>| | | | 471 | | | |·······················>| | | 472 | | | | | | | |<·····| 473 | |<······MEC·signalling··|<········MEC signalling··| | 474 | | | | | | | | | 475 |3.204 No Content | | | | | | 476 |<····| | | | | | | | 477 | | | | | | | | | 479 Figure 5: Application context update 481 Figure 5 shows an exemplary signaling flow diagram. We next explain 482 each of the steps illustrated in the figure: 484 1. An application running on the UE making use of a MEC app might 485 change its requirements for the MEC app and associated 486 reliability and availability (for example, in an Industry 4.0 487 scenario, a robot control app might be required less latency to 488 improve its precision). The UE updates a specific application 489 context by sending a PUT request to the resource within the MEC 490 system that represents it, with the message body containing the 491 modified data structure of AppContext in which only the callback 492 reference and/or application location constraints, and/or the 493 application reliability and availability requirements (e.g., 494 assured bandwidth, latency and reliability) may be updated. 496 2. Through interactions with the RAW ctrl, the RAW PSE is indicated 497 to perform the required updates in the RAW network (via 498 signalling with RAW nodes). 500 3. The UALCMP returns a "204 No Content" response. 502 3.4. Receiving extended notification events 504 Here we specify how the UE can receive updates about the RAW 505 connectivity experienced by a MEC application, so it can react in 506 time (e.g., implementing changes at the application level or 507 selecting another point of attachment/slice). 509 +--------------+ 510 +----------+ | MEC host | 511 +--+ | UALCMP | +---+ +----+ +----+ +----+ | +----+ | 512 |UE| +---+----+-+ |RAW| |MEAO| |RAW | |RAW | | +---+ |RAW | | 513 +--+ | |RAW | |PSE| +----+ |node| |node| | |MEP| |ctrl| | 514 | | |ctrl| +---+ | +----+ +----+ | +---+ +----+ | 515 | | +----+ | | | | +---|------|---+ 516 | | | |<··RAW·········>| | | | 517 | | | |<··signalling··········>| | | 518 | | | | | | | | | 519 | | | Event occurs (e.g., it is no longer | | 520 | | | to keep assured RAW conditions) | | 521 | | | | | | | | | 522 | | | |1.MEC-to-RAW | | | | 523 | | | |·······································>| 524 | | | | | | | |<·····| 525 | |<······MEC signalling··|<········MEC signalling··| | 526 | | | | | | | | | 527 |2.POST ../callback_ref | | | | | 528 | ({Notification}) | | | | | | 529 |<····| | | | | | | | 530 |3.204 No Content | | | | | | 531 |····>| | | | | | | | 532 | | | | | | | | | 534 Figure 6: Receiving notification events 536 Figure 5 shows an exemplary signaling flow diagram. We next explain 537 each of the steps illustrated in the figure: 539 1. If a change of the assured RAW conditions happens (which is 540 detected via RAW OAM mechanisms, out of the scope of this 541 document, and then notified to the MEC platform), this event 542 reaches the MEC orchestrator, and finally the UALCMP. 544 2. The UALCMP sends a POST message to the callback reference address 545 provided by the device application as part of application context 546 creation, with the message body containing the {Notification} 547 data structure. The variable {Notification} is replaced with the 548 data type specified for different notification events as 549 specified in ETSI MEC standards, extended to include a 550 modification to the RAW conditions offered to the user 551 application instance: 553 * Updated assured round trip time in milliseconds supported by 554 the MEC system for the MEC application instance. 556 * Updated assured connection bandwidth in kbit/s for the use of 557 the MEC application instance. 559 * Updated maximum percentage of packets failed. 561 * Updated assured jitter in milliseconds supported by the MEC 562 system for the MEC application instance. 564 * Updated assured number of redundant paths supported by the MEC 565 system for the MEC application instance. 567 3. The device application sends a "204 No Content" response to the 568 UALCMP. 570 4. IANA Considerations 572 TBD. 574 5. Security Considerations 576 TBD. 578 6. Acknowledgments 580 The work in this draft will be further developed and explored under 581 the framework of the H2020 5Growth (Grant 856709). 583 7. Informative References 585 [I-D.bernardos-raw-mec] 586 Bernardos, C. J. and A. Mourad, "Extensions to enable 587 wireless reliability and availability in multi-access edge 588 deployments", Work in Progress, Internet-Draft, draft- 589 bernardos-raw-mec-03, 27 January 2022, 590 . 593 [I-D.ietf-raw-architecture] 594 Thubert, P. and G. Z. Papadopoulos, "Reliable and 595 Available Wireless Architecture", Work in Progress, 596 Internet-Draft, draft-ietf-raw-architecture-04, 4 March 597 2022, . 600 [I-D.ietf-raw-use-cases] 601 Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F. 602 Theoleyre, "RAW use-cases", Work in Progress, Internet- 603 Draft, draft-ietf-raw-use-cases-05, 23 February 2022, 604 . 607 Authors' Addresses 609 Carlos J. Bernardos 610 Universidad Carlos III de Madrid 611 Av. Universidad, 30 612 28911 Leganes, Madrid 613 Spain 614 Phone: +34 91624 6236 615 Email: cjbc@it.uc3m.es 616 URI: http://www.it.uc3m.es/cjbc/ 618 Alain Mourad 619 InterDigital Europe 620 Email: Alain.Mourad@InterDigital.com 621 URI: http://www.InterDigital.com/