Enhanced transport level marking for protocol data unit set-level quality of service handling in wireless communications

Abstract

This disclosure describes systems, methods, and devices for supporting protocol data unit (PDU) set-level quality of service (QoS) handling. Processing circuitry of an application function (AF), of a user plane function (UPF), and of a session management function (SMF) may provide, by the AF, protocol description information for PDU set-level QoS handling to the UPF, the PUD set-level QoS handling indicative of PDU set-level information; identify, by the SMF, the protocol description information; provide, by the SMF, the protocol description information to the UPF; identify, by the UPF, a PSI of a detected downlink packet either based on matching the protocol description metadata received by the UPF; encapsulate, by the UPF, the downlink packet in a general packet radio service tunneling protocol for user plane (GTP-U) header.

Description

[0001] Attorney Docket No.: AF7269-PCT (31517-3527) ENHANCED TRANSPORT LEVEL MARKING FOR PROTOCOL DATA UNIT SET- LEVEL QUALITY OF SERVICE HANDLING IN WIRELESS COMMUNICATIONS CROSS-REFERENCE TO RELATED PATENT APPLICATION(S) This application claims the benefit of U.S. Provisional Application No. 63 / 595,048, filed November 1, 2023, the disclosure of which is incorporated herein by reference as if set forth in full. TECHNICAL FIELD This disclosure generally relates to systems and methods for wireless communications and, more particularly, to transport level marking for protocol data unit set-level quality of service in wireless communications. BACKGROUND Wireless devices are becoming widely prevalent and are increasingly using wireless channels. The 3rdGeneration Partnership Program (3GPP) is developing one or more standards for wireless communications. BRIEF DESCRIPTION OF THE DRAWINGS FIG .1 shows an example system for transport level marking supporting protocol data unit (PDU) set-level Quality of Service (QoS) handling, in accordance with one or more embodiments of the present disclosure. FIG. 2 shows an example of PDU sets and data bursts, in accordance with one or more embodiments of the present disclosure. FIG. 3 depicts an example network architecture, in accordance with one or more example embodiments of the present disclosure FIG. 4 illustrates a wireless network that includes a user equipment (UE) communicatively coupled with an access network (AN) via a connection, in accordance with one or more embodiments of the present disclosure. FIG. 5 illustrates components capable of reading instructions from a machine-readable or computer-readable medium, in accordance with one or more embodiments of the present disclosure. FIG.6 illustrates an example cellular network, in accordance with one or more embodiments of the present disclosure. FIG. 7 shows example network deployments, in accordance with one or more example embodiments of the present disclosure. FIG.8 depicts an example extended reality (XR) traffic model, in accordance with one or more example embodiments of the present disclosure. FIG. 9 depicts an example architecture and system model for XR traffic, in accordance with one or more example embodiments of the present disclosure. Attorney Docket No.: AF7269-PCT (31517-3527) FIG. 10 depicts example Fifth Generation XR (5G-XR) functions integrated in a 5G System (5GS), in accordance with one or more example embodiments of the present disclosure. FIG. 11 depicts an example 5G-XR architecture integrated in 5G and related interfaces, in accordance with one or more example embodiments of the present disclosure. FIG. 12 depicts an example of processor operations for XR applications, in accordance with one or more example embodiments of the present disclosure. DETAILED DESCRIPTION The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, algorithm, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all available equivalents of those claims. Wireless devices may operate as defined by technical standards. For cellular telecommunications, the 3rd Generation Partnership Program (3GPP) defines communication techniques, including for differentiated services code point (DSCP) marking, quality of service (QoS) flows, priority levels, and allocation and retention priority (ARP). Release 19 (Rel-19) of 3GPP is considering the use of protocol data unit (PDU) set QoS information for DSCP marking over the N3 / N9 interface in the transport network. In particular, 3GPP is considering whether, how, and what PDU set QoS information may be used for DSCP marking on an outer header of downlink packets in a PDU set over the N3 / N9 interface in the transport network to enable differentiated handling of transport packets carrying PDU sets within a QoS flow. Extended reality (XR) is a catch-all term that refers to augmented reality (AR), virtual reality (VR), mixed reality or mediated reality (MR) technologies, where “X” in “XR” is a variable that can interpolate between these various realities or extrapolate or extend beyond them. The XR fields are rapidly growing and being applied in a wide range of areas, such as entertainment, marketing, real estate, training, maintenance, and remote work. The present disclosure is generally related to wireless communication, cellular networks, cloud computing, edge computing, data centers, network topologies, and communication system implementations, and in particular, to transport level marking in fifth generation systems (5GS) for support of protocol data unit (PDU) set-level quality of service (QoS) handling. The following discussion is described in the context of XR data transmission, however, it should be understood that the embodiments herein are not limited to XR data, and can be straightforwardly applied to other types of critical data, such as cloud gaming (CG) data, ultra-reliable low latency communications (URLLC) data, IoT data, QoS flows / data, and / or any other type of high- priority data / traffic. Attorney Docket No.: AF7269-PCT (31517-3527) 3GPP defines PDU sets as one or more PDUs carrying a payload. An example PDU set may include encoded video frames or slices. For video and extended reality applications, for example, an important feature is QoS handling on a PDU set-basis (e.g., in contrast with handling individual PDUs). Using a video frame example, discarding a video frame in a set of related video frames (e.g., for a video title) may undermine a decoder’s ability to decode other video frames in the set, so it is important to be able to identify that PDUs may belong to a PDU set so that QoS handling may occur. Rel-18 of 3GPP includes text in technical standard 23.501 specifying that the Session Management Function (SMF) in the 5G core (5GC) network determines the DSCP marking to be used for a specific QoS flow, taking into account the5G QoS identifier (5QI), the priority level, and the ARP: “For every QoS Flow, the SMF shall determine the transport level packet marking value (e.g., the DSCP in the outer IP header) based on the 5QI, the Priority Level (if explicitly signaled) and optionally, the ARP priority level and provide the transport level packet marking value to the UPF.” The RAN1 release (Rel-)17 Study Item “Study on XR Evaluations for NR” has shown that eXtended Reality (XR) and Cloud Gaming (CG) are within the use cases and services considered important for NR in Rel-18 and beyond. In general, XR and CG are wide terms referring to various types of augmented, virtual, and mixed environments, where human-to-machine and human-to-human communications are performed with the assistance of handheld and wearable end user devices (UEs). Cloud gaming (CG) refers to a group of use cases where the overwhelming majority of computations related to gaming (e.g., single-player or multi-player games) is / are offloaded from a UE 1802 to an edge compute node or remote server(s) (e.g., XR server(s) 838 of Figure 8, server(s) 338 of Figure 3, and / or the like). XR is a broad-scope umbrella term for multiple heterogeneous use cases and services that were studied and outlined in 3GPP TR 22.842, 3GPP TR 26.928, among others. These XR use cases can be roughly divided into AR, VR, MR. While XR and CG present a set of attractive use cases for future mobile systems, they also impose a set of challenges for NR / 5GS that need to be studied and potentially addressed. Many of the XR and CG use cases are characterized by quasi-periodic traffic (with possible jitter) with high data rate in the downlink (DL) (e.g., video streams, and / or the like) combined with the frequent UL (e.g., pose / control update) and / or UL video streams. Both DL and UL traffic are also characterized by relatively strict packet delay budget (PDB). Many of the end-user XR and CG devices are expected to be mobile and small-scale (or small form factor) with limited battery power resources. Therefore, additional power enhancements and / or power-saving enhancements may be needed to reduce the overall UE power consumption when running XR / CG services and to extend the effective UE battery lifetime. As part of their Release (Rel-)19, 3GPP has initiated a study on further 5GS enhancements for support of eXtended Reality and Media (XRM) services. One key issue in the Rel-19 XRM study 3GPP TR 23.700-70 is: “Key Issue #3: Leverage PDU Set QoS information for DSCP marking over N3 / N9 in the transport network”, which aims at addressing the following points: “Study whether, how, and Attorney Docket No.: AF7269-PCT (31517-3527) what PDU Set QoS information can be used for DSCP marking on the outer header of downlink packets of the PDU Set over N3 / N9 in the transport network (e.g., to enable differentiated handling of transport packets carrying PDU Sets within QoS Flow).” The relevant stage-3 specification, 3GPP TS 29.244, defines an Information Element (IE) named Transport Level Marking IE that is included in the Forwarding Action Rule (FAR): “The Transport Level Marking IE type shall be encoded as shown in Figure 8.2.12-1. It indicates the DSCP to be used for UL / DL transport level marking.” Bits “The ToS / Traffic Class shall be encoded on two octets as an OctetString. The first octet shall contain the DSCP value in the IPv4 Type-of-Service or the IPv6 Traffic-Class field and the second octet shall contain the ToS / Traffic Class mask field, which shall be set to “0xFC”. See clause 5.3.15 of 3GPP TS 29.212 [8]. NOTE: The original ECN bits in the IP header of user plane packets are not changed after applying transport level marking.” According to existing 3GPP specifications, all transport layer packets associated with the same QoS Flow will be mapped with the same transport level marking (e.g., with the same DSCP marking). For XRM services, QoS handling in the 5GS is performed at the PDU set level, namely, based on upper layer information, all PDUs corresponding to a common application-level construct (e.g., a video frame) are handled together by 5GS. For instance, in presence of radio congestion, all PDUs associated with the same PDU set can be dropped together. Moreover, each PDU Set is associated with a PDU Set Importance value that allows the Radio Access Network (RAN) to prioritize the discarding of less important PDU Sets in presence of radio congestion. It is noted that PDU Sets associated with different PDU Set Importance (PSI) value can be carried within the same QoS Flow. For instance, when the video encoding is based on I-, B- and P- frames (e.g., Intra-frames, Predicted frames, and Bi-Directional frames), it may be beneficial in presence of network congestion to drop B- and P-frames first in order to spare the I-frames (e.g., which carry most valuable codec information). If the 5GS is instructed to map I-frames onto PDU Sets with Attorney Docket No.: AF7269-PCT (31517-3527) high PDU Set Importance, while mapping B- and P-frames to PDU Sets with low PDU Set Importance, this will effectively lead the RAN to prioritize dropping of B- and P-frames in presence of radio congestion. Given that PDU Sets associated with different PDU Set Importance (PSI) can be carried within the same QoS Flow, it would be desirable to allow GTP-U packets from the same QoS Flow to map to multiple DSCP code points in the transport network depending on the PSI value associated with the GTP-U packet. Existing specifications (e.g., [TS23501] § 5.8.2.7) allow a single transport level marking per QoS Flow. This mapping does not allow the transport network to discriminate more important from less important data (e.g., to discriminate packets associated with different PDU Set Importance). The embodiments discussed herein assume that packets associated with the same QoS Flow can have different transport level markings (e.g., different DSCP markings) depending on the PDU Set Importance value associated with the GTP-U packets. The SMF provides a list of Transport Level Markings for each possible PDU Set Importance value to the UPF. The new key issue from the Rel-19 XRM study referred above (e.g., Key Issue #3 in 3GPP TR 23.700-70) aims to study “how, and what PDU Set QoS information can be used for DSCP marking on the outer header of downlink packets of the PDU Set over N3 / N9 in the transport network (e.g., to enable differentiated handling of transport packets carrying PDU Sets within QoS Flow)”. Given that PDU Sets associated with different PDU Set Importance (PSI) can be carried within the same QoS Flow, it would be desirable to allow GTP-U packets from the same QoS Flow to map to multiple DSCP code points in the transport network depending on the PSI value associated with the GTP-U packet. The IETF has defined the Assured Forwarding (AF) per-hop behavior (see e.g., RFC 2597 and RFC 3260). Assured forwarding allows the operator to provide assurance of delivery as long as the traffic does not exceed some subscribed / configured rate. Traffic that exceeds the subscribed / configures rate faces a higher probability of being dropped if congestion occurs. The AF behavior group defines four separate AF classes with all traffic within one class having the same priority. Within each class, packets are given a drop precedence (high, medium or low, where higher precedence means more dropping). The combination of classes and drop precedence yields twelve separate DSCP encodings from AF11 through AF43 (see e.g., table 1-1).

