## 8 Open Issues  
5 GS already provides multiple opportunities that can leverage the AFBW use cases, but there are still some challenges that are either roadmapped in the 3 GPP standardization or should be included in the research and then in the future scope of standardization:  
* _Availability of NS-enabled 5 GS_--At present, the vast majority of commercial 5G network deployments implement a non-standalone deployment architecture [150], which does not support NS. As a consequence, a 5G network can be perceived as an improvedversion of a 4G network (\"boosted\" eMBB-only network), which does not provide the capabilities needed to offer commercial AFBW services. * _Dynamic NS_--In the centralized approach to NS currently adopted by 3 GPP, there exist no touch-points for interaction between an MNO and slice tenants; no relevant interfaces are specified in the Operations Support System (OSS)/Business Support System (BSS), which could be used for slice negotiation, slice request, slice management, etc. This severely impacts the dynamicity of slice deployment and exposure to specific verticals, thus limiting the NS business potential [151]. * _Lack of direct Device to Device (D2D) link_--This is needed to provide short-distance direct communication between UEs, especially vehicular ones (automotive, UAVs, UGVs, etc. ), regardless of the serving PLMN. Such communication is extremely important for, e.g., information (presence, location, etc.) broadcasting in the neighborhood or data exchange in objects' swarms. Its standardization is still ongoing within the 3 GPP Release 18, \"5G Advanced\" (to be completed by the middle of 2024) [149]. * _UAV support in NR_--UAVs will play a key role in the AFBW use cases; however, the support of some important generic 5G RAN mechanisms has already been included up to Release 17 [148], and the dedicated support of UAVs in NR is available only in the scope of Release 18 [149]. * _Seamless edge application context switching_ (change of the edge cloud or server)--A PLMN should have the ability to predict a network-level handover, forward the served application's context in advance to the target server, and then perform a correlated AP-level and network-level handover; the required delay limit for latency-critical services may not be met during the context transfer [152] due to the procedure definition [153] and virtualization aspects [154,155]. The answer to this problem is user-context transfer control by the application [152]. Nevertheless, the issue of integration of various architectural frameworks (e.g., 5 GS, virtualization, and edge computing frameworks) with functional overlaps still exists and needs a thorough redesign of the integrated architecture to avoid the uncoordinated competition of overlapping mechanisms, unstable performance, etc. [128]. * _Lack of mechanisms for proactive, on-demand coverage adaptation_--There are no interfaces exposed by a PLMN to serve the requests for coverage improvements in the specific area; with dedicated RAN controllers, such as Open RAN (O-RAN) that support applications dedicated to RAN optimization and expose a controller's API, such mechanisms may be provided [156]. 5 GS and O-RAN have not been integrated yet, but there exists a proposed solution [157]. * _National roaming for specific groups of UEs_--Coverage problems in a specific PLMN could be solved by the permission of a re-connection to another PLMN providing the required QoS in the problematic area. However, the visited PLMN must be aware of, e.g., the need to provide a Local Break-Out (LBO) of the traffic to the home PLMN's MEC or temporarily host the relevant edge cloud application. Appropriate inter-PLMN AP-level and network-level handover coordination must be ensured.