[0002] Attorney Docket No.: AF7269-PCT (31517-3527) Table 1-1: Assured Forwarding behavior group Drop precedence Class 1 Class 2 Class 3 Class 4 ent classes. Should congestion occur between classes, the traffic in the higher class is given priority. Rather than using strict priority queuing, more balanced queue servicing algorithms such as weighted fair queueing are likely to be used. If congestion occurs within a class, the packets with the higher drop precedence are discarded first. From the description above, it follows that the AF drop precedence (low, medium, high) in the DSCP marking is a good match for the PDU Set Importance (PSI). Similar to how the PSI can be used by RAN for prioritizing dropping of PDU Sets with lower importance in presence of radio congestion, the transport level nodes can rely on the AF drop precedence for prioritizing dropping of packets associated with PDU Sets of lower importance in presence of transport network congestion. The SMF may control transport level marking. Based on information received from the Policy Control Function (PCF), the Session Management Function (SMF) determines Packet Detection Rules (PDRs) and a Forward Action Rule (FAR) for a QoS Flow, and then forwards the PDRs and FAR to the User Plane Function (UPF) over the N4 reference point. The UPF uses the PDRs to perform detection of downstream data arriving on the N6 reference point. When a match is found, the UPF encapsulates the downlink data packet with a GTP-U header as indicated in the FAR. The UPF then forwards the GTP-U packet on the N3 reference point and includes the DSCP marking in the transport level header, again, as indicated in the FAR. In case of PDU Set-level QoS handling, the Application Function (AF) includes a Protocol Description information that allows the 5GS to determine the PDU Set information. The Protocol Description includes information on the header, extension header (e.g., RTP / SRTP) and payload type (e.g., H.264) used by the service data flow. The SMF forwards the Protocol Description information together with the related PDRs. The UPF uses the Protocol Description to determine the PDU Set-level information (also referred to as “PDU Set information”), including the following (see e.g., [TS23501] § 5.37.5.2): PDU Set Sequence Number; Indication of End PDU of the PDU Set; PDU Sequence Number within a PDU Set; PDU Set Size in bytes; and PDU Set Importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow. Attorney Docket No.: AF7269-PCT (31517-3527) After determining the PDU Set-level information of a data packet arriving on N6, the UPF encapsulates the downlink data packet with a GTP-U header as indicated in the FAR and includes the PDU Set-level information in the GTP-U header. The UPF then forwards the GTP-U packet on the N3 reference point and includes the DSCP marking in the transport level header as indicated in the FAR. According to existing specifications the UPF can use a single DSCP marking for all packets associated with the same QoS Flow. In one or more embodiments, the present disclosure enables transport level marking in 5GS for support of PDU set-level QoS handling. The SMF may control the transport level marking to support multiple DSCP markings for a same QoS flow. Here, the Forward Action Rule (FAR) information on N4 includes a Transport Level Marking List that contains a list of PDU Set Importance values, each of which is associated with a DSCP marking. After determining the PDU Set-level information of a data packet arriving on N6, the UPF encapsulates the downlink data packet with a GTP-U header as indicated in the FAR and includes the PDU Set-level information in the GTP-U header. The UPF then forwards the GTP-U packet on the N3 reference point and includes the DSCP marking in the transport level header that corresponds to the derived PDU Set Importance value, as indicated in the Transport Level Marking List in the FAR. In some examples, the FAR (see e.g., 3GPP TS 29.244, Table 7.5.2.3-2) is extended as indicated by table 1-2. Table 1-2: Forwarding Parameters IE in FAR including new parameter for Transport Level Marking for PDU Sets Octet 1 and 2 Forwarding Parameters IE Type = 4 (decimal) Octets 3 and 4 Length = n n n er t ing Attorney Docket No.: AF7269-PCT (31517-3527) EPC, it shall contain the value of the DSCP in the TOS / Traffic Class field set based on the QCI, and optionally the t ing g nt D Attorney Docket No.: AF7269-PCT (31517-3527) IPv6 Neighbour Solicitation based on the local cache information for the Ethernet PDUs. ype ork r and er nt ng Attorney Docket No.: AF7269-PCT (31517-3527) Additionally or alternatively, the QoS Enforcement Rule (QER) information can be used on N4 with or instead of the FAR to include the new Transport Level Marking List. The above descriptions are for purposes of illustration and are not meant to be limiting. Numerous other examples, configurations, processes, algorithms, etc., may exist, some of which are described in greater detail below. Example embodiments will now be described with reference to the accompanying figures. FIG .1 shows an example system 100 for transport level marking supporting PDU set-level QoS handling, in accordance with one or more embodiments of the present disclosure. Referring to FIG.1, the SMF 346 may support multiple DSCP markings for a same QoS flow. In case of PDU Set-level QoS handling, the Application Function (AF) 360 includes a Protocol Description 102 information that allows the 5GS to determine the PDU Set information. The Protocol Description 102 includes information on the header, extension header (e.g., RTP / SRTP) and payload type (e.g., H.264) used by the service data flow. The SMF 346 forwards the Protocol Description 102 information together with the related PDRs. The UPF 348 uses the Protocol Description 102 to determine the PDU Set-level information (also referred to as “PDU Set information”), including the following (see e.g., [TS23501] § 5.37.5.2): PDU Set Sequence Number; Indication of End PDU of the PDU Set; PDU Sequence Number within a PDU Set; PDU Set Size in bytes; and PDU Set Importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow. Based on information received from the Policy Control Function (PCF) 356, the Session Management Function (SMF) 346 determines Packet Detection Rules (PDRs) 104 and a Forward Action Rule (FAR) 106 for a QoS Flow, and then forwards the PDRs 104 and FAR 106 to the User Plane Function (UPF) over the N4 reference point. The UPF 348 uses the PDRs 104 to perform detection of downstream data arriving on the N6 reference point. When a match is found, the UPF encapsulates the downlink data packet with a GTP- U header as indicated in the FAR 106. The UPF then forwards the GTP-U packet on the N3 reference point and includes the DSCP marking in the transport level header, again, as indicated in the FAR 106. Here, the Forward Action Rule (FAR) 106 information on N4 includes a Transport Level Marking List that contains a list of PDU Set Importance values, each of which is associated with a DSCP marking. After determining the PDU Set-level information of a data packet arriving on N6, the UPF 348 encapsulates the downlink data packet 108 with a transport header 110 (including the DSCP) a GTP-U header 112 as indicated in the FAR 106 and including the PDU Set-level information in the GTP-U header 112, and data 114. The UPF 348 then forwards the GTP-U downlink packet 108 on the N3 reference point and includes the DSCP marking in the transport level header 110 that corresponds to the derived PDU Set Importance value, as indicated in the Transport Level Marking List in the FAR 106. Attorney Docket No.: AF7269-PCT (31517-3527) The FAR 106 may be extended as indicated above by Table 1-2. In particular, the Transport Level Marking List may be added, and when the Transport Level Marking IE is present, the Transport Level Marking List IE is not present, or vice versa. As shown in FIG.1, the FAR 106 transport marking list may include an added PSI and DSCP. FIG. 2 shows an example of PDU sets and data bursts, in accordance with one or more embodiments of the present disclosure. PDU sets and Data Bursts enable the RAN (e.g., RAN 304 in Figure 3) to identify the PDUs which carry content that the application processes as a single unit (e.g., portion of an image, one or more video frames, one or more audio frames, and / or the like) and the duration of a data transmission, respectively. With PDU set integrated handling indication (PSIHI), the RAN and / or UE (e.g., UE 302 in Figure 3) knows whether all PDUs of a PDU set are needed for the usage of PDU set by application layer. This allows the RAN and / or UE to stop transmitting a PDU set as soon as one of the PDUs in the set is known to be lost (e.g., as other PDUs in that set may be useless). Additionally, each PDU set can be signaled with an importance value, which is referred to as PDU set importance (PSI). The PSI identifies the relative importance of a corresponding PDU set compared to the importance (PSI) of other PDU sets. The RAN and / or UE may use the PSI in case of congestion and / or other issues to discard PDU sets of lower importance (e.g., PDU sets associated with PSIs that are lower than a subject / ego PSI / PDU set). PDU Set QoS Parameters PDU set QoS parameters are used to support PDU set based QoS handling in the NG-RAN 304. At least one PDU Set QoS Parameter is sent to the NG-RAN 304 to enable PDU Set based QoS handling. The following PDU Set QoS Parameters are specified: (1) PDU Set Delay Budget (PSDB); (2) PDU Set Error Rate (PSER); (3) PDU Set Integrated Handling Information (PSIHI). The QoS Profile may include the PDU Set QoS Parameters described in this clause (see e.g., [TS23501] § 5.7.1.2). The PCF 356 determines the PDU Set QoS Parameters based on information provided by the AF 360 and / or local configuration. The PDU Set QoS parameters are sent to the SMF 346 as part of PCC rule. The SMF 346 sends them to NG-RAN 304 as part of the QoS Profile. If the NG-RAN 304 receives PDU Set QoS Parameters and supports them, it enables the PDU Set based QoS handling and applies PDU Set QoS Parameters as described herein and / or in [TS23501] § 5.7.7. PDU Set Delay Budget (PSDB) The PSDB defines an upper bound for the delay that a PDU Set may experience for the transfer between the UE 302 and the N6 termination point at the UPF 348, for example, the duration between the reception time of the first PDU (at the N6 termination point for DL or the UE 302 for UL) and the time when all PDUs of a PDU Set have been successfully received (at the UE 302 for DL or N6 termination point for UL). PSDB applies to the DL PDU Set received by the PDU session anchor (PSA) UPF 348 over the N6 interface, and to the UL PDU Set sent by the UE 302. To enable support for Attorney Docket No.: AF7269-PCT (31517-3527) PSDB, a maximum inter arrival time between the first received PDU and the last received PDU of a PDU Set may need to comply with an SLA, and this maximum inter arrival time may not exceed the PSDB. In some examples, a QoS flow is associated with only one PSDB, although in other examples, a QoS flow may be associated with more than one PSDB. The value of the PSDB is the same in UL and DL, or may be different for UL and DL. In some examples, the PSDB is an optional parameter that may be provided by the PCF 356. The provided PSDB can be used by the NG-RAN 304 to support the configuration of scheduling and link layer functions. When the PSDB is available, the PSDB supersedes the PDB for the given QoS flow. The AN PSDB is derived at NG-RAN 304 by subtracting CN PDB (as described in [TS23501] § 5.7.3.4) from the PSDB. PDU Set Error Rate (PSER) The PSER defines an upper bound for the rate of PDU Sets that have been processed by the sender of a link layer protocol (e.g., RLC in RAN of a 3GPP access) but that are not successfully delivered by the corresponding receiver to the upper layer (e.g., PDCP in RAN of a 3GPP access). Thus, the PSER defines an upper bound for a rate of non-congestion related PDU Set losses. The purpose of the PSER is to allow for appropriate link layer protocol configurations (e.g., RLC and HARQ in RAN of a 3GPP access). In some examples, a PDU Set is considered as successfully delivered only when all PDUs of a PDU Set are delivered successfully. The way in which the RAN 304 enforces the PSER is up to RAN implementation. In some examples, a QoS flow is associated with only one PSER, although in other examples, a QoS flow may be associated with more than one PSER. In some examples, the PSER is an optional parameter. If the PSER is available, the PSER supersedes the PER. The value of the PDU Set Error Rate is the same in UL and DL. PDU Set Integrated Handling Information (PSIHI) The PDU Set Integrated Handling Information (PSIHI) indicates whether all PDUs of the PDU set are needed for the usage of the PDU Set by the application layer in the receiver side. PSIHI is an optional parameter. PDU Set based Handling A PDU set comprises one or more PDUs carrying an application layer payload such as, for example, video frame(s), video slice(s), audio frame(s), XR data / traffic, and / or the like. The PDU set based QoS handling by the NG-RAN 304 is determined by PDU Set QoS parameters discussed herein and / or as specified in clause 5.7.7 of [TS23501], and PDU set information as provided by the PSA UPF 348 as discussed herein and / or as described in clause 5.37.5.2 of [TS23501]. In addition to the PDU related service information, the AF 360 may provide PDU Set related assistance information for dynamic PCC control. One or more of the following PDU Set related assistance information may be provided to the NEF 352 and / or PCF 356 using the AF session with required QoS procedures (see e.g., clauses 4.15.6.6 and 4.15.6.6a of [TS23501]): PDU Set QoS Attorney Docket No.: AF7269-PCT (31517-3527) parameters as described in clause 5.7.7 of [TS23501] and / or a protocol description. The protocol description indicates protocol and payload type used by a service data flow. AF 360 provided PDU Set QoS Parameters and Protocol Description may be used in determining PCC rules by the PCF 356 as defined in clause 6.1.3.27.4 of 3GPP TS 23.503 and the protocol description may be used for identifying the PDU Set information by the PSA UPF 348. When the PCF 356 determines that PDU Set based QoS Handling is to be performed for an application service flow, the PCF 356 generates a PCC rule containing the PDU Set QoS parameters (e.g., PSER, PSDB and PSIHI) and the SMF 346 determines a QoS Profile for the QoS flow. Alternatively, the SMF 346 may be configured to support PDU Set QoS without receiving PCC rules from a PCF 356. The PSA UPF 348 identifies PDUs that belong to PDU Sets. If the UPF 348 receives a PDU that does not belong to a PDU Set based on Protocol Description for PDU Set identification, then the UPF 348 still maps it to a PDU Set and determines the PDU Set Information as described in section 1.1.6 and / or in clause 5.37.5.2 of [TS23501]. In some examples, if the PSA UPF 348 receives a PDU that does not belong to a PDU Set, then it is assumed that the UPF 348 determines the PDU Set Importance (PSI) value based on pre-configuration. PDU Set Information and Identification To support PDU Set based QoS handling, the PSA UPF 348 identifies PDUs that belong to PDU Sets and determines the below PDU Set Information which it sends to the NG-RAN 304 in the GTP-U header. The PDU Set information is used by the NG-RAN 304 for PDU Set based QoS handling as described above. The PDU Set Information comprises: PDU Set sequence number; indication of End PDU of the PDU Set; PDU sequence number within a PDU Set; PDU Set size (e.g., in bytes); and / or PSI, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS flow. The NG-RAN 304 may use the Priority Level (see e.g., clause 5.7.3.3 of [TS23501]) across QoS flows and PSI within a QoS flow for PDU Set level packet discarding in presence of congestion. In addition to considering the PSI within a QoS flow, NG-RAN 304 could also consider the relative PSI across QoS flows of the same Priority Level when determining which PDU Set needs to be discarded, which is up to implementation and configuration of operator. In some examples, the PDU Set information can be different for different PDU Sets within a QoS flow. The SMF 346 instructs PSA UPF 348 to perform PDU Set marking and may provide the PSA UPF 348 the Protocol Description indicating the header, extension header (e.g., RTP / SRTP and / or the like) and payload type (e.g., H.264 and / or the like) used by the service data flow. The Protocol Description may be received in the PCC rule, based on information provided by the AF 360 or by PCF 356 local policies as described in clause 5.37.5.1 of [TS23501]. The PSA UPF 348 can identify the PDU Set Information using the Protocol Description and the received RTP / SRTP headers or using implementation specific means. The details of the RTP / SRTP Attorney Docket No.: AF7269-PCT (31517-3527) headers, header extensions and / or payloads used to identify PDU Set Information are defined in 3GPP TS 26.522. For each DL PDU received on N6 for which PDU Set based QoS handling is indicated from the SMF 346, the PSA UPF 348 applies the rules for PDU Set identification and provides PDU Set Information which is available to the RAN in the GTP-U header. Non-homogenous support of PDU set based handling in NG-RAN By sending at least one PDU Set QoS parameter to the NG-RAN 304, the SMF 346 requests the NG-RAN 304 to activate PDU Set QoS handling for a given QoS flow and the NG-RAN 304 provides the SMF 346 with an indication of whether the PDU Set QoS parameter is accepted or not. At NG-RAN 304 Xn handover and N2 handover, the target NG-RAN 304 provides to the SMF 346 with an indication of whether the target NG-RAN node 304 supports PDU Set based handling, as specified in 3GPP TS 38.413. Based on the NG-RAN 304 indications, the SMF 346 configures the PSA UPF 348 to activate / deactivate the PDU Set identification and marking. In the case where the PSA UPF 348 identifies and marks PDUs with PDU Set information in GTP-U header it starts doing so from a complete PDU Set. In the case of handover from a source NG- RAN node 314 not supporting PDU Set handling to a target NG-RAN node 304 supporting PDU Set handling, whether there is a reason for the target NG-RAN node to temporarily handle both unmarked PDUs and marked PDUs within the same QoS flow is FFS. XR Awareness Support / Visibility Information XR traffic comprises bursts of traffic that can carry one or more protocol data unit (PDU) sets (see e.g., FIG.2), where an individual PDU set includes one or more PDUs carrying the payload of at least one unit of information generated at the application level (e.g., one or more video frames, one or more video slices, one or more audio frames, and / or the like). XR awareness (also referred to as “XR- awareness” or the like) includes various aspects of XR traffic (in both UL and DL) characteristics, QoS metrics, and / or application layer attributes beneficial for a XR node (e.g., RAN node 304 and / or UE 302) to be aware of, which may be used for XR-specific traffic handling. In particular, XR awareness in RAN 304 is intended to make the RAN 304 aware of both the XR traffic characteristics and the requirements of XR applications (e.g., XR aware application (AA) 1020 and / or the like), as well as any changes to either of them in terms of, for example, the number and types of flows, minimum / maximum / average packet size for each of the flows, flow periodicity, jitter, and / or the association between internet protocol (IP) packets and application packets. In both UL and DL, XR awareness contributes to optimizations of radio resource for XR traffic. XR awareness information (also referred to as “XR awareness support information”, “XR visibility information”, “XR awareness indicator”, and / or the like”) represents whether a node (e.g., UE 302) has or does not have visibility to XR kind of information in UL and / or DL. Attorney Docket No.: AF7269-PCT (31517-3527) In some examples, the XR awareness in UL and / or DL could be defined as a Boolean indicator, such as true / false (e.g., 1 or 0) and / or using enumerated values (e.g., “XR-Awareness” or “Not-XR- Awareness”). Additionally or alternatively, the XR awareness information could include granularity of information as part of the same parameter (in which multiple values could be provided) and / or multiple independent parameters (in which each separate parameter could be conveyed at the same time with different kind of information). For example, the XR awareness information can include PDU set awareness information, PDU set importance (PSI) awareness information, and / or other awareness information / characteristics that may vary the support across different XR traffic. The PDU set awareness information can include information about individual PDU sets such as, for example, PDU set QoS parameters, PDU set delay budget (PSDB), PDU set error rate (PSER), PDU set integrated handling information (PSIHI), PDU set level packet handling / treatment requirements, PDU set jitter information, PDU set information as provided by a UPF 348 (see e.g., [TS23501] § 5.37.5.2), PSI information (e.g., which may or may not include the PSI awareness information), dependency within or among PDU sets (e.g., intra-PDU set dependencies and / or inter- PDU set dependency), size of individual PDU sets, PDU set sequence number(s) carried of constituent PDUs, boundary indicators (e.g., first and last PDUs of a PDU set), and / or the like. The PSI awareness information can include, for example, the importance or criticality of one or more PDUs within a PDU set, if other PDUs / PDU sets are dependent on a given critical PDU and / or PDU set, the number of level visible and relation / importance between them, and / or the like. The other information / characteristics related to XR awareness can also be considered such as, for example, jitter awareness, burst arrival awareness, periodicity awareness, traffic pattern information, statistics, QoS characteristics, application characteristics, associated PCC rules, burst periodicity, traffic periodicity and periodicity changes, number of temporal and spatial media layers and their (PDU set) periodicities and their (PDU set) dependencies, media detection rules that specify RTP header type (for media where RTP header is used), and / or the like. The XR related information may also be associated with a burst of data which may contain one or more PDUs or PDU sets Additionally or alternatively, the XR awareness support information can be associated with a QoS flow (e.g., using QFI), PDU session (e.g., using PDU session ID), radio bearer (RB), logical channel (LCH), logical channel group (LCG), and / or per UE (e.g., using some ID related to a UE 302). Additionally or alternatively, the XR awareness / visibility information may also be defined as a capability that can change over time in a semi-static or dynamic way. In these examples, the XR awareness / visibility information may be dependent and / or change on the different XR applications and / or the kind of XR stream starting / ongoing / ending. Attorney Docket No.: AF7269-PCT (31517-3527) Parameters for N4 Session Management General The N4 session management (SM) parameters are used by SMF 346 to control the functionality of the UPF 348 as well as to inform SMF 346 about events occurring at the UPF 348. The N4 SM procedures defined in [TS23502] § 4.4.1 use the relevant parameters in the same way for all N4 reference points: the N4 Session Establishment procedure as well as the N4 Session Modification procedure provide the control parameters to the UPF, the N4 Session Release procedure removes all control parameters related to an N4 session, and the N4 Session Level Reporting procedure informs the SMF about events related to the PDU Session that are detected by the UPF. The parameters over the N4 reference point provided from an SMF 346 to a UPF 348 comprises an N4 session ID and may also contain: Packet Detection Rules (PDR) that contain information to classify traffic (e.g., PDU(s) and / or PDU set(s)) arriving at the UPF 348; Forwarding Action Rules (FAR) that contain information on whether forwarding, dropping, and / or buffering is / are to be applied to traffic (or data flow) identified by one or more PDRs; Multi-Access Rules (MAR) that contain information on how to handle traffic steering, switching and splitting for a MA PDU Session; Usage Reporting Rules (URR) contains information that defines how traffic identified by PDR(s) shall be accounted as well as how a certain measurement is / are to be reported; QoS Enforcement Rules (QER), that contain information related to QoS enforcement of traffic identified by PDR(s); Session Reporting Rules (SRR) that contain information to request the UP function to detect and report events for a PDU session that are not related to specific PDRs of the PDU session or that are not related to traffic usage measurement; Trace Requirements; Port Management Information Container in 5GS; and / or Bridge / Router Information. The N4 Session ID is assigned by the SMF 346 and uniquely identifies an N4 session. In some implementations, the PDR, FAR, MAR, URR, QER, SRR, trace requirements, port management information, bridge / router information, and / or N4 session context are included in respective data containers, information elements (IE), data elements, and / or other data structures. According to various embodiments, any of the N4 SM parameters include the transport level markings list as discussed herein. In some examples, the transport level marking list contains a list of PDU set importance (PSI) values, and individual PSI values in the list of PSI values are associated with at least one DSCP marking / value. In some implementations, the transport level marking list and / or the list of PSI values (and / or DSCP markings / values) is / are included in a FAR and / or QER. In other implementations, the transport level marking list and / or the list of PSI values (and / or DSCP markings / values) is / are included in a MAR, URR, SRR, trace requirements container / IE and / or other data structure, port management information container / IE and / or other data structure, bridge / router information container / IE and / or other data structure, and / or an N4 session context container / IE and / or other data structure. If the UPF 348 indicated support of Trace, the SMF 346 may activate a trace session during a N4 Session Establishment or a N4 Session Modification procedure. In that case it provides Trace Attorney Docket No.: AF7269-PCT (31517-3527) Requirements to the UPF 348. The SMF 346 may deactivate an on-going trace session using a N4 Session Modification procedure. There shall be at most one trace session activated per N4 Session at a time. For the MA PDU Session, the SMF 346 may add an additional access tunnel information during an N4 Session Modification procedure by updating MAR with addition of an FAR ID which refers to an FAR containing the additional access tunnel information for the MA PDU session for traffic steering in the UPF 348. For the MA PDU Session, the SMF 346 may request Access Availability report per N4 Session, during N4 Session Establishment procedure or N4 Session Modification procedure. An N4 Session may be used to control both UPF 348 and NW-TT behaviour in the UPF 348. An N4 session support and enable exchange of bridge / router configuration between the SMF 346 and the UPF 348: information that the SMF 346 needs for bridge / router management (see e.g., [TS23501] § 5.8.5.9); information that 5GS transparently relays between the TSN AF or TSCTSF and the NW-TT: transparent Port Management Information Container along with the associated NW-TT port number; information that 5GS transparently relays between the TSN AF or TSCTSF and the NW-TT: transparent user plane node Management Information Container (see e.g., [TS23501] § 5.8.5.14). When a N4 Session related with bridge / router management is established, the UPF 348 allocates a dedicated port number for the device side of the PDU Session. The UPF 348 then provides to the SMF 346 following configuration parameters for the N4 Session: port number and / or user-plane node ID. To support TSN, the user-plane node ID is bridge ID. The User Plane Node ID / Bridge ID may be pre-configured in the UPF 348 based on deployment. After the N4 session has been established, the SMF 346 and UPF 348 may at any time exchange transparent user plane node and Port Management Information Container over a N4 session. N4 Session Context N4 Session Context is identified by an N4 Session ID. An N4 Session Context is generated by SMF 346 and UPF 348 respectively to store the parameters related to an N4 session, including the N4 session ID and following information (see TS 29.244

[0065] for an exhaustive list): (1) general session related parameters such as S-NSSAI, PDU Session Type, Trace Information, APN / DNN, ATSSS Control Information; (2) the PDRs, URRs, QERs, BAR(s), FARs, MARs used for this N4 session; and / or (3) parameters sent to support UPF 348 statistics. The UPF 348 may use parameters listed in (1) (e.g., S-NSSAI) and (2) (e.g., Network Instance in PDR / FAR(s)) for determining internal UPF 348 resources. Packet Detection Rule Table 1.3.3-1 describes the Packet Detection Rule (PDR) containing information required to classify a packet arriving at the UPF 348. A PDR is used to detect packets in a certain transmission direction (e.g., UL direction or DL direction). Attorney Docket No.: AF7269-PCT (31517-3527) Table 1.3.3-1: Attributes within Packet Detection Rule Attribute Description Comment N4 Session ID Identifies the N4 session associated to this PDR. e, ecessa y , u e o, Detection packet filter set, application identifier, Ethernet PDU Session Information. Information and QFI are used for NOTE 4. traffic detection. Source interface identifies the . interface for incoming packets where the PDR applies, e.g., from access side (e.g., up-link), from core side (e.g., down-link), . from SMF, from N6-LAN (e.g., the n DN), or from "5G VN internal" (e.g., local switch). Details like all the combination possibilities on N3, N9 interfaces are left for stage 3 decision. The FQDN or FQDN range only used for detection of plain DNS Query message (e.g., not subject to ciphering). The usage is described in 3GPP TS 23.548. Description . Attorney Docket No.: AF7269-PCT (31517-3527) Packet Packet Contains UE address indication or N19 / N6 replication replication indication. If the packet matches the packet replication skip information eg source address of

[0003] Attorney Docket No.: AF7269-PCT (31517-3527) NOTE 1: Needed, for example, if: UPF supports multiple DNN with overlapping IP addresses; UPF is connected to other UPF or AN node in different IP domains; UPF "local switch", N6-based forwarding and N19 forwarding is used t The following table describes the QoS Enforcement Rule (QER) that defines how a packet shall be treated in terms of bit rate limitation and packet marking for QoS purposes. In some examples, some or all PDRs that refer to the same QER share the same QoS resources (e.g., MFBR). Table 1.3.4-1: Attributes within QoS Enforcement Rule Attribute Description Comment Attorney Docket No.: AF7269-PCT (31517-3527) Maximum bitrate The uplink / downlink maximum bitrate to be As examples, this field may enforced for the packets. contain any one or more of: s et at at ) s et at ) et in Attorney Docket No.: AF7269-PCT (31517-3527) Paging Policy Indicator Indicates the PPI value the UPF is required to PPI applies only for DL traffic. insert in outgoing packets (see [TS23501] The UPF inserts the PPI in the § 5.4.3.2). outer header of outgoing PDU. he r ke PF nd U s 5. Table 1.3.5-1 describes the Usage Reporting Rule (URR) that defines how a packet shall be accounted as well as when and how to report the measurements. Table 1.3.5-1: Attributes within Usage Reporting Rule Attribute Description Comment ng Attorney Docket No.: AF7269-PCT (31517-3527) Reporting triggers One or multiple of the events can be activated for Applicable events include: the generation and reporting of the usage report. -Start / stop of traffic detection ce ter R nt d; d; d; L ed ss ic; IP as of g., ng ge ng to ck ed his of Attorney Docket No.: AF7269-PCT (31517-3527) Event based reporting Points to a locally configured policy which is identifies event(s) trigger for generating usage a his ng PP oS a of 2] or Table 1.3.6-1 describes the Forwarding Action Rule (FAR) that defines how a packet shall be buffered, dropped or forwarded, including packet encapsulation / decapsulation and forwarding destination. Table 1.3.6-1: Attributes within Forwarding Action Rule (FAR) Attribute Description Comment

[0004] Attorney Docket No.: AF7269-PCT (31517-3527) Action Identifies the action to apply to the packet Indicates whether the packet is to be forwarded, duplicated, tes a tes fer nd t a ed rst ee of be ] § for he he F, to cal N6 of N, ess I) for ed oS is fic Attorney Docket No.: AF7269-PCT (31517-3527) Send end marker packet(s) Instructs the UPF to construct end marker This parameter should be sent (NOTE 2) packet(s) and send them out as described in together with the "outer header ew o a ng be he he ns le ss he by 1] nd ng ter or is ed U nk Attorney Docket No.: AF7269-PCT (31517-3527) NOTE 1: Needed, for example, if: UPF supports multiple DNN with overlapping IP addresses; UPF is connected to other UPF or NG-RAN node in different IP domains; and / or UPF "local switch" and N19 forwarding is used for he N6 ed fic .4. ess he ild not ual ng The UPF 348 sends a Usage Report to inform the SMF 346 about the measurement of an active URR or about the detection of application traffic of an active Packet Detection Rule. For each URR, the Usage Report may be generated repeatedly, for example, as long as any one of the valid event triggers applies. A final Usage Report is sent for a URR when it is no longer active, e.g., either the URR is removed or all the references to this URR in any of the Packet Detection Rules belonging to the N4 session. The attributes of table 1.3.7-1 can be included.

[0005] Attorney Docket No.: AF7269-PCT (31517-3527) Table 1.3.7-1: Attributes within Usage Report Attribute Description Comment N4 Session ID Uniquely identifies a session. Identifies the N4 session ly er . is ng on ce ter R nt d; d; d; L of C L wn nd d. er . er . PP PP Attorney Docket No.: AF7269-PCT (31517-3527) Multi-Access Rule Table 1.3.8-1 describes the Multi-Access Rule (MAR) that includes the association to the two FARs for both 3GPP access and non-3GPP access in the case of supporting ATSSS. Table 1.3.8-1: Attributes within Multi-Access Rule Attribute Description Comment be he he all rt re ed Rs Attorney Docket No.: AF7269-PCT (31517-3527) (NOTE 1) Priority Values "Active or Standby" or "High or Low" for "Active or Standby" for the FAR "Active-Standby" steering NOTE 2 or ng to rts g., n- ad ng de de Table 1.3.9-1 describes the User plane node Information (UI) that includes the information required to configure a 5GS logical bridge / router for TSC or Deterministic Networking PDU Sessions. Table 1.3.9-1: User plane node Information Attribute Description Comment Table 1.3.10-1 describes the Session Reporting Rule (SRR) that defines the detection and reporting events that the UPF 348 is to report, that are not related to specific PDRs of the PDU Session, as follows: Per QoS Flow per UE QoS Monitoring Report, as specified in [TS23501] § 5.33.3.2; change Attorney Docket No.: AF7269-PCT (31517-3527) of 3GPP or non-3GPP access availability, for an MA PDU session; and / or Per QoS Flow N6 Traffic Parameter Measurement Report. Table 1.3.10-1: Attributes within Session Reporting Rule Attribute Description Comment g. PP PP PP ee nt re F). ed rol The UPF 348 sends the session report to inform the SMF 346 the detected events for a PDU Session that are related to an SRR. The UPF 348 may support notification to the AF 360 possibly via local NEF 352 as described in [TS23548] § 6.4. Attorney Docket No.: AF7269-PCT (31517-3527) Table 5.8.5.12-1: Attributes within Session Reporting Attribute Description Comment g. PP PP PP . p p . y p consistent with 3GPP technical specifications for LTE or 5G / NR systems. However, the example embodiments are not limited in this regard and the described examples may apply to other networks that benefit from the principles described herein, such as future 3GPP systems, or the like. The network 300 includes a UE 302, which is any mobile or non-mobile computing device designed to communicate with a RAN 304 via an over-the-air connection. The UE 302 is communicatively coupled with the RAN 304 by a Uu interface, which may be applicable to both LTE and NR systems. Examples of the UE 302 include, but are not limited to, a smartphone, tablet computer, wearable device (e.g., smart watch, fitness tracker, smart glasses, smart clothing / fabrics, head-mounted displays, smart shows, and / or the like), desktop computer, workstation, laptop computer, in-vehicle infotainment system, in-car entertainment system, instrument cluster, head-up display (HUD) device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic / engine control unit, electronic / engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, machine-to-machine (M2M), device-to-device (D2D), machine- type communication (MTC) device, Internet of Things (IoT) device, smart appliance, flying drone or unmanned aerial vehicle (UAV), terrestrial drone or autonomous vehicle, robot, electronic signage, single-board computer (SBC) (e.g., Raspberry Pi, Arduino, Intel Edison, and the like), plug computers, and / or any type of computing device such as any of those discussed herein. Attorney Docket No.: AF7269-PCT (31517-3527) The network 300 may include a set of UEs 302 coupled directly with one another via a D2D, ProSe, PC5, and / or sidelink (SL) interface, and / or any other suitable interface such as any of those discussed herein. In 3GPP systems, SL communication involves communication between two or more UEs 302 using 3GPP technology without traversing a network node. These UEs 302 may be M2M / D2D / MTC / IoT devices and / or vehicular systems that communicate using an SL interface, which includes, for example, one or more SL logical channels (e.g., Sidelink Broadcast Control Channel (SBCCH), Sidelink Control Channel (SCCH), and Sidelink Traffic Channel (STCH)); one or more SL transport channels (e.g., Sidelink Shared Channel (SL-SCH) and Sidelink Broadcast Channel (SL- BCH)); and one or more SL physical channels (e.g., Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Control Channel (PSCCH), Physical Sidelink Feedback Channel (PSFCH), Physical Sidelink Broadcast Channel (PSBCH), and / or the like). The UE 302 may perform blind decoding attempts of SL channels / links according to the various examples herein. In some examples, the UE 302 may additionally communicate with an AP 306 via an over-the- air (OTA) connection. The AP 306 manages a WLAN connection, which may serve to offload some / all network traffic from the RAN 304. The connection between the UE 302 and the AP 306 may be consistent with any IEEE 802.11 protocol. Additionally, the UE 302, RAN 304, and AP 306 may utilize cellular-WLAN aggregation / integration (e.g., LWA / LWIP). Cellular-WLAN aggregation may involve the UE 302 being configured by the RAN 304 to utilize both cellular radio resources and WLAN resources. The RAN 304 includes one or more network access nodes (NANs) 314 (also referred to as “access network nodes” or the like). The NG-RANs 304 terminate air-interface(s) for the UE 302 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and PHY / L1 protocols. In this manner, the gNB 314 enables data / voice connectivity between CN 320 and the UE 302. The NG-RANs 304 may be a macrocell base station or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells; or some combination thereof. In these implementations, an NG-RANs 304 may be referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRP, and the like. One example implementation is a “CU / DU split” architecture where the NG-RANs 304 are embodied as a gNB-Central Unit (CU) that is communicatively coupled with one or more gNB- Distributed Units (DUs), where each DU may be communicatively coupled with one or more Radio Units (RUs) (also referred to as RRHs, RRUs, or the like). In some implementations, the one or more RUs may be individual RSUs. In some implementations, the CU / DU split may include an ng-eNB-CU and one or more ng-eNB-DUs instead of, or in addition to, the gNB-CU and gNB-DUs, respectively. The NG-RANs 304 employed as the CU may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network including a virtual Base Band Unit (BBU) or BBU pool, cloud RAN (CRAN), Radio Equipment Controller (REC), Radio Cloud Center (RCC), centralized RAN (C-RAN), virtualized RAN (vRAN), and / or the like Attorney Docket No.: AF7269-PCT (31517-3527) (although these terms may refer to different implementation concepts). Any other type of architectures, arrangements, and / or configurations can be used. The set NG-RANs 304 are coupled with one another via respective X2 interfaces if the RAN 304 is an LTE RAN or Evolved Universal Terrestrial Radio Access Network (E-UTRAN) 310, or respective Xn interfaces if the RAN 304 is a NG-RAN 304. The X2 / Xn interfaces, which may be separated into control / user plane interfaces in some examples, may allow the ANs to communicate information related to handovers, data / context transfers, mobility, load management, interference coordination, and the like. The NANs of the RAN 304 may each manage one or more cells, cell groups, component carriers, and the like to provide the UE 302 with an air interface for network access. The UE 302 may be simultaneously connected with a set of cells provided by the same or different RANs 304 of the RAN 304. For example, the UE 302 and RAN 304 may use carrier aggregation to allow the UE 302 to connect with a set of component carriers, each corresponding to a Pcell or Scell. In dual connectivity scenarios, a first RAN 304 may be a master node that provides an MCG and a second RAN 304 may be secondary node that provides an SCG. The first / second NANs 314 may be any combination of eNB, gNB, ng- eNB, and the like. The NG-RAN 304 supports multi-radio DC (MR-DC) operation where a UE 302 is configured to utilize radio resources provided by two distinct schedulers, located in at least two different NG-RAN nodes 304 connected via a non-ideal backhaul, one NG-RAN node 304 providing NR access and the other NG-RAN node 304 providing either E-UTRA or NR access. One node acts as a master node and the other as a secondary node, and the master node and secondary node are connected via a network interface and at least the MN is connected to the core network (e.g., CN 340). In some implementations, the MN and / or the SN can be operated with shared spectrum channel access. Further details of MR-DC operation, including conditional PSCell addition (CPA) and conditional PSCell change (CPC), can be found in 3GPP TS 36.300 (“[TS36300]”), [TS38300], and 3GPP TS 37.340. The RAN 304 may provide the air interface over a licensed spectrum or an unlicensed spectrum. To operate in the unlicensed spectrum, the nodes may use LAA, eLAA, and / or feLAA mechanisms based on CA technology with PCells / Scells. Prior to accessing the unlicensed spectrum, the nodes may perform medium / carrier-sensing operations based on, for example, a listen-before-talk (LBT) protocol. Additionally or alternatively, individual UEs 302 provide radio information to one or more NG- RANs 304 and / or one or more edge compute nodes (e.g., edge servers / hosts, and the like). The radio information may be in the form of one or more measurement reports, and / or may include, for example, signal strength measurements, signal quality measurements, and / or the like. In examples where the RAN 304 is an E-UTRAN 310 with one or more eNBs 312, the E- UTRAN 310 provides an LTE air interface (Uu) with the parameters and characteristics at least as discussed in 3GPP TS 36.300 (“[TS36300]”). In examples where the RAN 304 is an next generation (NG)-RAN 314 with a set of gNBs 316. Each gNB 316 connects with 5G-enabled UEs 302 using a 5G- NR air interface (which may also be referred to as a Uu interface) with parameters and characteristics Attorney Docket No.: AF7269-PCT (31517-3527) as discussed in [TS38300], among many other 3GPP standards. Where the NG-RAN 304 includes a set of ng-eNBs 318, the one or more ng-eNBs 318 connect with a UE 302 via the 5G Uu and / or LTE Uu interface. The gNBs 316 and the ng-eNBs 318 connect with the 5GC 340 through respective NG interfaces, which include an N2 interface, an N3 interface, and / or other interfaces. The gNB 316 and the ng-eNB 318 are connected with each other over an Xn interface. Additionally, individual gNBs 316 are connected to one another via respective Xn interfaces, and individual ng-eNBs 318 are connected to one another via respective Xn interfaces. In some examples, the NG interface may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the nodes of the NG-RAN 304 and a UPF 348 (e.g., N3 interface), and an NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN 304 and an AMF 344 (e.g., N2 interface). The NG-RAN 304 may provide a 5G-NR air interface (which may also be referred to as a Uu interface) with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s- OFDM for UL; polar, repetition, simplex, and Reed-Muller codes for control and LDPC for data. The 5G-NR air interface may rely on CSI-RS, PDSCH / PDCCH DMRS similar to the LTE air interface. The 5G-NR air interface may not use a CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signal for time tracking. The 5G-NR air interface may operating on FR1 bands that include sub-6 GHz bands or FR2 bands that include bands from 24.25 GHz to 52.6 GHz. The 5G-NR air interface may include an SSB that is an area of a downlink resource grid that includes PSS / SSS / PBCH. The 5G-NR air interface may utilize BWPs for various purposes. For example, BWP can be used for dynamic adaptation of the SCS. For example, the UE 302 can be configured with multiple BWPs where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 302, the SCS of the transmission is changed as well. Another use case example of BWP is related to power saving. In particular, multiple BWPs can be configured for the UE 302 with different amount of frequency resources (e.g., PRBs) to support data transmission under different traffic loading scenarios. A BWP containing a smaller number of PRBs can be used for data transmission with small traffic load while allowing power saving at the UE 302 and in some cases at the gNB 316. A BWP containing a larger number of PRBs can be used for scenarios with higher traffic load. In some implementations, individual gNBs 316 can include a gNB-CU and a set of gNB-DUs. Additionally or alternatively, gNBs 316 can include one or more RUs. In these implementations, the gNB-CU may be connected to each gNB-DU via respective F1 interfaces. In case of network sharing with multiple cell ID broadcast(s), each cell identity associated with a subset of PLMNs corresponds to a gNB-DU and the gNB-CU it is connected to, share the same physical layer cell resources. For resiliency, a gNB-DU may be connected to multiple gNB-CUs by appropriate implementation. Additionally, a gNB-CU can be separated into gNB-CU control plane (gNB-CU-CP) and gNB-CU user plane (gNB-CU-UP) functions. The gNB-CU-CP is connected to a gNB-DU through an F1 control plane interface (F1-C), the gNB-CU-UP is connected to the gNB-DU through an F1 user plane interface Attorney Docket No.: AF7269-PCT (31517-3527) (F1-U), and the gNB-CU-UP is connected to the gNB-CU-CP through an E1 interface. In some implementations, one gNB-DU is connected to only one gNB-CU-CP, and one gNB-CU-UP is connected to only one gNB-CU-CP. For resiliency, a gNB-DU and / or a gNB-CU-UP may be connected to multiple gNB-CU-CPs by appropriate implementation. One gNB-DU can be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP, and one gNB-CU-UP can be connected to multiple DUs under the control of the same gNB-CU-CP. Data forwarding between gNB-CU-UPs during intra-gNB-CU-CP handover within a gNB may be supported by Xn-U. Similarly, individual ng-eNBs 318 can include an ng-eNB-CU and a set of ng-eNB-DUs. In these implementations, the ng-eNB-CU and each ng-eNB-DU are connected to one another via respective W1 interface. An ng-eNB can include an ng-eNB-CU-CP, one or more ng-eNB-CU-UP(s), and one or more ng-eNB-DU(s). An ng-eNB-CU-CP and an ng-eNB-CU-UP is connected via the E1 interface. An ng-eNB-DU is connected to an ng-eNB-CU-CP via the W1-C interface, and to an ng- eNB-CU-UP via the W1-U interface. The general principle described herein w.r.t gNB aspects also applies to ng-eNB aspects and corresponding E1 and W1 interfaces, if not explicitly specified otherwise. The node hosting user plane part of the PDCP protocol layer (e.g., gNB-CU, gNB-CU-UP, and for EN-DC, MeNB or SgNB depending on the bearer split) performs user inactivity monitoring and further informs its inactivity or (re)activation to the node having control plane connection towards the core network (e.g., over E1, X2, or the like). The node hosting the RLC protocol layer (e.g., gNB-DU) may perform user inactivity monitoring and further inform its inactivity or (re)activation to the node hosting the control plane (e.g., gNB-CU or gNB-CU-CP). In these implementations, the NG-RAN 304, is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN 304 architecture (e.g., the NG-RAN logical nodes and interfaces between them) is part of the RNL. For each NG-RAN interface (e.g., NG, Xn, F1, and the like) the related TNL protocol and the functionality are specified. The TNL provides services for user plane transport and / or signalling transport. In NG-Flex configurations, each NG-RAN node is connected to all AMFs 344 of AMF sets within an AMF region supporting at least one slice also supported by the NG-RAN node. The AMF Set and the AMF Region are defined in [TS23501]. The RAN 304 is communicatively coupled to CN 320 that includes network elements and / or network functions (NFs) to provide various functions to support data and telecommunications services to customers / subscribers (e.g., UE 302). The components of the CN 320 may be implemented in one physical node or separate physical nodes. In some examples, NFV may be utilized to virtualize any or all of the functions provided by the network elements of the CN 320 onto physical compute / storage resources in servers, switches, and the like. A logical instantiation of the CN 320 may be referred to as a network slice, and a logical instantiation of a portion of the CN 320 may be referred to as a network sub-slice. In the example of Figure 3, the CN 340 is a 5GC 340 including an Authentication Server Function (AUSF) 342, Access and Mobility Management Function (AMF) 344, Session Management Attorney Docket No.: AF7269-PCT (31517-3527) Function (SMF) 346, User Plane Function (UPF) 348, Network Slice Selection Function (NSSF) 350, Network Exposure Function (NEF) 352, Network Repository Function (NRF) 354, Policy Control Function (PCF) 356, Unified Data Management (UDM) 358, Unified Data Repository (UDR), Application Function (AF) 360, and Network Data Analytics Function (NWDAF) 362 coupled with one another over various interfaces as shown. The NFs in the 5GC 340 are briefly introduced as follows. The NWDAF 362 includes one or more of the following functionalities: support data collection from NFs and AFs 360; support data collection from OAM; NWDAF service registration and metadata exposure to NFs and AFs 360; support analytics information provisioning to NFs and AFs 360; support machine learning (ML) model training and provisioning to NWDAF(s) 362 (e.g., those containing analytics logical function). Some or all of the NWDAF functionalities can be supported in a single instance of an NWDAF 362. The NWDAF 362 also includes an analytics reporting capability, which comprises means that allow discovery of the type of analytics that can be consumed by an external party and / or the request for consumption of analytics information generated by the NWDAF 362. The NWDAF 362 interacts with different entities for different purposes, such as one or more of the following: data collection based on subscription to events provided by AMF 344, SMF 346, PCF 356, UDM 358, NSACF, AF 360 (directly or via NEF 352) and OAM (not shown); analytics and data collection using the Data Collection Coordination Function (DCCF); retrieval of information from data repositories (e.g., UDR via UDM 358 for subscriber-related information); data collection of location information from LCS system; storage and retrieval of information from an Analytics Data Repository Function (ADRF); analytics and data collection from a Messaging Framework Adaptor Function (MFAF); retrieval of information about NFs (e.g., from NRF 354 for NF-related information); on- demand provision of analytics to consumers, as specified in clause 6 of [TS23288]; and / or provision of bulked data related to analytics ID(s). NWDAF discovery and selection procedures are discussed in clause 6.3.13 in [TS23501] and clause 5.2 of [TS23288]. A single instance or multiple instances of NWDAF 362 may be deployed in a PLMN. If multiple NWDAF 362 instances are deployed, the architecture supports deploying the NWDAF 362 as a central NF, as a collection of distributed NFs, or as a combination of both. If multiple NWDAF 362 instances are deployed, an NWDAF 362 can act as an aggregate point (e.g., aggregator NWDAF 362) and collect analytics information from other NWDAFs 362, which may have different serving areas, to produce the aggregated analytics (e.g., per analytics ID), possibly with analytics generated by itself. When multiple NWDAFs 362 exist, not all of them need to be able to provide the same type of analytics results. For example, some of the NWDAFs 362 can be specialized in providing certain types of analytics. An analytics ID information element is used to identify the type of supported analytics that NWDAF 362 can generate. In some implementations, NWDAF 362 instance(s) can be collocated with a 5GS NF. Additional aspects of NWDAF 362 functionality are defined in 3GPP TS 23.288 (“[TS23288]”). Attorney Docket No.: AF7269-PCT (31517-3527) Different NWDAF 362 instances may be present in the 5GC 340, with possible specializations per type of analytics. The capabilities of an NWDAF 362 instance are described in the NWDAF profile stored in the NRF 354. The NWDAF architecture allows for arranging multiple NWDAF 362 instances in a hierarchy / tree with a flexible number of layers / branches. The number and organisation of the hierarchy layers, as well as the capabilities of each NWDAF 362 instance remain deployment choices and may vary depending on implementation and / or use case. In a hierarchical deployment, NWDAFs 362 may provide data collection exposure capability for generating analytics based on the data collected by other NWDAFs 362, when DCCFs 363 and / or MFAFs 365 are not present in the network. The AUSF 342 stores data for authentication of UE 302 and handle authentication-related functionality. The AUSF 342 may facilitate a common authentication framework for various access types. The AMF 344 allows other functions of the 5GC 340 to communicate with the UE 302 and the RAN 304 and to subscribe to notifications about mobility events w.r.t the UE 302. The AMF 344 is also responsible for registration management (e.g., for registering UE 302), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 344 provides transport for SM messages between the UE 302 and the SMF 346, and acts as a transparent proxy for routing SM messages. AMF 344 also provides transport for SMS messages between UE 302 and an SMSF. AMF 344 interacts with the AUSF 342 and the UE 302 to perform various security anchor and context management functions. Furthermore, AMF 344 is a termination point of a RAN-CP interface, which includes the N2 reference point between the RAN 304 and the AMF 344. The AMF 344 is also a termination point of NAS (N1) signaling, and performs NAS ciphering and integrity protection. The AMF 344 also supports NAS signaling with the UE 302 over an N3IWF interface. The N3IWF provides access to untrusted entities. N3IWF may be a termination point for the N2 interface between the (R)AN 304 and the AMF 344 for the control plane, and may be a termination point for the N3 reference point between the (R)AN 304 and the 348 for the user plane. As such, the AMF 344 handles N2 signaling from the SMF 346 and the AMF 344 for PDU sessions and QoS, encapsulate / de- encapsulate packets for IPSec and N3 tunneling, marks N3 user-plane packets in the UL, and enforces QoS corresponding to N3 packet marking taking into account QoS requirements associated with such marking received over N2. N3IWF may also relay UL and DL control-plane NAS signaling between the UE 302 and AMF 344 via an N1 reference point between the UE 302and the AMF 344, and relay UL and DL user-plane packets between the UE 302 and UPF 348. The N3IWF also provides mechanisms for IPsec tunnel establishment with the UE 302. The AMF 344 may exhibit an Namf service-based interface, and may be a termination point for an N14 reference point between two AMFs 344 and an N17 reference point between the AMF 344 and a 5G-EIR (not shown by Figure 3). In addition to the functionality of the AMF 344 described herein, the AMF 344 may provide support for Network Slice restriction and Network Slice instance restriction based on NWDAF analytics. Attorney Docket No.: AF7269-PCT (31517-3527) The SMF 346 is responsible for SM (e.g., session establishment, tunnel management between UPF 348 and gNB 314); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at UPF 348 to route traffic to proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement, charging, and QoS; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; DL data notification; initiating AN specific SM information, sent via AMF 344 over N2 to gNB 314; and determining SSC mode of a session. SM refers to management of a PDU session, and a PDU session or “session” refers to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 302 and the DN 336. The SMF 346 may also include the following functionalities to support edge computing enhancements (see e.g., [TS23548]): selection of EASDF 361 and provision of its address to the UE as the DNS server for the PDU session; usage of EASDF 361 services as defined in [TS23548]; and for supporting the application layer architecture defined in [TS23558], provision and updates of ECS address configuration information to the UE. Discovery and selection procedures for EASDFs 361 is discussed in [TS23501] § 6.3.23. The UPF 348 acts as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to data network 336, and a branching point to support multi-homed PDU session. The UPF 348 also performs packet routing and forwarding, packet inspection, enforces user plane part of policy rules, lawfully intercept packets (UP collection), performs traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UL / DL rate enforcement), performs UL traffic verification (e.g., SDF-to-QoS flow mapping), transport level packet marking in the UL and DL, and performs DL packet buffering and DL data notification triggering. UPF 348 may include an UL classifier to support routing traffic flows to a data network. For DL traffic, the UPF 348 maps user plane traffic to QoS flows based on the PDRs; performs Session-AMBR enforcement as specified in [TS23501] § 5.7.1.8 and performs counting of packets for charging. The UPF 348 transmits the PDUs of the PDU Session in a single tunnel between 5GC and (R)AN, and the UPF 348 includes the QFI in the encapsulation header. In addition, the UPF 348 may include an indication for reflective QoS activation in the encapsulation header. The UPF 348 performs transport level packet marking in DL on a per QoS Flow basis. The UPF 348 uses the transport level packet marking value provided by the SMF 346 (as described in [TS23501] § 5.8.2.7). The UPF 348 enforces UL and DL Session-AMBR (see e.g., [TS23501] § 5.7.2.6), if the UPF 348 receives the Session-AMBR values from the SMF 346 as described in [TS23501] §§ 5.8.2.7 and 5.8.5.4. With respect to (w.r.t) PDU Session and QoS Flow Policing, Allocation and Retention Priority (ARP) is used for admission control (e.g., retention and pre-emption of the new QoS Flow). The value of ARP is not required to be provided to the UPF 348. For every QoS Flow, the SMF 346 determines the transport level packet marking value (e.g., the DSCP in the outer IP header) based on the 5QI, the Priority Level (if explicitly signaled) and optionally, the ARP priority level and provide the transport Attorney Docket No.: AF7269-PCT (31517-3527) level packet marking value to the UPF 348. The SMF 346 provides the Session-AMBR values of the PDU Session to the UPF 348 so that the UPF 348 can enforce the Session-AMBR of the PDU Session across all Non-GBR QoS Flows of the PDU Session. The SMF 346 provides the GFBR and MFBR value for each GBR QoS Flow of the PDU Session to the UPF 348. SMF 346 may also provide the averaging window to the UPF 348, if averaging window is not configured at the UPF 348 or if it is different from the default value configured at the UPF 348. The SMF 346 may decide to activate ECN marking for L4S by PSA UPF for the QoS Flow (see e.g., [TS23501] § 5.37). In this case, the SMF 346 sends an ECN marking for L4S indicator to UPF 348. With respect to traffic detection, a detection process at the UPF 348 identifies the packets belonging to a session and / or a service data flow. The SMF 346 is responsible for instructing the UP function (e.g., UPF 348) about how to detect user data traffic belonging to a Packet Detection Rule (PDR). The other parameters provided within a PDR describe how the UP function (e.g., UPF 348) is to treat a packet that matches the detection information. The SMF 346 controls the traffic detection at the UP function (e.g., UPF 348) by providing traffic detection information (also referred to as “packet detection information” and / or “detection information”) for every PDR. For IPv4 or IPv6 or IPv4v6 PDU session type, the detection information is a combination of CN tunnel info; network instance; QFI; IP Packet Filter Set (see e.g., [TS23501] § 5.7.6.2); application identifier; and / or FQDN filter for DNS Query message. The application identifier is an index to a set of application detection rules configured in UPF 348. For an Ethernet PDU session type, the detection information is a combination of: CN tunnel info; network instance; QFI; and / or Ethernet Packet Filter Set (see e.g., [TS23501] § 5.7.6.3). In some examples, for an unstructured PDU Session Type, the UPF 348 does not perform-QoS flow level traffic detection for QoS enforcement. The traffic detection information sent by the SMF 346 to the UPF 348 for a PDU Session may be associated with a network instance for detection and routing of traffic over the N6 interface. In the case of IP PDU session type, one or more network instance can, for example, be used by the UPF 348 for traffic detection and routing in the case of different IP domains and / or overlapping IP addresses. In the case of Ethernet PDU session type, different network instances can, for example, be configured in the UPF 348 with different ways to handle the association between N6 and the PDU sessions. Based on SMF instructions, the UPF 348 may identify the PDU sets, according to the Protocol Description in the PDR, to derive the PDU set information for DL traffic (and / or data flows) and send it to RAN 304 via DL GTP-U header of each PDU identified as belonging to a PDU set. The PDU set information is described herein and / or in [TS23501] § 5.37.5. The PDU set information can be done by UPF implementation and / or by detecting RTP / SRTP header or payload. The details of the RTP / SRTP headers, header extensions and / or payloads used to identify PDU Sets are defined in 3GPP TS 26.522. The NSSF 350 selects a set of network slice instances serving the UE 302. The NSSF 350 also determines allowed NSSAI and the mapping to the subscribed S-NSSAIs, if needed. The NSSF 350 also determines an AMF set to be used to serve the UE 302, or a list of candidate AMFs 344 based on Attorney Docket No.: AF7269-PCT (31517-3527) a suitable configuration and possibly by querying the NRF 354. The selection of a set of network slice instances for the UE 302 may be triggered by the AMF 344 with which the UE 302 is registered by interacting with the NSSF 350; this may lead to a change of AMF 344. The NSSF 350 interacts with the AMF 344 via an N22 reference point; and may communicate with another NSSF in a visited network via an N31 reference point (not shown). The NEF 352 securely exposes services and capabilities provided by 3GPP NFs for third party, internal exposure / re-exposure, AFs 360, edge computing networks / frameworks, and the like. In such examples, the NEF 352 may authenticate, authorize, or throttle the AFs 360. The NEF 352 stores / retrieves information as structured data using the Nudr interface to a Unified Data Repository (UDR). The NEF 352 also translates information exchanged with the AF 360 and information exchanged with internal NFs. For example, the NEF 352 may translate between an AF-Service- Identifier and an internal 5GC information, such as DNN, S-NSSAI, as described in clause 5.6.7 of [TS23501]. In particular, the NEF 352 handles masking of network and user sensitive information to external AF's 360 according to the network policy. The NEF 352 also receives information from other NFs based on exposed capabilities of other NFs. This information may be stored at the NEF 352 as structured data, or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 352 to other NFs and AFs, or used for other purposes such as analytics. For example, NWDAF analytics may be securely exposed by the NEF 352 for external party, as specified in [TS23288]. Furthermore, data provided by an external party may be collected by the NWDAF 362 via the NEF 352 for analytics generation purpose. The NEF 352 handles and forwards requests and notifications between the NWDAF 362 and AF(s) 360, as specified in [TS23288]. In some examples, the NEF 352 can provide an interface to edge compute nodes 338, which can be used to process wireless connections with the RAN 304, task / workload offloading, and / or to provide any other suitable services, such as any of those discussed herein. The NRF 354 supports service discovery functions, receives NF discovery requests from NF instances, and provides information of the discovered NF instances to the requesting NF instances. The NRF 354 also maintains NF profiles of available NF instances and their supported services. The PCF 356 provides policy rules to control plane functions to enforce them, and may also support unified policy framework to govern network behavior. The PCF 356 may also implement a front end to access subscription information relevant for policy decisions in a UDR 359 of the UDM 358. In addition to communicating with functions over reference points as shown, the PCF 356 exhibit an Npcf service-based interface. The UDM 358 handles subscription-related information to support the network entities’ handling of communication sessions, and stores subscription data of UE 302. For example, subscription data may be communicated via an N8 reference point between the UDM 358 and the AMF 344. The UDM 358 may include two parts, an application front end and a UDR. The UDR may store subscription data and policy data for the UDM 358 and the PCF 356, and / or structured data for exposure and Attorney Docket No.: AF7269-PCT (31517-3527) application data (including PFDs for application detection, application request information for multiple UEs 302) for the NEF 352. The Nudr service-based interface may be exhibited by the UDR to allow the UDM 358, PCF 356, and NEF 352 to access a particular set of the stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notification of relevant data changes in the UDR. The UDM 358 may include a UDM-FE, which is in charge of processing credentials, location management, subscription management and so on. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification handling, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs over reference points as shown, the UDM 358 may exhibit the Nudm service-based interface. Edge Application Server Discovery Function (EASDF) 361 exhibits an Neasdf service-based interface, and is connected to the SMF 346 via an N88 interface. One or multiple EASDF instances may be deployed within a PLMN, and interactions between 5GC NF(s) and the EASDF 361 take place within a PLMN. The EASDF 361 includes one or more of the following functionalities: registering to NRF 354 for EASDF 361 discovery and selection; handling the DNS messages according to the instruction from the SMF 346; and / or terminating DNS security, if used. Handling the DNS messages according to the instruction from the SMF 346 includes one or more of the following functionalities: receiving DNS message handling rules and / or BaselineDNSPattern from the SMF 346; exchanging DNS messages from / with the UE 302; forwarding DNS messages to C-DNS or L-DNS for DNS query; adding EDNS client subnet (ECS) option into DNS query for an FQDN; reporting to the SMF 346 the information related to the received DNS messages; and / or buffering / discarding DNS messages from the UE 302 or DNS Server. The EASDF has direct user plane connectivity (e.g., without any NAT) with the PSA UPF over N6 for the transmission of DNS signaling exchanged with the UE. The deployment of a NAT between EASDF 361 and PSA UPF 348 may or may not be supported. Additional aspects of the EASDF 361 are discussed in [TS23548]. AF 360 provides application influence on traffic routing, provide access to NEF 352, and interact with the policy framework for policy control. The AF 360 may influence UPF 348 (re)selection and traffic routing. Based on operator deployment, when AF 360 is considered to be a trusted entity, the network operator may permit AF 360 to interact directly with relevant NFs. In some implementations, the AF 360 is used for edge computing implementations. An NF that needs to collect data from an AF 360 may subscribe / unsubscribe to notifications regarding data collected from an AF 360, either directly from the AF 360 or via NEF 352. The data collected from an AF 360 is used as input for analytics by the NWDAF 362. The details for the data collected from an AF 360 as well as interactions between NEF 352, AF 360 and NWDAF 362 are described in [TS23288]. The 5GC 340 may enable edge computing by selecting operator / 3rd party services to be geographically close to a point that the UE 302 is attached to the network. This may reduce latency and Attorney Docket No.: AF7269-PCT (31517-3527) load on the network. In edge computing implementations, the 5GC 340 may select a UPF 348 close to the UE 302 and execute traffic steering from the UPF 348 to DN 336 via the N6 interface. This may be based on the UE subscription data, UE location, and information provided by the AF 360, which allows the AF 360 to influence UPF (re)selection and traffic routing. The data network (DN) 336 may represent various network operator services, Internet access, or third party services that may be provided by one or more servers including, for example, application (app) / content server 338. The DN 336 may be an operator external public, a private PDN, or an intra- operator packet data network, for example, for provision of IMS services. In this example, the app server 338 can be coupled to an IMS via an S-CSCF or the I-CSCF. In some implementations, the DN 336 may represent one or more local area DNs (LADNs), which are DNs 336 (or DN names (DNNs)) that is / are accessible by a UE 302 in one or more specific areas. Outside of these specific areas, the UE 302 is not able to access the LADN / DN 336. Additionally or alternatively, the DN 336 may be an edge DN 336, which is a (local) DN that supports the architecture for enabling edge applications. In these examples, the app server 338 may represent the physical hardware systems / devices providing app server functionality and / or the application software resident in the cloud or at an edge compute node that performs server function(s). In some examples, the app / content server 338 provides an edge hosting environment that provides support required for Edge Application Server's execution. In some examples, the 5GS can use one or more edge compute nodes to provide an interface and offload processing of wireless communication traffic. In these examples, the edge compute nodes may be included in, or co-located with one or more RANs 304 or RAN nodes 304. For example, the edge compute nodes can provide a connection between the RAN 304 and UPF 348 in the 5GC 340. The edge compute nodes can use one or more NFV instances instantiated on virtualization infrastructure within the edge compute nodes to process wireless connections to and from the RAN 304 and UPF 348. In some implementations, the edge compute nodes provide a distributed computing environment for application and service hosting, and also provide storage and processing resources so that data and / or content can be processed in close proximity to subscribers (e.g., users of UEs 302) for faster response times. The edge compute nodes also support multitenancy run-time and hosting environment(s) for applications, including virtual appliance applications that may be delivered as packaged virtual machine (VM) images, middleware application and infrastructure services, content delivery services including content caching, mobile big data analytics, and computational offloading, among others. Computational offloading involves offloading computational tasks, workloads, applications, and / or services to the edge compute nodes from the UEs 302, CN 340, DN 336, and / or server(s) 338, or vice versa. For example, a device application or client application operating in a UE 302 may offload application tasks or workloads to one or more edge compute nodes. In another example, an edge compute node may offload application tasks or workloads to a set of UEs 302 (e.g., for distributed machine learning computation and / or the like). Attorney Docket No.: AF7269-PCT (31517-3527) The edge compute nodes may include or be part of an edge system that employs one or more edge computing technologies (ECTs) (also referred to as an “edge computing framework” or the like). The edge compute nodes may also be referred to as “edge hosts” or “edge servers.” The edge system includes a collection of edge servers and edge management systems (not shown) necessary to run edge computing applications within an operator network or a subset of an operator network. The edge servers are physical computer systems that may include an edge platform and / or virtualization infrastructure, and provide compute, storage, and network resources to edge computing applications. Each of the edge servers are disposed at an edge of a corresponding access network, and are arranged to provide computing resources and / or various services (e.g., computational task and / or workload offloading, cloud-computing capabilities, IT services, and other like resources and / or services as discussed herein) in relatively close proximity to UEs 302. The VI of the edge compute nodes provide virtualized environments and virtualized resources for the edge hosts, and the edge computing applications may run as VMs and / or application containers on top of the VI. The interfaces of the 5GC 340 include reference points and service-based interfaces. A reference point, at least in some examples, is a point at the conjunction of two non-overlapping functional groups, elements, or entities. The reference points in the 5GC 340 include: N1 (between the UE 302 and the AMF 344), N2 (between RAN 304 and AMF 344), N3 (between RAN 304 and UPF 348), N4 (between the SMF 346 and UPF 348), N5 (between PCF 356 and AF 360), N6 (between UPF 348 and DN 336), N7 (between SMF 346 and PCF 356), N8 (between UDM 358 and AMF 344), N9 (between two UPFs 348), N10 (between the UDM 358 and the SMF 346), N11 (between the AMF 344 and the SMF 346), N12 (between AUSF 342 and AMF 344), N13 (between AUSF 342 and UDM 358), N14 (between two AMFs 344; not shown), N15 (between PCF 356 and AMF 344 in case of a non- roaming scenario, or between the PCF 356 in a visited network and AMF 344 in case of a roaming scenario), N16 (between two SMFs 346; not shown), and N22 (between AMF 344 and NSSF 350). Other reference points not shown in Figure 3 can also be used, such as any of those discussed in [TS23501]. FIG.4 illustrates a wireless network 400 that includes a UE 402 communicatively coupled with an AN 404 via connection 406. The UE 402 and AN 404 may be the same or similar as the UE 1802 and AN 1804, respectively. The connection 406 is an air interface to enable communicative coupling, which is consistent with cellular communications protocols, such as LTE, a 5G / NR operating at mmWave or sub-6GHz frequencies, and / or according to any other RAT discussed herein. The UE 402 includes a host platform 408 coupled with a modem platform 410. The host platform 408 includes application processing circuitry 412, which is coupled with protocol processing circuitry 414 of the modem platform 410. The application processing circuitry 412 runs various applications for the UE 402 that source / sink application data. The application processing circuitry 412 implements one or more layer operations to transmit / receive application data to / from a data network. These layer operations include transport (e.g., UDP, TCP, QUIC, and / or the like), network (e.g., IP, Attorney Docket No.: AF7269-PCT (31517-3527) and / or the like), and / or operations of other layers. The protocol processing circuitry 414 implements one or more of layer operations to facilitate transmission or reception of data over the connection 406. The layer operations implemented by the protocol processing circuitry 414 includes, for example, MAC, RLC, PDCP, RRC and NAS operations. The modem platform 410 includes digital baseband circuitry 416 that implements one or more layer operations that are “below” layer operations performed by the protocol processing circuitry 414 in a network protocol stack. These operations includes, for example, PHY operations including one or more of HARQ-ACK functions, scrambling / descrambling, encoding / decoding, layer mapping / de- mapping, modulation symbol mapping, received symbol / bit metric determination, multi-antenna port precoding / decoding, which includes one or more of space-time, space-frequency or spatial coding, reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, control channel signal blind decoding, and other related functions. The modem platform 410 includes transmit (Tx) circuitry 418, receive (Rx) circuitry 420, radiofrequency (RF) circuitry 422, and an RF front end (RFFE) 424, which includes or connects to one or more antenna panels 426. The Tx circuitry 418 includes a digital-to-analog converter, mixer, intermediate frequency (IF) components, and / or the like; the Rx circuitry 420 includes an analog-to- digital converter, mixer, IF components, and / or the like; the RF circuitry 422 includes a low-noise amplifier, a power amplifier, power tracking components, and / or the like; the RFFE 424 includes filters (e.g., surface / bulk acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phase-array antenna components), and / or the like; and the antenna panels 426 (also referred to as “Tx / Rx components”) include one or more antenna elements, such as planar inverted-F antennas (PIFAs), monopole antennas, dipole antennas, loop antennas, patch antennas, Yagi antennas, parabolic dish antennas, omni-directional antennas, and / or the like. The selection and arrangement of the components of the Tx circuitry 418, Rx circuitry 420, RF circuitry 422, RFFE 424, and antenna panels 426 may be specific to details of a specific implementation such as, for example, whether communication is TDM or FDM, in mmWave or sub-6 gHz frequencies, and / or the like. The Tx / Rx components may be arranged in multiple parallel Tx / Rx chains, may be disposed in the same or different chips / modules, and / or the like. The protocol processing circuitry 414 includes one or more instances of control circuitry (not shown) to provide control functions for the Tx / Rx components. A UE reception is established by and via the antenna panels 426, RFFE 424, RF circuitry 422, Rx circuitry 420, digital baseband circuitry 416, and protocol processing circuitry 414. The antenna panels 426 may receive a transmission from the AN 404 by receive-beamforming signals received by a set of antennas / antenna elements of the antenna panels 426. A UE transmission is established by and via the protocol processing circuitry 414, digital baseband circuitry 416, Tx circuitry 418, RF circuitry 422, RFFE 424, and antenna panels 426. The Tx components of the UE 402 may apply a spatial filter to the data to be transmitted to form a Tx beam emitted by the antenna elements of the antenna panels 426. Attorney Docket No.: AF7269-PCT (31517-3527) Similar to the UE 402, the AN 404 includes a host platform 428 coupled with a modem platform 430. The host platform 428 includes application processing circuitry 432 coupled with protocol processing circuitry 434 of the modem platform 430. The modem platform may further include digital baseband circuitry 436, Tx circuitry 438, Rx circuitry 440, RF circuitry 442, RFFE circuitry 444, and antenna panels 446. The components of the AN 404 may be similar to and substantially interchangeable with like-named components of the UE 402. In addition to performing data transmission / reception as described previously, the components of the AN 404 may perform various logical functions that include, for example, RNC functions such as radio bearer management, UL and DL dynamic radio resource management, data packet scheduling, and / or various other functions, such as any of those discussed herein. FIG. 5 illustrates components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein. Specifically, FIG.5 shows hardware resources 500 including one or more processors (or processor cores) 510, one or more memory / storage devices 520, and one or more communication resources 530, each of which may be communicatively coupled via a bus 540 or other interface circuitry. For examples where node virtualization (e.g., NFV) is utilized, a hypervisor 502 may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 500. In some examples, the hardware resources 500 may be implemented in or by an individual compute node, which may be housed in an enclosure of various form factors. In other examples, the hardware resources 500 may be implemented by multiple compute nodes that may be deployed in one or more data centers and / or distributed across one or more geographic regions. The processors 510 include, for example, a processor 510-1 to 510-p (where p is a number). As examples, individual processors 510 may be or include a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a baseband processor, a DSP, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), a microprocessor or controller, a multi-core processor, a multithreaded processor, an ultra-low voltage processor, an embedded processor, an xPU, a data processing unit (DPU), an Infrastructure Processing Unit (IPU), a network processing unit (NPU), a neural processing unit, another processor (including any of those discussed herein), and / or any combination thereof. In some examples, individual processors 510 represent individual processor cores and / or individual compute tiles. The memory / storage devices 520 may include main memory, disk storage, or any suitable combination thereof. The memory / storage devices 520 may include, but are not limited to, any type of volatile, non-volatile, semi-volatile memory, and / or any combination thereof. As examples, the memory / storage devices 520 can be or include random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), Attorney Docket No.: AF7269-PCT (31517-3527) conductive bridge Random Access Memory (CB-RAM), spin transfer torque (STT)-MRAM, phase change RAM (PRAM), core memory, dual inline memory modules (DIMMs), microDIMMs, MiniDIMMs, block addressable memory device(s) (e.g., those based on NAND or NOR technologies (e.g., single-level cell (SLC), Multi-Level Cell (MLC), Quad-Level Cell (QLC), Tri-Level Cell (TLC), or some other NAND), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically EPROM (EEPROM), flash memory, non-volatile RAM (NVRAM), solid-state storage, magnetic disk storage mediums, optical storage mediums, memory devices that use chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single or multi- level Phase Change Memory (PCM) and / or phase change memory with a switch (PCMS), NVM devices that use chalcogenide phase change material (e.g., chalcogenide glass), a resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), anti-ferroelectric memory, magnetoresistive random access memory (MRAM) memory that incorporates memristor technology, phase change RAM (PRAM), resistive memory including the metal oxide base, the oxygen vacancy base and the conductive bridge Random Access Memory (CB-RAM), or spin transfer torque (STT)- MRAM, a spintronic magnetic junction memory based device, a magnetic tunneling junction (MTJ) based device, a Domain Wall (DW) and Spin Orbit Transfer (SOT) based device, a th7istor based memory device, and / or a combination of any of the aforementioned memory devices, and / or other memory. The communication resources 530 include, for example, interconnection controllers and / or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 504, one or more databases 506, and / or other network elements via a network 508. The network 508 may represent any suitable network (e.g., DN 336, the Internet, an enterprise network, WAN, LAN, WLAN, VPN, and / or the like), an edge computing network, a cloud computing service, and / or the like. For example, the communication resources 530 can include wired communication components (e.g., for coupling via USB, Ethernet, and / or the like), cellular communication components, NFC components, Bluetooth® components, WLAN (e.g., WiFi®) components, and / or some other communication components. Instructions 550 comprise software, program code, application(s), applet(s), an app(s), firmware, microcode, machine code, and / or other executable code for causing at least any of the processors 510 to perform any one or more of the methodologies and / or techniques discussed herein. The instructions 550 may reside, completely or partially, within at least one of the processors 510 (e.g., within the processor’s cache memory), the memory / storage devices 520, or any suitable combination thereof. Furthermore, any portion of the instructions 550 may be transferred to the hardware resources 500 from any combination of the peripheral devices 504 or the databases 506. Accordingly, the memory of processors 510, the memory / storage devices 520, the peripheral devices 504, and the databases 506 are examples of computer-readable and machine-readable media. Attorney Docket No.: AF7269-PCT (31517-3527) FIG.6 illustrates an example cellular network 600. The network 600 may operate in a matter consistent with 3GPP technical specifications or technical reports for 6G systems. In some examples, the network 600 may operate concurrently with network 300. For example, in some examples, the network 600 may share one or more frequency or bandwidth resources with network 300. As one specific example, a UE (e.g., UE 602) may be configured to operate in both network 600 and network 300. Such configuration may be based on a UE including circuitry configured for communication with frequency and bandwidth resources of both networks 300 and 600. In general, several elements of network 600 may share one or more characteristics with elements of network 300. For the sake of brevity and clarity, such elements may not be repeated in the description of network 600. The network 600 may include a UE 602, which may include any mobile or non-mobile computing device designed to communicate with a RAN 608 via an over-the-air connection. The UE 602 may be similar to, for example, UE 302. The UE 602 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic / engine control unit, electronic / engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, IoT device, and / or the like. Although not specifically shown in Figure 6, in some examples the network 600 may include a set of UEs coupled directly with one another via a sidelink interface. The UEs may be M2M / D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, and / or the like. Similarly, although not specifically shown in Figure 6, the UE 602 may be communicatively coupled with an AP such as AP 306 as described with respect to Figure 3. Additionally, although not specifically shown in Figure 6, in some examples the RAN 608 may include one or more ANs such as gNB 314 as described with respect to Figure 3. The RAN 608 and / or the AN of the RAN 608 may be referred to as a base station (BS), a RAN node, or using some other term or name. The UE 602 and the RAN 608 may be configured to communicate via an air interface that may be referred to as a sixth generation (6G) air interface. The 6G air interface may include one or more features such as communication in a terahertz (THz) or sub-THz bandwidth, or joint communication and sensing. As used herein, the term “joint communication and sensing” may refer to a system that allows for wireless communication as well as radar-based sensing via various types of multiplexing. As used herein, THz or sub-THz bandwidths may refer to communication in the 80 GHz and above frequency ranges. Such frequency ranges may additionally or alternatively be referred to as “millimeter wave” or “mmWave” frequency ranges. The RAN 608 may allow for communication between the UE 602 and a 6G core network (CN) 610. Specifically, the RAN 608 may facilitate the transmission and reception of data between the UE Attorney Docket No.: AF7269-PCT (31517-3527) 602 and the 6G CN 610. The 6G CN 610 may include various functions such as NSSF 350, NEF 352, NRF 354, PCF 356, UDM 358, AF 360, SMF 346, and AUSF 342. The 6G CN 610 may additional include UPF 348 and DN 336 as shown in Figure 6. Additionally, the RAN 608 may include various additional functions that are in addition to, or alternative to, functions of a legacy cellular network such as a 4G or 5G network. Two such functions may include a Compute Control Function (Comp CF) 624 and a Compute Service Function (Comp SF) 636. The Comp CF 624 and the Comp SF 636 may be parts or functions of the Computing Service Plane. Comp CF 624 may be a control plane function that provides functionalities such as management of the Comp SF 636, computing task context generation and management (e.g., create, read, modify, delete), interaction with the underlaying computing infrastructure for computing resource management, and / or the like. Comp SF 636 may be a user plane function that serves as the gateway to interface computing service users (such as UE 602) and computing nodes behind a Comp SF instance. Some functionalities of the Comp SF 636 may include: parse computing service data received from users to compute tasks executable by computing nodes; hold service mesh ingress gateway or service API gateway; service and charging policies enforcement; performance monitoring and telemetry collection, and / or the like. In some examples, a Comp SF 636 instance may serve as the user plane gateway for a cluster of computing nodes. A Comp CF 624 instance may control one or more Comp SF 636 instances. Two other such functions may include a Communication Control Function (Comm CF) 628 and a Communication Service Function (Comm SF) 638, which may be parts of the Communication Service Plane. The Comm CF 628 may be the control plane function for managing the Comm SF 638, communication sessions creation / configuration / releasing, and managing communication session context. The Comm SF 638 may be a user plane function for data transport. Comm CF 628 and Comm SF 638 may be considered as upgrades of SMF 346 and UPF 348, which were described with respect to a 5G system in Figure 3. The upgrades provided by the Comm CF 628 and the Comm SF 638 may enable service-aware transport. For legacy (e.g., 4G or 5G) data transport, SMF 346 and UPF 348 may still be used. Two other such functions may include a Data Control Function (Data CF) 622 and Data Service Function (Data SF) 632 may be parts of the Data Service Plane. Data CF 622 may be a control plane function and provides functionalities such as Data SF 632 management, Data service creation / configuration / releasing, Data service context management, and / or the like. Data SF 632 may be a user plane function and serve as the gateway between data service users (such as UE 602 and the various functions of the 6G CN 610) and data service endpoints behind the gateway. Specific functionalities may include: parse data service user data and forward to corresponding data service endpoints, generate charging data, report data service status. Another such function may be the Service Orchestration and Chaining Function (SOCF) 620, which may discover, orchestrate and chain up communication / computing / data services provided by functions in the network. Upon receiving service requests from users, SOCF 620 may interact with one Attorney Docket No.: AF7269-PCT (31517-3527) or more of Comp CF 624, Comm CF 628, and Data CF 622 to identify Comp SF 636, Comm SF 638, and Data SF 632 instances, configure service resources, and generate the service chain, which could contain multiple Comp SF 636, Comm SF 638, and Data SF 632 instances and their associated computing endpoints. Workload processing and data movement may then be conducted within the generated service chain. The SOCF 620 may also responsible for maintaining, updating, and releasing a created service chain. Another such function may be the service registration function (SRF) 612, which may act as a registry for system services provided in the user plane such as services provided by service endpoints behind Comp SF 636 and Data SF 632 gateways and services provided by the UE 602. The SRF 612 may be considered a counterpart of NRF 354, which may act as the registry for network functions. Other such functions may include an evolved service communication proxy (eSCP) and service infrastructure control function (SICF) 626, which may provide service communication infrastructure for control plane services and user plane services. The eSCP may be related to the service communication proxy (SCP) of 5G with user plane service communication proxy capabilities being added. The eSCP is therefore expressed in two parts: eCSP-C 612 and eSCP-U 634, for control plane service communication proxy and user plane service communication proxy, respectively. The SICF 626 may control and configure eCSP instances in terms of service traffic routing policies, access rules, load balancing configurations, performance monitoring, and / or the like. Another such function is the AMF 644. The AMF 644 may be similar to 344, but with additional functionality. Specifically, the AMF 644 may include potential functional repartition, such as move the message forwarding functionality from the AMF 644 to the RAN 608. Another such function is the service orchestration exposure function (SOEF) 618. The SOEF may be configured to expose service orchestration and chaining services to external users such as applications. The UE 602 may include an additional function that is referred to as a computing client service function (comp CSF) 604. The comp CSF 604 may have both the control plane functionalities and user plane functionalities, and may interact with corresponding network side functions such as SOCF 620, Comp CF 624, Comp SF 636, Data CF 622, and / or Data SF 632 for service discovery, request / response, compute task workload exchange, and / or the like. The Comp CSF 604 may also work with network side functions to decide on whether a computing task should be run on the UE 602, the RAN 608, and / or an element of the 6G CN 610. The UE 602 and / or the Comp CSF 604 may include a service mesh proxy 606. The service mesh proxy 606 may act as a proxy for service-to-service communication in the user plane. Capabilities of the service mesh proxy 606 may include one or more of addressing, security, load balancing, and / or the like. FIG. 7 shows example network deployments including an example next generation fronthaul (NGF) deployment 700a where a user equipment (UE) 702 is connected to an RU 730 (also referred to Attorney Docket No.: AF7269-PCT (31517-3527) as a “remote radio unit 730”, “a remote radio head 730”, or “ RRH 730”) via an air interface, the RU 730 is connected to a Digital Unit (DU) 731 via a NGF interface (NGFI)-I, the DU 731 is connected to a Central Unit (CU) 732 via an NGFI-II, and the CU 732 is connected to a core network (CN) 742 via a backhaul interface. In 3GPP NG-RAN implementations (see e.g., [TS38401]), the DU 731 may be a distributed unit (for purposes of the present disclosure, the term “DU” may refer to a digital unit and / or a distributed unit unless the context dictates otherwise). The UEs 702 may be the same or similar to, and / or share one or more features with UE 302, UE 402, hardware resources 500, UE 602, and / or any other UE described herein. In some implementations, the NGF deployment 700a may be arranged in a distributed RAN (D-RAN) architecture where the CU 732, DU 731, and RU 730 reside at a cell site and the CN 742 is located at a centralized site. Alternatively, the NGF deployment 700a may be arranged in a centralized RAN (C-RAN) architecture with centralized processing of one or more baseband units (BBUs) at the centralized site. In C-RAN architectures, the radio components are split into discrete components, which can be located in different locations. In one example C-RAN implementation, only the RU 730 is disposed at the cell site, and the DU 731, the CU 732, and the CN 742 are centralized or disposed at a central location. In another example C-RAN implementation, the RU 730 and the DU 731 are located at the cell site ,and the CU 732 and the CN 742 are at the centralized site. In another example C-RAN implementation, only the RU 730 is disposed at the cell site, the DU 731 and the CU 732 are located a RAN hub site, and the CN 742 is at the centralized site. The CU 732 is a central controller that can serve or otherwise connect to one or multiple DUs 731 and / or multiple RUs 730. The CU 732 is network (logical) nodes hosting higher / upper layers of a network protocol functional split. For example, in the 3GPP NG-RAN and / or O-RAN architectures, a CU 732 hosts the radio resource control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) layers of a next generation NodeB (gNB), or hosts the RRC and PDCP protocol layers when included in or operating as an E-UTRA-NR gNB (en-gNB). The SDAP sublayer performs mapping between QoS flows and a data radio bearers (DRBs) and marking QoS flow IDs (QFI) in both DL and UL packets. The PDCP sublayer performs transfers user plane or control plane data; maintains PDCP sequence numbers (SNs); header compression and decompression using the Robust Header Compression (ROHC) and / or Ethernet Header Compression (EHC) protocols; ciphering and deciphering; integrity protection and integrity verification; provides timer based SDU discard; routing for split bearers; duplication and duplicate discarding; reordering and in-order delivery; and / or out-of-order delivery. In various implementations, a CU 732 terminates respective F1 interfaces connected with corresponding DUs 731 (see e.g., [TS38401]). A CU 732 may include a CU-control plane (CP) entity (referred to herein as “CU-CP 732”) and a CU-user plane (UP) entity (referred to herein as “CU-UP 732”). The CU-CP 732 is a logical node hosting the RRC layer and the control plane part of the PDCP protocol layer of the CU 732 (e.g., a gNB-CU for an en-gNB or a gNB). The CU-CP terminates an E1 interface connected with the CU-UP Attorney Docket No.: AF7269-PCT (31517-3527) and the F1-C interface connected with a DU 731. The CU-UP 732 is a logical node hosting the user plane part of the PDCP protocol layer (e.g., for a gNB-CU 732 of an en-gNB), and the user plane part of the PDCP protocol layer and the SDAP protocol layer (e.g., for the gNB-CU 732 of a gNB). The CU-UP 732 terminates the E1 interface connected with the CU-CP 732 and the F1-U interface connected with a DU 731. The DU 731 controls radio resources, such as time and frequency bands, locally in real time, and allocates resources to one or more UEs. The DUs 731 are network (logical) nodes hosting middle and / or lower layers of the network protocol functional split. For example, in the 3GPP NG-RAN and / or O-RAN architectures, a DU 731 hosts the radio link control (RLC), medium access control (MAC), and high-physical (PHY) layers of the gNB or en-gNB, and its operation is at least partly controlled by the CU 732. The RU 730 is a transmission / reception point (TRP) or other physical node that handles radiofrequency (RF) processing functions. The RU 730 is a network (logical) node hosting lower layers based on a lower layer functional split. For example, in 3GPP NG-RAN and / or O-RAN architectures, the RU 730 hosts low-PHY layer functions and RF processing of the radio interface based on a lower layer functional split. The RU 730 may be similar to 3GPP’s transmission / reception point (TRP) or RRH, but specifically includes the Low-PHY layer. Examples of the low-PHY functions include fast Fourier transform (FFT), inverse FFT (iFFT), physical random access channel (PRACH) extraction, and the like. Each of the CUs 732, DUs 731, and RUs 730 are connected through respective links, which may be any suitable wireless and / or wired (e.g., fiber, copper, and the like) links. In some implementations, various combinations of the CU 732, DU 731, and RU 730 may correspond to one or more of the RAN 304, gNB 314, AP 306, and / or any other NAN, such as any of those discussed herein. Additional aspects of CUs 732, DUs 731, and RUs 730 are discussed in [O-RAN], [TS38401], [TS38410], and [TS38300]. 2.1. EXTENDED REALITY (XR) SYSTEM ASPECTS Extended reality (XR) is a catch-all term (or umbrella term) for different types of realities and refers to all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables. In particular, the term “XR” includes and / or refers to augmented reality (AR), virtual reality (VR), mixed reality or mediated reality (MR) technologies, where "X" in “XR” is a variable that can interpolate between these various realities or extrapolate or extend beyond them. The XR fields are rapidly growing and being applied in a wide range of areas, such as entertainment, marketing, real estate, training, maintenance, and remote work. FIG.8 depicts an example XR traffic model 800. The XR traffic model 800 follows the 5GS architecture discussed w.r.t Figure 3 and / or as defined in [TS23501]. In particular, the user plane aspects are considered as shown by Figure 8 for which an XR server 838 is in the external DN 338 or Attorney Docket No.: AF7269-PCT (31517-3527) in a trusted DN 338, and the XR device 802 is a 5G-capable UE, which may be the same or similar as UE 302 of Figure 3. As examples, the XR server 838 may be hosted in the cloud (e.g., by one or more cloud compute nodes of a cloud computing service) or may be hosted at the edge (e.g., by one or more edge compute nodes of an edge computing system / network). The XR device 802 can include suitable XR hardware components for communicating and rendering / displaying XR content. Examples of such XR hardware components include processor circuitry, output circuitry (e.g., actuators, display(s), and / or the like), optical elements (e.g., waveguides (e.g., diffractive, reflective, holographic, polarized, and / or the like), diffusers, lenses, mirrors, projectors, picture generation units, holographic optical elements (HOEs), and / or the like), one or more sensors, and input circuitry. The input circuitry and / or sensor(s) may include, for example, image capture devices (e.g., visible-light cameras, infrared cameras, ultraviolet- light cameras, and / or the like), proximity sensors, GPS circuitry, and / or microelectromechanical systems (MEMS) sensors, such as accelerometers, g7oscopes, solid state compasses, and / or the like. Additionally or alternatively, the sensor(s), input circuitry, and / or output circuitry, may include any of the devices / components as the peripheral devices 504 discussed w.r.t Figure 5. As examples, the XR device 802 may be a head-up display (HUD), head-mounted display (HMD) and / or optical HMD, AR / VR headset, smart glasses, EyeTap device, XR contact lenses and / or bionic contact lenses, smart watch, handheld XR device, projector / projection mapper, and / or any other suitable devices, such as any of those discussed herein. In this example, the exchange of data is carried out using the 5GS 300. Interfaces to the 5GC functions for charging, QoS control, and / or the like are not shown by Figure 8, but may include any of those discussed infra w.r.t Figure 3 and / or as discussed in [TS23501]. Additionally, aspects of the XR traffic model 800 are discussed in 3GPP TR 26.926 (“[TR26926]”), 3GPP TR 26.928 (“[TR26298]”), 3GPP TR 26.925, 3GPP TR 38.838, and 3GPP TS 26.501. FIG. 9 depicts an example architecture and system model for XR traffic, which supports modelling of end-to-end XR Traffic. This system is used as a baseline and may be refined for specific traffic classes. The system follows the basic building blocks from Figure 8, but provides details for each of those aspects. In order to support simpler system modelling and simulation, the interfaces are supported by traces. Traces define a well-defined format to describe a sequence of timed data units together with relevant metadata for system simulation. Aspects of the traces in Figure 9 are discussed infra. The system model of Figure 9 includes a content model based on traces, which may be provided based on stakeholder input providing sufficient information on a rendered application (e.g., a game or a scene). Based on these content model traces, codec centric experts defines a content encoding and delivery model taking into account a system design, for example based on [TR26298]. The system model includes encoding, delivery, decoding, and also a quality definition, providing packet traces. Attorney Docket No.: AF7269-PCT (31517-3527) 5GS and RAN simulations may be carried out by the 3GPP radio experts using the packet traces to simulate different traffic characteristics and evaluate different performance options. The system model of Figure 9 includes various functions, which are described infra. Several of these functions are initialized by appropriate configuration(s). An overview of configurations is introduced in each of the functions, if needed. Additional aspects of the various functions and / or configurations are discussed in [TR26926]. The content model provides typical characteristics for the XR content model for video, audio, and potentially other data. This content is rendered for XR / CG consumption. The content encoding model provides the details for the content encoding in order to meet certain objectives. This includes the generation of sequences of application data units (e.g., slices, video frames, audio frames, and / or the like) and the incurred timestamp of each of the units is available. The content delivery model provides details on content delivery, for example, packetization, delay jitter, but possibly also more sophisticated models such as retransmission, TCP operations, and so forth. This also includes emulation of the 5GC 340. It produces packet traces (e.g., timestamp and size of each packet) based on traces of application data units. The core network model emulates the core network behavior in terms of delay, latency, and packet losses in the core network 340 (e.g., the interface between the UPF 348 and gNB 314). The packet radio model receives sequences / traces of packets at a given time and of a specified size. The packets may have additional metadata assigned that can potentially be used by the radio simulator. The packet traces are provided for multiple users and reflect typical traffic characteristics. The RAN simulator provides packet traces after delivery that reflect the occurred delays and losses for each user. The content receiver model converts the packet traces into application units taking into account delays and losses occurred. It may also model additional functions, such as retransmissions or FEC, if applicable. The content decoding model uses the received application units to model the reconstruction of timed data (e.g., video frames, audio, and the like) considering delays, losses and also content model properties (e.g., error propagation, refresh data, and the like). A quality evaluation tool is provided that takes into account traces to compute different quality metrics based on packet, application unit and media quality. The uplink model is a model for uplink traffic in a similar fashion also providing packet traces. Generally, traces include the following information: time series of data units; size of each data units; association to the application; and / or additional “metadata”. Traces can also directly be fed to a quality evaluation tool obtain the application quality based on the simulation as shown in clause 5.8 of [TR26926]. The benefit of traces compared to first order statistical model are as follows: traces to represent time correlations; traces can be used to assign additional metadata in the time series; statistical models can be developed based on time series; traces can be directly fed to quality evaluation tool. The trace formats are defined as CSV files and follow the recommendation in Y. Shafranovich, Common Format and MIME Type for CSV Files, IETF RFC 4180 (Oct.2005). For CSV files, headers are added Attorney Docket No.: AF7269-PCT (31517-3527) to identify the data types. From existing CSV types, the online tool https: / / csv.openbridge.dev / has been used to validate the csv file, and create a schema for the files. Figure 9 shows different traces, associated to different interfaces, including video traces (V- Traces), video receive traces (V’-Traces), slice traces (S-Traces), S’-Traces, packet / PDU traces (P- Traces), and P’-Traces. V-Traces provide a time series of the statistics / complexity of a video frame (see e.g., [TR26926] § 5.5). Such a V-Trace is expected to provide sufficient information such that a coding model can create suitable statistics statics for encoded video streams at the output. V’-Traces provide a time series of received video frames together with an associated encoding and delivery quality (see e.g., [TR26926] § 5.8). S-Traces provide a time series of encoded video application data units, referred to as slices as known from H.264 / AVC and H.265 / HEVC suitable application data units as outputs from a video codecs (see e.g., [TR26926] § 5.6). S-Traces are expected to provide sufficient information to the content delivery module to create IP packets. S’-Traces are have the same format as S-Traces, but in addition may include information on losses and distortions due to the delivery over a network (see e.g., [TR26926] § 5.7). P Traces provide a time series of IP packets, possibly associated with different application flows and / or QoS Flows (see e.g., [TR26926] § 5.3). In addition, they provide metadata information that may be beneficial for advanced delivery. P’-Traces have the same format as P-Traces, but in addition may include losses and delays observed due to the delivery over a network. Additional aspects of the various traces are discussed in [TR26926]. FIG. 10 depicts an example 5G-XR functions integrated in a 5GS (e.g., 5GS 300). The integration of XR applications (e.g., 5G-XR aware application 1020) within the 5GS is approached following the model of 5G media streaming as defined in 3GPP TS 26.501 (“[TS26501]”). Assume a 5G-XR application provider (AP) 1040 being an XR AP 1040 that makes use of 5GS functionalities for its services. For this purpose, it provides a 5G-XR aware application (AA) 1020 on the UE 302 to make use of a 5G-XR client 1002 and NFs using network interfaces and APIs, potentially defined in 5G-XR related specifications. The architecture in Figure 10 represents potential 5G-XR functions within the 5GS as defined in [TS23501], and includes a 5G-XR AF 1060, 5G-XR application server (AS) 1062, and a 5G-XR client 1002. The 5G-XR AF 1060 is an AF similar to AF 360 and / or the AF as defined in [TS23501] § 6.2.10, dedicated to 5G-XR Services. The 5G-XR AS 1062 is an AS dedicated to 5G-XR services, and the 5G-XR client 1002 is a UE internal function dedicated to 5G-XR services. The 5G-XR AF 1060 and 5G-XR AS 1062 are initially considered Data Network (DN) functions and communicate with the UE 302 via the N6, N3, and Uu interfaces as discussed herein and / or as defined in [TS23501]. Communication through sidelink PC5 may be an alternative to Uu based communication. Additionally or alternatively, 5G radio may also be differentiated between 5G Uu and 5G Sidelink / PC5. Uu is the interface between the UE 302 and the RAN 304 as defined in 3GPP TS 38.300, and sidelink is a mode of communication whereby UEs 302 can communicate with each other directly as defined in 3GPP TS 38.300. Attorney Docket No.: AF7269-PCT (31517-3527) Functions in trusted DNs 336 are trusted by the operator’s network as illustrated. Therefore, AFs in trusted DNs 336 may directly communicate with all 5GC functions. Functions in external DNs 336 may only communicate with 5GC functions via the NEF 352 using the N33 interface. The architecture of Figure 10 is used as a starting point. With XR related functions exclusively assigned to either DN 336 or UE 302. However, architectural extensions may be identified for the 3GPP system that may benefit from XR applications. Examples include the use of network slicing, edge computing, and / or usage of 5G QoS models. FIG. 11 depicts an example 5G-XR architecture integrated in 5G and related interfaces. The XR architecture of Figure 11 includes an 5G-XR client 1002 on UE 302. The 5G-XR client 1002 is a transmitter / receiver of 5G-XR session data that may be accessed through well-defined interfaces / APIs by the 5G-XR AA 1020. In this example, the 5G-XR client 1002 contains two sub-functions: an XR engine 1110 and an XR session handler 1115. The XR session handler 1115 is a function of the UE 302 that communicates with the 5G-XR AF in order to establish, control and support the delivery of an XR session. The XR session handler 1115 exposes APIs that can be used by the 5G-XR AA 1020. The XR engine 1110 is a function of the UE 302 that communicates with the 5G-XR AS 1062 in order to get access to XR related data, includes XR relevant functionalities (e.g., sensors, actuators, tracking, and / or the like), processes the XR data and communicates with the XR session handler 1115 for XR session control. XR engines 1110 provide a middleware that abstracts hardware and software functionalities for developers of XR applications. The 5G-XR client 1002 may be controlled by an internal and / or external XR AA 1020. In some examples, the XR AA 1020 is an app, which implements the external application service provider specific logic and enables establishment of an XR session. The 5G-XR AA 1020 makes use of 5G-XR client 1002 and NFs using interfaces and APIs. The 5G-XR AS 1062 is an AS that hosts 5G-XR media and media functions. The 5G-XR AP 1040 is an external XR AP that makes use of 5G-XR client 1002 and network functionalities to provide an XR experience to 5G-XR AAs 1020. The 5G-XR AF 1060 provides various control functions to the XR session handler 1115 on / in the UE 302 and / or to the 5G-XR AP 1040. The 5G-XR AF 1060 may relay or initiate a request for different policy or charging function (PCF) 356 treatment or interact with other network functions. FIG.12 depicts an example of processor (e.g., CPU and GPU) operations for XR applications. The XR engine 1110 is operated on or by one or more processors 1210, which interacts with one or more processors 1220. As examples, the processor(s) 1210, 1220 may include one or more CPUs, hardware accelerators, GPUs, FPGAs, ASICs, SoCs, MCPs, DSPs, and / or other like hardware elements. In some examples, one or more of the processor(s) 1210, 1220 correspond to processor(s) 510 of Figure Attorney Docket No.: AF7269-PCT (31517-3527) 5. In the example of Figure 11, the processor(s) 1210 include one or more CPUs and the processor(s) 1220 include one or more GPUs. The XR engine 1110 is a software-development environment designed for people to build XR experiences, such as games, virtual worlds, and / or other XR applications. Examples of the core functionality provided by XR engines 1110 include a rendering engine (“renderer”) for 2D or 3D graphics (e.g., provided by a main control loop / engine 1201 and / or provided by processors, such as GPU(s), accelerator(s), and / or the like), a physics engine or collision detection (and collision response) (e.g., provided by physics engine 1203), sound (e.g., provided by audio engine 1202), scripting, animation, artificial intelligence (e.g., provided by AI engine 1204), networking, streaming (e.g., provided by streaming engine 1206), memory management, threading, localization support (e.g., provided by localization engine 1207), scene graph (e.g., provided by scene graph engine 1205), and may include video support. The rendering engine provides the functionalities as documented in [TR26298] § 4.2.2 with a set of well defined APIs. The rendering engine generates animated 3D graphics by any of a number of methods (e.g., rasterization, ray-tracing, and / or the like). Instead of being programmed and compiled to be executed on the CPU or GPU directly, most often rendering engines are built upon one or multiple rendering (abstraction) APIs 1211, such as Direct3D, OpenGL, Vulkan, and / or the like, which provide a software abstraction of the GPU(s). The audio engine 1202 is a component that includes algorithms related to the loading, modifying, and output of sound through the client's speaker system. At a minimum it is able to load, decompress, and play sound files. More advanced audio engines 1202 can calculate and produce such configurations as Doppler effects, echoes, pitch / amplitude adjustments, oscillation, and / or the like. The audio engine 1202 can perform calculations on the CPU, a dedicated ASIC, FPGA, and / or some other hardware device, component, or element, such as any of those discussed herein. Abstraction APIs 1211 (e.g., OpenAL, SDL audio, XAudio 2, Web Audio, and / or the like) are also available. The physics engine 1203 is responsible for emulating the laws of physics realistically within the XR application. Specifically, the physics engine 1203 provides a set of functions for simulating physical forces and collisions, acting on the various objects within the scene at run time. The AI engine 1204 is usually outsourced from the main XR engine 1110 into a special module, device, component, or other entity / element. XR applications may implement very different AI systems, and thus, AI is considered to be specific to the particular XR application for which it is created. For the purposes of the present document, the following terms and definitions are applicable to the examples and embodiments discussed herein. As used herein, the singular forms “a,” “an” and “the” are intended to include plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specific the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operation, elements, Attorney Docket No.: AF7269-PCT (31517-3527) components, and / or groups thereof. The phrase “A and / or B” means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase “A, B, and / or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C). The phrase “X(s)” means one or more X or a set of X. The description may use the phrases “in an embodiment,” “In some embodiments,” “in one implementation,” “In some implementations,” “in some examples”, and the like, each of which may refer to one or more of the same or different embodiments, implementations, and / or examples. Furthermore, the terms “comprising,” “including,” “having,” and the like, as used with respect to the present disclosure, are synonymous. The terms “coupled,” “communicatively coupled,” along with derivatives thereof are used herein. The term “coupled” may mean two or more elements are in direct physical or electrical contact with one another, may mean that two or more elements indirectly contact each other but still cooperate or interact with each other, and / or may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other. The term “directly coupled” may mean that two or more elements are in direct contact with one another. The term “communicatively coupled” may mean that two or more elements may be in contact with one another by a means of communication including through a wire or other interconnect connection, through a wireless communication channel or ink, and / or the like. The term “identifier” at least in some examples refers to a value, or a set of values, that uniquely identify an identity in a certain scope. Additionally or alternatively, the term “identifier” at least in some examples refers to a sequence of characters that identifies or otherwise indicates the identity of a unique object, element, or entity, or a unique class of objects, elements, or entities. Additionally or alternatively, the term “identifier” at least in some examples refers to a sequence of characters used to identify or refer to an application, program, session, object, element, entity, variable, set of data, and / or the like. The “sequence of characters” mentioned previously at least in some examples refers to one or more names, labels, words, numbers, letters, symbols, and / or any combination thereof. Additionally or alternatively, the term “identifier” at least in some examples refers to a name, address, label, distinguishing index, and / or attribute. Additionally or alternatively, the term “identifier” at least in some examples refers to an instance of identification. The term “persistent identifier” at least in some examples refers to an identifier that is reused by a device or by another device associated with the same person or group of persons for an indefinite period. The term “identification” at least in some examples refers to a process of recognizing an identity as distinct from other identities in a particular scope or context, which may involve processing identifiers to reference an identity in an identity database. The term “application identifier”, “application ID”, or “app ID” at least in some examples refers to an identifier that can be mapped to a specific application, application instance, or application instance. In the context of 3GPP 5G / NR, an “application identifier” at least in some examples refers to an identifier that can be mapped to a specific application traffic detection rule. Attorney Docket No.: AF7269-PCT (31517-3527) The term “circuitry” at least in some examples refers to a circuit or system of multiple circuits configured to perform a particular function in an electronic device. The circuit or system of circuits may be part of, or include one or more hardware components, such as a logic circuit, a processor (shared, dedicated, or group) and / or memory (shared, dedicated, or group), an application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), programmable logic controller (PLC), single- board computer (SBC), system on chip (SoC), system in package (SiP), multi-chip package (MCP), digital signal processor (DSP), and the like, that are configured to provide the described functionality. In addition, the term “circuitry” may also refer to a combination of one or more hardware elements with the program code used to carry out the functionality of that program code. Some types of circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. Such a combination of hardware elements and program code may be referred to as a particular type of circuitry. The term “processor circuitry” at least in some examples refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and / or transferring digital data. The term “processor circuitry” at least in some examples refers to one or more application processors, one or more baseband processors, a physical CPU, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and / or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and / or functional processes. The terms “application circuitry” and / or “baseband circuitry” may be considered synonymous to, and may be referred to as, “processor circuitry.” The term “memory” and / or “memory circuitry” at least in some examples refers to one or more hardware devices for storing data, including random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), conductive bridge Random Access Memory (CB-RAM), spin transfer torque (STT)-MRAM, phase change RAM (PRAM), core memory, read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically EPROM (EEPROM), flash memory, non-volatile RAM (NVRAM), magnetic disk storage mediums, optical storage mediums, flash memory devices or other machine readable mediums for storing data. The term “computer-readable medium” includes, but is not limited to, memory, portable or fixed storage devices, optical storage devices, and various other mediums capable of storing, containing or carrying instructions or data. The terms “machine-readable medium” and “computer-readable medium” refers to tangible medium that is capable of storing, encoding or carrying instructions for execution by a machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. A “machine-readable medium” thus includes but is not limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile Attorney Docket No.: AF7269-PCT (31517-3527) memory, including but not limited to, by way of example, semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The instructions embodied by a machine-readable medium may further be transmitted or received over a communications network using a transmission medium via a network interface device utilizing any one of a number of transfer protocols (e.g., HTTP). A machine-readable medium may be provided by a storage device or other apparatus which is capable of hosting data in a non-transitory format. In an example, information stored or otherwise provided on a machine-readable medium may be representative of instructions, such as instructions themselves or a format from which the instructions may be derived. This format from which the instructions may be derived includes source code, encoded instructions (e.g., in compressed or encrypted form), packaged instructions (e.g., split into multiple packages), or the like. The information representative of the instructions in the machine-readable medium may be processed by processing circuitry into the instructions to implement any of the operations discussed herein. For example, deriving the instructions from the information (e.g., processing by the processing circuitry) includes: compiling (e.g., from source code, object code, and / or the like), interpreting, loading, organizing (e.g., dynamically or statically linking), encoding, decoding, encrypting, unencrypting, packaging, unpackaging, or otherwise manipulating the information into the instructions. In an example, the derivation of the instructions includes assembly, compilation, or interpretation of the information (e.g., by the processing circuitry) to create the instructions from some intermediate or preprocessed format provided by the machine-readable medium. The information, when provided in multiple parts, may be combined, unpacked, and modified to create the instructions. For example, the information may be in multiple compressed source code packages (or object code, or binary executable code, and / or the like) on one or several remote servers. The source code packages may be encrypted when in transit over a network and decrypted, uncompressed, assembled (e.g., linked) if necessary, and compiled or interpreted (e.g., into a library, stand-alone executable, and / or the like) at a local machine, and executed by the local machine. The terms “machine-readable medium” and “computer-readable medium” may be interchangeable for purposes of the present disclosure. The term “non-transitory computer-readable medium at least in some examples refers to any type of memory, computer readable storage device, and / or storage disk and may exclude propagating signals and transmission media. The term “interface circuitry” at least in some examples refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” at least in some examples refers to one or more hardware interfaces, for example, buses, I / O interfaces, peripheral component interfaces, network interface cards, and / or the like. Attorney Docket No.: AF7269-PCT (31517-3527) The term “device” at least in some examples refers to a physical entity embedded inside, or attached to, another physical entity in its vicinity, with capabilities to convey digital information from or to that physical entity. Although many of the previous examples are provided with use of specific cellular / mobile network terminology, including with the use of 4G / 5G 3GPP network components (or expected terahertz-based 6G / 6G+ technologies), it will be understood these examples may be applied to many other deployments of wide area and local wireless networks, as well as the integration of wired networks (including optical networks and associated fibers, transceivers, and / or the like). Furthermore, various standards (e.g, 3GPP, ETSI, and / or the like) may define various message formats, PDUs, containers, frames, and / or the like, as comprising a sequence of optional or mandatory data elements (DEs), data frames (DFs), information elements (IEs), and / or the like. However, it should be understood that the requirements of any particular standard should not limit the examples discussed herein, and as such, any combination of containers, frames, DFs, DEs, IEs, values, actions, and / or features are possible in various examples, including any combination of containers, DFs, DEs, values, actions, and / or features that are strictly required to be followed in order to conform to such standards or any combination of containers, frames, DFs, DEs, IEs, values, actions, and / or features strongly recommended and / or used with or in the presence / absence of optional elements. Aspects of the inventive subject matter may be referred to herein, individually and / or collectively, merely for convenience and without intending to voluntarily limit the scope of this application to any single aspect or inventive concept if more than one is in fact disclosed. Thus, although specific aspects have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific aspects shown. This disclosure is intended to cover any and all adaptations or variations of various aspects. Combinations of the above aspects and other aspects not specifically described herein will be apparent to those of skill in the art upon reviewing the above description. The following examples pertain to further embodiments. For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and / or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. The terms “computing device,” “user device,” “communication Attorney Docket No.: AF7269-PCT (31517-3527) station,” “station,” “handheld device,” “mobile device,” “wireless device” and “user equipment” (UE) as used herein refers to a wireless communication device such as a cellular telephone, a smartphone, a tablet, a netbook, a wireless terminal, a laptop computer, a femtocell, a high data rate (HDR) subscriber station, an access point, a printer, a point of sale device, an access terminal, or other personal communication system (PCS) device. The device may be either mobile or stationary. As used within this document, the term “communicate” is intended to include transmitting, or receiving, or both transmitting and receiving. This may be particularly useful in claims when describing the organization of data that is being transmitted by one device and received by another, but only the functionality of one of those devices is required to infringe the claim. Similarly, the bidirectional exchange of data between two devices (both devices transmit and receive during the exchange) may be described as “communicating,” when only the functionality of one of those devices is being claimed. The term “communicating” as used herein with respect to a wireless communication signal includes transmitting the wireless communication signal and / or receiving the wireless communication signal. For example, a wireless communication unit, which is capable of communicating a wireless communication signal, may include a wireless transmitter to transmit the wireless communication signal to at least one other wireless communication unit, and / or a wireless communication receiver to receive the wireless communication signal from at least one other wireless communication unit. As used herein, unless otherwise specified, the use of the ordinal adjectives “first,” “second,” “third,” etc., to describe a common object, merely indicates that different instances of like objects are being referred to and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner. The term “access point” (AP) as used herein may be a fixed station. An access point may also be referred to as an access node, a base station, an evolved node B (eNodeB), or some other similar terminology known in the art. An access terminal may also be called a mobile station, user equipment (UE), a wireless communication device, or some other similar terminology known in the art. Embodiments disclosed herein generally pertain to wireless networks. Some embodiments may relate to wireless networks that operate in accordance with one of the IEEE 802.11 standards. Some embodiments may be used in conjunction with various devices and systems, for example, a personal computer (PC), a desktop computer, a mobile computer, a laptop computer, a notebook computer, a tablet computer, a server computer, a handheld computer, a handheld device, a personal digital assistant (PDA) device, a handheld PDA device, an on-board device, an off-board device, a hybrid device, a vehicular device, a non-vehicular device, a mobile or portable device, a consumer device, a non-mobile or non-portable device, a wireless communication station, a wireless communication device, a wireless access point (AP), a wired or wireless router, a wired or wireless modem, a video device, an audio device, an audio-video (A / V) device, a wired or wireless network, a wireless area network, a wireless video area network (WVAN), a local area network (LAN), a wireless LAN (WLAN), a personal area network (PAN), a wireless PAN (WPAN), and the like. Attorney Docket No.: AF7269-PCT (31517-3527) Some embodiments may be used in conjunction with one way and / or two-way radio communication systems, cellular radio-telephone communication systems, a mobile phone, a cellular telephone, a wireless telephone, a personal communication system (PCS) device, a PDA device which incorporates a wireless communication device, a mobile or portable global positioning system (GPS) device, a device which incorporates a GPS receiver or transceiver or chip, a device which incorporates an RFID element or chip, a multiple input multiple output (MIMO) transceiver or device, a single input multiple output (SIMO) transceiver or device, a multiple input single output (MISO) transceiver or device, a device having one or more internal antennas and / or external antennas, digital video broadcast (DVB) devices or systems, multi-standard radio devices or systems, a wired or wireless handheld device, e.g., a smartphone, a wireless application protocol (WAP) device, or the like. Some embodiments may be used in conjunction with one or more types of wireless communication signals and / or systems following one or more wireless communication protocols, for example, radio frequency (RF), infrared (IR), frequency-division multiplexing (FDM), orthogonal FDM (OFDM), time-division multiplexing (TDM), time-division multiple access (TDMA), extended TDMA (E-TDMA), general packet radio service (GPRS), extended GPRS, code-division multiple access (CDMA), wideband CDMA (WCDMA), CDMA 2000, single-carrier CDMA, multi-carrier CDMA, multi-carrier modulation (MDM), discrete multi-tone (DMT), Bluetooth^, global positioning system (GPS), Wi-Fi, Wi-Max, ZigBee, ultra-wideband (UWB), global system for mobile communications (GSM), 2G, 2.5G, 3G, 3.5G, 4G, fifth generation (5G) mobile networks, 3GPP, long term evolution (LTE), LTE advanced, enhanced data rates for GSM Evolution (EDGE), or the like. Other embodiments may be used in various other devices, systems, and / or networks. Various embodiments are described below. Example 1 may include an apparatus of a Fifth Generation (5G) wireless communications network for supporting protocol data unit (PDU) set-level quality of service (QoS) handling, the apparatus comprising processing circuitry of an application function (AF), of a user plane function (UPF), and of a session management function (SMF), the processing circuitry coupled to storage for storing information associated with the PDU set-level QoS handling, the processing circuitry configured to: provide, by the AF, protocol description information for PDU set-level QoS handling to the UPF, wherein the PDU set-level QoS handling is indicative of PDU set-level information; identify, by the SMF, the protocol description information; provide, by the SMF, the protocol description information to the UPF; identify, by the UPF, a PSI of a detected downlink packet either based on matching the protocol description or based on metadata received by the UPF over an N6 interface of the 5G wireless communications network; encapsulate, by the UPF, the downlink packet in a general packet radio service tunneling protocol for user plane (GTP-U) header comprising the PDU set-level information and using transport level marking associated with the PSI of the downlink packet. Attorney Docket No.: AF7269-PCT (31517-3527) Example 2 may include the apparatus of example 1 and / or any other examples herein, wherein the SMF provides a list of transport level markings to the UPF in a forward action rule (FAR), and wherein to identify the PSI is based on the transport level markings. Example 3 may include the apparatus of example 1 and / or any other examples herein, wherein the SMF provides a list of transport level markings to the UPF in a QoS enforcement rule (QER), and wherein to identify the PSI is based on the transport level markings. Example 4 may include the apparatus of example 1 and / or any other examples herein, wherein the UPF receives transport level markings over an N4 interface of the 5G wireless communications network, and wherein to identify the PSI is based on the transport level markings. Example 5 may include the apparatus of example 1 and / or any other examples herein, wherein the encapsulated downlink packet further comprises a transport header comprising a differentiated service point code (DSCP) value of the encapsulated downlink packet. Example 6 may include the apparatus of example 1 and / or any other examples herein, wherein the UPF receives the protocol description information over an N4 interface of the 5G wireless communications network. Example 7 may include the apparatus of example 1 and / or any other examples herein, wherein the SMF receives the protocol description information over an N7 interface of the 5G wireless communications network. Example 8 may include a computer-readable medium storing computer-executable instructions for supporting protocol data unit (PDU) set-level quality of service (QoS) handling, which when executed by one or more processors of an application function (AF), of a user plane function (UPF), and of a session management function (SMF) of a Fifth Generation (5G) wireless communications network, result in performing operations comprising: providing by the AF, protocol description information for PDU set-level QoS handling to the UPF, wherein the PDU set-level QoS handling is indicative of PDU set-level information; identifying, by the SMF, the protocol description information; providing, by the SMF, the protocol description information to the UPF; identifying, by the UPF, a PSI of a detected downlink packet either based on matching the protocol description or based on metadata received by the UPF over an N6 interface of the 5G wireless communications network; encapsulating, by the UPF, the downlink packet in a general packet radio service tunneling protocol for user plane (GTP-U) header comprising the PDU set-level information and using transport level marking associated with the PSI of the downlink packet. Example 9 may include the computer-readable medium of example 8 and / or any other examples herein, wherein the wherein the SMF provides a list of transport level markings to the UPF in a forward action rule (FAR), and wherein identifying the PSI is based on the transport level markings. Example 10 may include the computer-readable medium of example 8 and / or any other examples herein, wherein the SMF provides a list of transport level markings to the UPF in a QoS enforcement rule (QER), and wherein identifying the PSI is based on the transport level markings. Attorney Docket No.: AF7269-PCT (31517-3527) Example 11 may include the computer-readable medium of example 8 and / or any other examples herein, wherein the UPF receives transport level markings over an N4 interface of the 5G wireless communications network), and wherein identifying the PSI is based on the transport level markings. Example 12 may include the computer-readable medium of example 8 and / or any other examples herein, wherein the encapsulated downlink packet further comprises a transport header comprising a differentiated service point code (DSCP) value of the encapsulated downlink packet. Example 13 may include the computer-readable medium of example 8 and / or any other examples herein, wherein the UPF receives the protocol description information over an N4 interface of the 5G wireless communications network. Example 14 may include the computer-readable medium of example 8 and / or any other examples herein, wherein the SMF receives the protocol description information over an N7 interface of the 5G wireless communications network. Example 15 may include a method for supporting protocol data unit (PDU) set-level quality of service (QoS) handling, the method comprising: receiving, by processing circuitry of an application function (AF) of a Fifth Generation (5G) wireless communications network, protocol description information for PDU set-level QoS handling to processing circuitry of a user plane function (UPF) of the 5G wireless communications network, wherein the PDU set-level QoS handling is indicative of PDU set-level information; identifying, by processing circuitry of a session management function (SMF) of the 5G wireless communications network, the protocol description information; providing, by the SMF, the protocol description information to the UPF; identifying, by the UPF, a PSI of a detected downlink packet either based on matching the protocol description or based on metadata received by the UPF over an N6 interface of the 5G wireless communications network; encapsulating, by the UPF, the downlink packet in a general packet radio service tunneling protocol for user plane (GTP-U) header comprising the PDU set-level information and using transport level marking associated with the PSI of the downlink packet. Example 16 may include the method of example 15 and / or any other examples herein, wherein the SMF provides a list of transport level markings to the UPF in a forward action rule (FAR), and wherein identifying the PSI is based on the transport level markings. Example 17 may include the method of example 15 and / or any other examples herein, wherein the SMF provides a list of transport level markings to the UPF in a QoS enforcement rule (QER), and wherein identifying the PSI is based on the transport level markings. Example 18 may include the method of example 15 and / or any other examples herein, wherein the UPF receives transport level markings over an N4 interface of the 5G wireless communications network, and wherein identifying the PSI is based on the transport level markings. Example 19 may include an apparatus comprising means for: receiving, using processing circuitry of an application function (AF) of a Fifth Generation (5G) wireless communications network, Attorney Docket No.: AF7269-PCT (31517-3527) protocol description information for PDU set-level QoS handling to processing circuitry of a user plane function (UPF) of the 5G wireless communications network, wherein the PDU set-level QoS handling is indicative of PDU set-level information; identifying, using processing circuitry of a session management function (SMF) of the 5G wireless communications network, the protocol description information; providing, using the SMF, the protocol description information to the UPF; identifying, using the UPF, a PSI of a detected downlink packet either based on matching the protocol description or based on metadata received by the UPF over an N6 interface of the 5G wireless communications network; encapsulating, using the UPF, the downlink packet in a general packet radio service tunneling protocol for user plane (GTP-U) header comprising the PDU set-level information and using transport level marking associated with the PSI of the downlink packet. Example 20 may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1-19, or any other method or process described herein. Example 21 may include an apparatus comprising logic, modules, and / or circuitry to perform one or more elements of a method described in or related to any of examples 1-19, or any other method or process described herein. Example 22 may include a method, technique, or process as described in or related to any of examples 1-19, or portions or parts thereof. Example 23 may include an apparatus comprising: one or more processors and one or more computer readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-19, or portions thereof. Example 24 may include a method of communicating in a wireless network as shown and described herein. Example 25 may include a system for providing wireless communication as shown and described herein. Example 26 may include a device for providing wireless communication as shown and described herein. Embodiments according to the disclosure are in particular disclosed in the attached claims directed to a method, a storage medium, a device and a computer program product, wherein any feature mentioned in one claim category, e.g., method, can be claimed in another claim category, e.g., system, as well. The dependencies or references back in the attached claims are chosen for formal reasons only. However, any subject matter resulting from a deliberate reference back to any previous claims (in particular multiple dependencies) can be claimed as well, so that any combination of claims and the features thereof are disclosed and can be claimed regardless of the dependencies chosen in the attached claims. The subject-matter which can be claimed comprises not only the combinations of features as Attorney Docket No.: AF7269-PCT (31517-3527) set out in the attached claims but also any other combination of features in the claims, wherein each feature mentioned in the claims can be combined with any other feature or combination of other features in the claims. Furthermore, any of the embodiments and features described or depicted herein can be claimed in a separate claim and / or in any combination with any embodiment or feature described or depicted herein or with any of the features of the attached claims. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments. Certain aspects of the disclosure are described above with reference to block and flow diagrams of systems, methods, apparatuses, and / or computer program products according to various implementations. It will be understood that one or more blocks of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and the flow diagrams, respectively, may be implemented by computer-executable program instructions. Likewise, some blocks of the block diagrams and flow diagrams may not necessarily need to be performed in the order presented, or may not necessarily need to be performed at all, according to some implementations. These computer-executable program instructions may be loaded onto a special-purpose computer or other particular machine, a processor, or other programmable data processing apparatus to produce a particular machine, such that the instructions that execute on the computer, processor, or other programmable data processing apparatus create means for implementing one or more functions specified in the flow diagram block or blocks. These computer program instructions may also be stored in a computer-readable storage media or memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage media produce an article of manufacture including instruction means that implement one or more functions specified in the flow diagram block or blocks. As an example, certain implementations may provide for a computer program product, comprising a computer-readable storage medium having a computer-readable program code or program instructions implemented therein, said computer-readable program code adapted to be executed to implement one or more functions specified in the flow diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational elements or steps to be performed on the computer or other programmable apparatus to produce a computer- implemented process such that the instructions that execute on the computer or other programmable apparatus provide elements or steps for implementing the functions specified in the flow diagram block or blocks. Accordingly, blocks of the block diagrams and flow diagrams support combinations of means for performing the specified functions, combinations of elements or steps for performing the specified functions and program instruction means for performing the specified functions. It will also be Attorney Docket No.: AF7269-PCT (31517-3527) understood that each block of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, may be implemented by special-purpose, hardware-based computer systems that perform the specified functions, elements or steps, or combinations of special-purpose hardware and computer instructions. Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain implementations could include, while other implementations do not include, certain features, elements, and / or operations. Thus, such conditional language is not generally intended to imply that features, elements, and / or operations are in any way required for one or more implementations or that one or more implementations necessarily include logic for deciding, with or without user input or prompting, whether these features, elements, and / or operations are included or are to be performed in any particular implementation. Many modifications and other implementations of the disclosure set forth herein will be apparent having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the disclosure is not to be limited to the specific implementations disclosed and that modifications and other implementations are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation. For the purposes of the present document, the following terms and definitions are applicable to the examples and embodiments discussed herein. The term “circuitry” as used herein refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and / or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable SoC), digital signal processors (DSPs), etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry. The term “processor circuitry” as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and / or transferring digital data. Processing circuitry may include one or more processing cores to execute instructions and one or more memory structures to store program and data information. The term “processor circuitry” may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual- Attorney Docket No.: AF7269-PCT (31517-3527) core processor, a triple-core processor, a quad-core processor, and / or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and / or functional processes. Processing circuitry may include more hardware accelerators, which may be microprocessors, programmable processing devices, or the like. The one or more hardware accelerators may include, for example, computer vision (CV) and / or deep learning (DL) accelerators. The terms “application circuitry” and / or “baseband circuitry” may be considered synonymous to, and may be referred to as, “processor circuitry.” The term “interface circuitry” as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, I / O interfaces, peripheral component interfaces, network interface cards, and / or the like. The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the term “user equipment” or “UE” may include any type of wireless / wired device or any computing device including a wireless communications interface. The term “network element” as used herein refers to physical or virtualized equipment and / or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to and / or referred to as a networked computer, networking hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, and / or the like. The term “computer system” as used herein refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” and / or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” and / or “system” may refer to multiple computer devices and / or multiple computing systems that are communicatively coupled with one another and configured to share computing and / or networking resources. The term “appliance,” “computer appliance,” or the like, as used herein refers to a computer device or computer system with program code (e.g., software or firmware) that is specifically designed to provide a specific computing resource. A “virtual appliance” is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or otherwise is dedicated to provide a specific computing resource. The term “resource” as used herein refers to a physical or virtual device, a physical or virtual component within a computing environment, and / or a physical or virtual component within a particular Attorney Docket No.: AF7269-PCT (31517-3527) device, such as computer devices, mechanical devices, memory space, processor / CPU time, processor / CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input / output operations, ports or network sockets, channel / link allocation, throughput, memory usage, storage, network, database and applications, workload units, and / or the like. A “hardware resource” may refer to compute, storage, and / or network resources provided by physical hardware element(s). A “virtualized resource” may refer to compute, storage, and / or network resources provided by virtualization infrastructure to an application, device, system, etc. The term “network resource” or “communication resource” may refer to resources that are accessible by computer devices / systems via a communications network. The term “system resources” may refer to any kind of shared entities to provide services, and may include computing and / or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable. The term “channel” as used herein refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with and / or equivalent to “communications channel,” “data communications channel,” “transmission channel,” “data transmission channel,” “access channel,” “data access channel,” “link,” “data link,” “carrier,” “radiofrequency carrier,” and / or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” as used herein refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information. The terms “instantiate,” “instantiation,” and the like as used herein refers to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code. The terms “coupled,” “communicatively coupled,” along with derivatives thereof are used herein. The term “coupled” may mean two or more elements are in direct physical or electrical contact with one another, may mean that two or more elements indirectly contact each other but still cooperate or interact with each other, and / or may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other. The term “directly coupled” may mean that two or more elements are in direct contact with one another. The term “communicatively coupled” may mean that two or more elements may be in contact with one another by a means of communication including through a wire or other interconnect connection, through a wireless communication channel or link, and / or the like. The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element, or a data element that contains content. Unless used differently herein, terms, definitions, and abbreviations may be consistent with terms, definitions, and abbreviations defined in 3GPP TR 21.905 v16.0.0 (2019-06) and / or any other Attorney Docket No.: AF7269-PCT (31517-3527) GPP standard. For the purposes of the present document, the following abbreviations (shown in Table) may apply to the examples and embodiments discussed herein.

[0006] Attorney Docket No.: AF7269-PCT (31517-3527) Table 2: Abbreviations 3GPP Third Generation IBE In-Band Emission PUSCH Physical Uplink Shared Partnership Project Channel 4G Fourth Generation IEEE Institute of Electrical QAM Quadrature Amplitude er e TI , st on rk e io p Attorney Docket No.: AF7269-PCT (31517-3527) BFD Beam Failure Detection ISO International RLC Radio Link Control, Organisation for Radio Link Control Standardisation layer ed ng el r er me g, Attorney Docket No.: AF7269-PCT (31517-3527) CIR Carrier to Interference LLC Logical Link Control, S1-MMES1 for the control plane Ratio Low Layer Compatibility k nt C p ol Attorney Docket No.: AF7269-PCT (31517-3527) CRI Channel-State Information MDAF Management Data SDNF Structured Data Resource Indicator, CSI- Analytics Function Storage Network RS Resource Indicator Function n me ce er ort t t ce Attorney Docket No.: AF7269-PCT (31517-3527) DN Data network MSI Minimum System SMTC SSB-based Information, MCH Measurement Timing Scheduling Configuration nal nal nal nal nal nal nal nal e o nal Attorney Docket No.: AF7269-PCT (31517-3527) EES Edge Enabler Server NFVO NFV Orchestrator SSSIF Search Space Set Indicator EESID Edge Enabler Server NG Next Generation, Next SST Slice / Service Types k up ty e tor x ple te Attorney Docket No.: AF7269-PCT (31517-3527) F1AP F1 Application Protocol NSSF Network Slice TPMI Transmitted Precoding Selection Function Matrix Indicator F1-C F1 Control plane interface NW Network TR Technical Report Attorney Docket No.: AF7269-PCT (31517-3527) G-RNTI GERAN Radio Network PDCP Packet Data URLLC Ultra-Reliable and Low Temporary Identity Convergence Protocol, Latency Packet Data rk ot n g er e- l ck Attorney Docket No.: AF7269-PCT (31517-3527) HPLMN Home Public Land Mobile PRG Physical resource WiMAX Worldwide Network block group Interoperability for Microwave Access n ea

Claims

Attorney Docket No.: AF7269-PCT (31517-3527) CLAIMS What is claimed is:

1. An apparatus of a Fifth Generation (5G) wireless communications network for supporting protocol data unit (PDU) set-level quality of service (QoS) handling, the apparatus comprising processing circuitry of an application function (AF), of a user plane function (UPF), and of a session management function (SMF), the processing circuitry coupled to storage for storing information associated with the PDU set-level QoS handling, the processing circuitry configured to: provide, by the AF, protocol description information for PDU set-level QoS handling to the UPF, wherein the PDU set-level QoS handling is indicative of PDU set- level information; identify, by the SMF, the protocol description information; provide, by the SMF, the protocol description information to the UPF; identify, by the UPF, a PSI of a detected downlink packet either based on matching the protocol description or based on metadata received by the UPF over an N6 interface of the 5G wireless communications network; and encapsulate, by the UPF, the downlink packet in a general packet radio service tunneling protocol for user plane (GTP-U) header comprising the PDU set-level information and using transport level marking associated with the PSI of the downlink packet.

2. The apparatus of claim 1, wherein the SMF provides a list of transport level markings to the UPF in a forward action rule (FAR), and wherein to identify the PSI is based on the transport level markings.

3. The apparatus of claim 1, wherein the SMF provides a list of transport level markings to the UPF in a QoS enforcement rule (QER), and wherein to identify the PSI is based on the transport level markings.

4. The apparatus of claim 1, wherein the UPF receives transport level markings over an N4 interface of the 5G wireless communications network, and wherein to identify the PSI is based on the transport level markings.Attorney Docket No.: AF7269-PCT (31517-3527) 5. The apparatus of claim 1, wherein the encapsulated downlink packet further comprises a transport header comprising a differentiated service point code (DSCP) value of the encapsulated downlink packet.

6. The apparatus of claim 1, wherein the UPF receives the protocol description information over an N4 interface of the 5G wireless communications network.

7. The apparatus of claim 1, wherein the SMF receives the protocol description information over an N7 interface of the 5G wireless communications network.

8. A computer-readable medium storing computer-executable instructions for supporting protocol data unit (PDU) set-level quality of service (QoS) handling, which when executed by one or more processors of an application function (AF), of a user plane function (UPF), and of a session management function (SMF) of a Fifth Generation (5G) wireless communications network, result in performing operations comprising: providing by the AF, protocol description information for PDU set-level QoS handling to the UPF, wherein the PDU set-level QoS handling is indicative of PDU set- level information; identifying, by the SMF, the protocol description information; providing, by the SMF, the protocol description information to the UPF; identifying, by the UPF, a PSI of a detected downlink packet either based on matching the protocol description or based on metadata received by the UPF over an N6 interface of the 5G wireless communications network; and encapsulating, by the UPF, the downlink packet in a general packet radio service tunneling protocol for user plane (GTP-U) header comprising the PDU set-level information and using transport level marking associated with the PSI of the downlink packet.

9. The computer-readable medium of claim 8, wherein the wherein the SMF provides a list of transport level markings to the UPF in a forward action rule (FAR), and wherein identifying the PSI is based on the transport level markings.

10. The computer-readable medium of claim 8, wherein the SMF provides a list of transport level markings to the UPF in a QoS enforcement rule (QER), and wherein identifying the PSI is based on the transport level markings.Attorney Docket No.: AF7269-PCT (31517-3527) 11. The computer-readable medium of claim 8, wherein the UPF receives transport level markings over an N4 interface of the 5G wireless communications network), and wherein identifying the PSI is based on the transport level markings.

12. The computer-readable medium of claim 8, wherein the encapsulated downlink packet further comprises a transport header comprising a differentiated service point code (DSCP) value of the encapsulated downlink packet.

13. The computer-readable medium of claim 8, wherein the UPF receives the protocol description information over an N4 interface of the 5G wireless communications network.

14. The computer-readable medium of claim 8, wherein the SMF receives the protocol description information over an N7 interface of the 5G wireless communications network.

15. A method for supporting protocol data unit (PDU) set-level quality of service (QoS) handling, the method comprising: receiving, by processing circuitry of an application function (AF) of a Fifth Generation (5G) wireless communications network, protocol description information for PDU set-level QoS handling to processing circuitry of a user plane function (UPF) of the 5G wireless communications network, wherein the PDU set-level QoS handling is indicative of PDU set- level information; identifying, by processing circuitry of a session management function (SMF) of the 5G wireless communications network, the protocol description information; providing, by the SMF, the protocol description information to the UPF; identifying, by the UPF, a PSI of a detected downlink packet either based on matching the protocol description or based on metadata received by the UPF over an N6 interface of the 5G wireless communications network; and encapsulating, by the UPF, the downlink packet in a general packet radio service tunneling protocol for user plane (GTP-U) header comprising the PDU set-level information and using transport level marking associated with the PSI of the downlink packet.

16. The method of claim 15, wherein the SMF provides a list of transport level markings to the UPF in a forward action rule (FAR), and wherein identifying the PSI is based on the transport level markings.Attorney Docket No.: AF7269-PCT (31517-3527) 17. The method of claim 15, wherein the SMF provides a list of transport level markings to the UPF in a QoS enforcement rule (QER), and wherein identifying the PSI is based on the transport level markings.

18. The method of claim 15, wherein the UPF receives transport level markings over an N4 interface of the 5G wireless communications network, and wherein identifying the PSI is based on the transport level markings.

19. A computer-readable storage medium comprising instructions to perform the method of any of claims 15-18.

20. An apparatus comprising means for performing the method of any of claims 15-18.

Images