New Metrics for Fairness and Latency Guarantees in the IAB Network

Abstract

The present disclosure relates to new metrics for fairness and delay assurance in an IAB network. Systems and methods for implementing various metrics in an integrated IAB network are disclosed. A child IAB node may determine metrics about one or more of its data streams and report these metrics to an upstream IAB node (i.e., a parent node and / or an IAB donor). The upstream node may use these metrics to determine a data stream prioritization configuration, which it either uses itself or sends back to the child IAB node or another IAB node of the IAB network for use herein. The metrics discussed include a hop count metric, an aggregate throughput metric per BH RLC channel ID (or per route ID), a fairness index metric per BH RLC channel ID (or per route ID), a packet drop metric, and a per-hop delay metric for aggregated traffic per BH RLC channel ID (or per route ID) per IAB node.

Description

Technical Field

[0001] The present application relates generally to wireless communication systems, including wireless communication systems that implement various metrics for integrated access and backhaul (IAB) networks. Background Art

[0002] Wireless mobile communication technology uses various standards and protocols to transmit data between base stations and wireless mobile devices. Wireless communication system standards and protocols may include the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) (e.g., 4G) or New Radio (NR) (e.g., 5G); the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, which is generally referred to as Worldwide Interoperability for Microwave Access (WiMAX) by industry organizations; and the IEEE 802.11 standard for wireless local area networks (WLANs), which is generally referred to as Wi-Fi by industry organizations. In the 3GPP radio access network (RAN) in the LTE system, the base station may include a RAN node such as an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as an evolved Node B, an enhanced Node B, an eNodeB, or an eNB) and / or a radio network controller (RNC) in the E-UTRAN, which communicates with a wireless communication device referred to as a user equipment (UE). In the fifth generation (5G) wireless RAN, the RAN nodes may include 5G nodes, NR nodes (also called next generation Node B or g NodeB (gNB)).

[0003] The RAN uses radio access technologies (RATs) to communicate between RAN nodes and UEs. The RAN may include a global system for mobile communications (GSM), an enhanced data rate for GSM evolution (EDGE) RAN (GERAN), a universal terrestrial radio access network (UTRAN), and / or an E-UTRAN, which provides access to communication services through a core network. Each RAN in the RAN operates according to a specific 3GPP RAT. For example, GERAN implements GSM and / or EDGE RAT, UTRAN implements Universal Mobile Telecommunications System (UMTS) RAT or other 3GPP RAT, E-UTRAN implements LTE RAT, and NG-RAN implements 5G RAT. In some deployments, E-UTRAN may also implement 5G RAT.

[0004] The frequency bands of 5G NR can be divided into two different frequency ranges. Frequency range 1 (FR1) may include frequency bands operating at frequencies below 6 GHz, some of which may be used by previous standards and may potentially be expanded to cover new spectrum products from 410 MHz to 7125 MHz. Frequency range 2 (FR2) may include frequency bands from 24.25 GHz to 52.6 GHz. The frequency bands in the millimeter wave (mmWave) range of FR2 may have a smaller range but potentially higher available bandwidth than the frequency bands in FR1. The skilled person will recognize that these frequency ranges, which are provided by way of example, may vary from time to time or region to region. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] To easily identify the discussion of any particular element or act, the most significant digit(s) in a reference number refers to the drawing number that first introduces the element.

[0006] Figure 1 An exemplary integrated access and backhaul (IAB) network of certain embodiments is shown.

[0007] Figure 2 An exemplary protocol architecture for IAB is shown according to one embodiment.

[0008] Figure 3 An IAB network is shown according to some embodiments.

[0009] Figure 4 A diagram is shown with a new protocol data unit (PDU) type ID for a Backhaul Adaptation Protocol (BAP) message that may be used to send one of these metrics, according to an embodiment.

[0010] Figure 5 A Hop Count BAP Control PDU for transmitting a hop count metric is shown according to an embodiment.

[0011] Figure 6 An aggregate throughput per backhaul (BH) radio link control (RLC) channel ID BAP control PDUs is shown for transmitting an aggregate throughput metric per BH RLC channel ID according to an embodiment.

[0012] Figure 7 The aggregate throughput of the per-route ID control PDUs used to transmit the aggregate throughput metric per-route ID is shown according to an embodiment.

[0013] Figure 8 A fairness index per BH RLC channel ID BAP control PDU is shown according to an embodiment, which is used to transmit the fairness index metric per BH RLC channel ID.

[0014] Fig. 9 A fairness index per route ID BAP control PDU is shown, according to an embodiment, which is used to transmit a fairness index metric per route ID.

[0015] Fig.10 A fairness index for a per-route-ID packet discard BAP control PDU, which is used to transmit packet discard metrics, is shown according to an embodiment.

[0016] Fig.11 The per-hop delay of the aggregated traffic per BH RLC channel ID per IAB node BAP control PDU is shown according to an embodiment, which is used to transmit the per-hop delay metric of the aggregated traffic per BH RLC channel ID per IAB node.

[0017] Fig.12 The per-hop delay of aggregate traffic per routing ID per BAP control PDU per IAB node is shown, which is used to transmit the per-hop delay metric of aggregate traffic per routing ID per IAB node according to an embodiment.

[0018] Fig.13 A method of an IAB node of a wireless communication system according to an embodiment is shown.

[0019] Fig.14 A method of a donor IAB node of a wireless communication system according to an embodiment is shown.

[0020] Fig.15 A method of a sub IAB node of a wireless communication system according to an embodiment is shown.

[0021] Fig.16 A UE according to one embodiment is shown.

[0022] Fig.17 A network node according to one embodiment is shown.

[0023] Fig.18 An exemplary service-based architecture is shown in accordance with certain embodiments.

[0024] Fig.19 An NG-RAN architecture according to one embodiment is shown.

[0025] Fig. 20 Components according to one embodiment are shown. DETAILED DESCRIPTION

[0026] Millimeter wave (mmWave) deployments of wireless networks may use fiber backhaul to carry traffic at NR speeds. However, it may be difficult or expensive to provide fiber backhaul to many nodes for mmWave coverage. In some systems, integrated access and backhaul (IAB) can be used to overcome the deployment costs of ultra-dense NR mmWave networks by implementing wireless backhaul links for relaying access traffic.

[0027] The IAB architecture enables multi-hop routing, where the IAB node acts as an access node for the UE and provides backhaul (BH) links to other IAB nodes. On the wireless backhaul, the IP layer is carried on the backhaul adaptation protocol (BAP) sublayer, which enables multi-hop routing. The BAP allows the IAB nodes to communicate with each other and provides multiple functions, including, for example, mapping of the next-hop radio link control (RLC) channel, routing to the next-hop IAB node (both child and parent nodes) based on traffic differentiation, indication of network events (e.g., radio link failure (RLF)), data transmission and / or flow control feedback signaling.

[0028] On each backhaul link, the BAP protocol data unit (PDU) is carried by a BH RLC channel. Multiple BH RLC channels can be configured on each BH link to allow traffic prioritization and quality of service (QoS) enforcement. BH-RLC-channel mapping of BAP PDUs is performed by the BAP entity and the IAB donor data unit (DU) on each IAB node. In some systems, the RLC channel mapping can be accomplished by a radio resource control (RRC) reconfiguration message from the donor control unit (CU) to each individual node. In some specific implementations of the BH RLC channel establishment, a separate RRC reconfiguration message is used to ensure that the setup is completed hop by hop until the final destination (at the UE).

[0029] Figure 1An exemplary IAB network 100 of certain embodiments is shown. The IAB network 100 includes an IAB donor 102 having a fiber backhaul connection to a 5G core network (5GC) 104 (e.g., via an NG interface). In this example, the IAB network 100 also has an IAB node 106 (shown as an IAB node 1-1), an IAB node 108 (shown as an IAB node 2-1), and an IAB node 110 (shown as an IAB node 3-1), but any number of IAB nodes or frequency hopping may be used to establish a connection between a UE 112 and a 5GC 104. The IAB node 110 establishes communication between the UE 112 and the 5GC 104 using a wireless backhaul (e.g., using an NR-Uu interface). A skilled person will recognize from the disclosure herein that any IAB node may also provide communication for other UEs. For example, an IAB node 106 may establish communication between a UE 114 and a 5GC 104. It is contemplated that an IAB Contributor may, in at least some circumstances, also properly be considered an IAB Node, as that term is used herein (eg, in the context of its relationship to its immediate child IAB nodes).

[0030] The IAB donor 102 (which may also be referred to as a backend node) includes a DU 116 and a CU 118. Although shown as a single unit, the DU 116 of the IAB donor 102 may include two or more DUs. The IAB node 106, the IAB node 108, and the IAB node 110 may be referred to as intermediate nodes, subnodes, or relay nodes, and each includes two subcomponents: a DU and a mobile terminal (MT). The CU generally provides basic control plane functions. In some embodiments, the CU includes a CU control plane (CU-CP), a CU user plane (CU-UP), and / or other functions.

[0031] MT includes components that configure a network node (e.g., gNB) to behave similarly to a conventional UE. For example, the protocols that a typical UE uses to connect to the network are supported in MT, with additional enhancements discussed in 3GPP Rel.16 and Rel.17. For example, the MT in the IAB node 108 allows the IAB node 108 to establish a signaling radio bearer (SRB) and / or a data radio bearer (DRB) with its parent node (IAB node 106). The MT performs cell selection to identify the parent node to join, and establishes and uses RLC through the BAP layer, which carries the function of routing data through the network via different routes for different UEs.

[0032] Figure 2An exemplary protocol architecture for IAB 200 according to one embodiment is shown. The exemplary protocol architecture for IAB 200 shows the various protocol layers of UE 202, first IAB node 208 (IAB node 1), second IAB node 204 (IAB node 2), and IAB donor 206. The various layers may correspond to mobile terminal (MT), distributed unit (DU) or centralized unit (CU)-user plane (UP) entities. The DU and CU-UP of IAB donor 206 can communicate through the F1-U interface within the donor. In this example, UE 202 communicates wirelessly with the second IAB node 204 through the dedicated radio bearer (DRB) of the UE, and the second IAB node 204 wirelessly relays uplink traffic to the first IAB node 208 through the backhaul (BH) radio link control (RLC) channel. The protocol layers include, for example, Medium Access Control (MAC), RLC, Packet Data Convergence Protocol (PDCP), Service Data Adaptation Protocol (SDAP), Internet Protocol (IP), User Datagram Protocol (UDP), and General Packet Radio Service (GPRS) Tunneling Protocol-User Plane (GTP-U).

[0033] The exemplary protocol architecture for IAB 200 also includes a backhaul adaptation protocol (BAP) layer that provides the functionality to route data through the network via different routes for different UE bearers. This can be accomplished by having an adaptation layer header that includes some information for identifying the bearer. The routing includes mapping incoming data to outgoing links based on the bearer identifier.

[0034] Given that different UE bearers may be carried on different routes through the network, in certain embodiments the buffer occupancy status generated by a node may only be relevant to the bearers routed through the node and the IAB nodes on those routes.

[0035] The data stream may include one or more BAP PDUs having the same BH RLC channel ID and sent over time on the BH link between the first entity and the second entity. In some embodiments, it is contemplated that the IAB node may merge or combine multiple incoming data streams into a single outgoing data stream.

[0036] One consideration in developing wireless communication systems using IAB is fairness among the various data flows. In an IAB topology, some UEs are farther from the IAB donor / 5GC than other UEs (see e.g. Figure 1, where UE 112 is further hops away from IAB donor 102 / 5GC 104 than UE 114). Therefore, it may be desirable to have a mechanism for ensuring that UE 112 can receive QoS treatment for one or more of its data flows that is similar (in effect) to the QoS treatment it would receive if connected to, for example, a gNB of a wireless communication system (without passing through IAB network 100). Also of interest is a mechanism for preventing data flows of UE 114 from being unfairly favored relative to data flows of UE 112 due to UE 114's closer proximity (in hop distance) to IAB donor 102 / 5GC 104.

[0037] Another aspect of fairness of the entire IAB network may be to prevent starvation of best effort (BE) PDU flows associated with any QoS PDU flow in the IAB network. It may also be beneficial to have a mechanism to ensure that a BE UE / data flow that is closer to the IAB donor is not penalized in order to maintain the QoS requirements of another UE / data flow that may be further away (in hop count) from the IAB donor.

[0038] Another aspect of fairness of the entire IAB network may be to ensure that QoS requirements of two UEs can be maintained where each UE has joined the IAB network by a different IAB node and has the same / similar signaling conditions, regardless of the number of hops either of the UEs is from the IAB donor.

[0039] Another aspect of fairness of the entire IAB network may be to ensure that grants are distributed to various IAB nodes using a weighted fair queuing mechanism based on the data transfer requirements of various flows within the IAB network rather than based on parent-child node dynamics such as between IAB nodes in the IAB network.

[0040] It is envisioned that possible solutions to satisfy these considerations may impact at least three areas. First, any adaptive routing functionality within the IAB network may be implicated by control of any of these aspects. In other words, the ability of the IAB network to reroute data flows due to, for example, congestion and / or signaling conditions may be affected.

[0041] Second, any local metric calculation and evaluation functionality that allows for better reactive decision making at a non-centralized controller may be implicated by control of these aspects. This may include, for example, determinations related to latency, fairness, and / or congestion. Depending on the nature of the solution chosen, more or less of these local calculations may be used. Such local calculations may result in prioritization of data flows at a local node (e.g., an IAB node, not necessarily an IAB donor), which is then sent to its child IAB nodes.

[0042] Again, any centralized decision making function within the IAB network may be implicated by control of any of these aspects. Any solution to control the above aspects may rely to a greater or lesser extent on centralized decision making (e.g., from IAB Donors to IAB Nodes) functions within the IAB network.

[0043] The selected solution may not provide UEs with advantages over what they would enjoy in a single hop network scenario. Furthermore, the selected solution may be adapted to ensure that UEs closer to the IAB donor than the second UE are not overly penalized in order to provide a certain level of service to the second UE.

[0044] One or more metrics may be used within the IAB network to develop solutions as discussed herein. These metrics may allow an IAB node or CU receiving such metrics to ensure that one or more of fairness goals, delay goals, and / or congestion reduction goals are met.

[0045] Current metrics available within a wireless communication system (prior to the introduction of those discussed herein) may currently exist in each gNB. Therefore, the wireless communication system should be adapted to use metrics at individual IAB nodes (which may currently be handled using UE procedures). Furthermore, current metrics may be on a per-DRB, per-UE basis, which is not suitable for use with many-to-one (N:1) BH RLC mappings at a single IAB. Load, delay, and packet loss may all exist, including random access channel (RACH) level metrics, so using a similar framework in an inclusive manner may be very useful. Furthermore, such current metrics may only be communicated to an IAB donor and / or by an IAB donor to an IAB node.

[0046] Therefore, the additional metrics proposed herein may relate to metrics related to QoS and / or Packet Delay Budget (PDB) management at intermediate IAB nodes in order to address issues introduced due to potential multi-hopping issues related to the use of IAB networks.

[0047] The IAB node may determine one or more metrics based on its data flows. In addition, these metrics may then be communicated to the parent IAB node, for example in BAP layer communications, so as to enable the parent IAB node to take actions to ensure that fairness / delay / congestion targets are met with respect to those flows. In some cases, the parent IAB node may use these metrics to determine data flow prioritization configurations (either for itself or for child IAB nodes, in which case it may send the data flow prioritization configurations to the child IAB nodes).

[0048] Alternatively or additionally, these metrics may be communicated to the CU of the IAB Donor in F1AP communications or subsequent BAP layer communications, enabling the IAB Donor to take actions to ensure that fairness / delay / congestion targets are met with respect to those flows. In some cases, the IAB Donor may use these metrics to determine data flow prioritization configurations (for itself or for a descendant IAB node or another IAB node in the IAB network, in which case it may send the data flow prioritization configurations to the relevant IAB nodes).

[0049] Figure 3 An IAB network 300 according to some embodiments is shown. The IAB network 300 includes a first UE 302, a second UE 304, and a third UE 306, a first IAB node 308, a second IAB node 310, and a third IAB node 312, an IAB donor 314, and a 5GC 316. The first UE 302 is connected to the first IAB node 308 on a first BH link 318. The first IAB node 308 is connected to the third IAB node 312 on a second BH link 320. The second IAB node 310 is connected to the third IAB node 312 on a third BH link 322. The second UE 304 is connected to the third IAB node 312 on a fourth BH link 324. The third IAB node 312 is connected to the IAB donor 314 on one or both of the fifth BH link 326 and / or the sixth BH link 328. The third UE 306 is connected to the IAB donor 314 on a seventh BH link 330. Finally, the IAB donor 314 is connected to the 5GC 316 over the fiber BH 332. Figure 3 The IAB nodes may transmit data streams between each other using a one-to-one (1:1) RLC channel mapping, or they may transmit data streams between each other using an N:1 RLC channel mapping.

[0050] The IAB network 300 can be used to illustrate a number of potential problems that can be addressed by introducing the use of various new metrics into the IAB network 300. These problems may result in the IAB system being unfair in providing services to all users in the manner described above. Due to the multi-hop nature of the IAB network, these problems may result in the inability to guarantee the end-to-end (E2E) delay requirements for UE outgoing data flows.

[0051] In a first example, an IAB node (e.g., the third IAB node 312) may not have all the system centralized information needed to make appropriate decisions about its incoming data flows. This may include, for example, the number of hops to the destination, how many QoS UEs / data flows are aggregated into the incoming data flow, and how many BE UEs / data flows are aggregated into the incoming data flow, the aggregate BH RLC channel rate, etc. Because it lacks this information, the third IAB node 312 may not realize that it should, for example, prioritize the incoming data flow because it has a larger number of hops to the destination, prioritize the incoming data flow from the first IAB node 308, which aggregates many UE VoIP data flows on a single VoIP incoming data flow from the second UE 304, so that equal treatment of all UE VoIP data flows is achieved, etc. All of this centralized information may instead be at the CU of the IAB donor 314, which may not have the most accurate information about downstream nodes (such as the child nodes (the first IAB node 308 and the second IAB node 310) of the third IAB node 312) in any case.

[0052] In a second example, an IAB node (e.g., the third IAB node 312) may not include a prioritization scheme to prioritize packets that cause additional delays and / or violate PDBs, making it impossible to meet the QoS of the data flow. Because it lacks such a capability, such packets may not be prioritized relative to other packets to allow QoS to be met. In some cases, this may mean that the third IAB node 312 does not have a prioritization scheme to prioritize, for example, traffic corresponding to a larger hop distance relative to other traffic.

[0053] In a third example, an IAB node (e.g., the third IAB node 312) may not have a mechanism to request additional resources for a BH RLC flow that must carry a relatively large number of aggregated individual UE data flows. This may occur, for example, in situations where the child IAB nodes do not have balanced usage (e.g., where the first IAB node 308 is located in an office and therefore sees high traffic during working hours, while the second IAB node 310 is located in a residential area and therefore sees relatively low traffic during working hours).

[0054] In a fourth example, an IAB node (e.g., the third IAB node 312) may not have the remaining PDB information for the current packet flow. In other words, there is no information that would allow the third IAB node 312 to recognize that adjustments should be made in order to maintain the QoS of the current data flow. In this case, the third IAB node 312 may also not be aware of the delay of the IAB donor 314, which may help the third IAB node 312 ensure that any / some remaining PDBs can be used to deliver packets.

[0055] In a fifth example, an IAB node (e.g., the third IAB node 312) may not have a way to reduce traffic buffer overload that may cause additional delay accumulation, nor a mechanism for cleaning up traffic that may not meet the required QoS (e.g., required delay and / or PDB criteria). In other words, there is no packet drop mechanism at the third IAB node 312. This may mean that packets that may be dropped at upstream entities of the IAB network continue to be sent by the third IAB node 312 to the IAB donor 314 (despite this possibility), where it may be preferred to drop such packets at the third IAB node 312 in order to save those transmission resources. In addition, in the event of an overload on certain logical channels (LCHs), there is no mechanism for reporting a single buffer status to the CU.

[0056] The addition of various metrics to be used in the IAB network may allow the above-mentioned problems to be solved. These metrics may include: a hop count metric, an aggregate throughput metric per BH RLC channel ID, an aggregate throughput metric per route ID, a fairness index metric per BH RLC channel ID, a fairness index metric per route ID, a packet drop metric, a per-hop delay metric for aggregated traffic per BH RLC channel ID per IAB node, and a per-hop delay metric for aggregated traffic per route ID per IAB node.

[0057] As previously discussed, it is contemplated that one or more of these metrics may be sent from the IAB node to the parent IAB / received at the IAB node from the parent IAB node (as the case may be) using BAP PDU signaling. In some embodiments, the receiving IAB node may use the information found directly in the received metrics, and / or the information may then be further relayed to the IAB donor via additional BAP signaling. It is also contemplated that one or more of these metrics may instead be sent directly to / received from the IAB donor using the F1AP interface between the IAB node and the IAB donor. Using F1AP in this manner may be more centralized than using BAP signaling, since the IAB donor will be used to receive all such messages and relay them from their source IAB node to their destination IAB node.

[0058] Figure 4A diagram 400 is shown with a new PDU type ID for a BAP message that can be used to send one of these metrics, according to an embodiment. As will be described, the PDU type IDs can be represented in binary because they will be placed in the BAP PDU. As shown, the hop count metric (hop count) can correspond to a hop count BAP control PDU using a PDU type ID of 100. The aggregate throughput metric per BH RLC channel ID can correspond to the aggregate throughput per BH RLC channel ID BAP control PDU using a PDU type ID of 101. The aggregate throughput metric per route ID can correspond to the aggregate throughput per route ID BAP control PDU using a PDU type ID of 110. The fairness index metric per BH RLC channel ID can correspond to the fairness index per BH RLC channel ID BAP control PDU using a PDU type ID of 111. The fairness index metric per route ID can correspond to the fairness index per route ID BAP control PDU using a PDU type ID of 1000. The packet drop metric (purposeful packet drop) may correspond to a packet drop BAP control PDU using a PDU type ID of 1001. The per-hop delay metric for aggregated traffic per BH RLC channel ID per IAB node may correspond to the per-hop delay for aggregated traffic per BH RLC channel ID per IAB node BAP control PDU using a PDU type ID of 1010. The per-hop delay metric for aggregated traffic per route ID per IAB node may correspond to the per-hop delay for aggregated traffic per route ID per IAB node BAP control PDU using a PDU type ID of 1011. PDU type IDs 1100-1111 may remain reserved.

[0059] A hop count metric corresponding to one or more data flows at a downstream IAB node may be received. Multiple hop count metrics may provide an indirect way to estimate latency and / or provide prioritization information of CUs from an IAB donor to the UE as needed. The implementation of the metric may be based on a counter mechanism that increments each time a new hop is reached (e.g., each time a new IAB node is reached). Once the IAB donor is reached, the counter may stop incrementing.

[0060] An integer increment of the hop count may be verified. This may involve converting the BAP message to an acknowledgement based mechanism or by introducing a timestamp into the BAP header.

[0061] Figure 5A hop count BAP control PDU 500 for transmitting hop count metrics according to an embodiment is shown. As shown, the hop count BAP control PDU 500 includes a D / C bit for indicating whether the hop count BAP control PDU 500 is a control PDU or a data PDU (in some cases, for a control PDU, the D / C bit may be set to 0 for control).

[0062] The Hop Count BAP Control PDU 500 also includes a PDU Type field. The appropriate PDU Type ID (100) of the Hop Count BAP Control PDU 500 may be inserted into this field.

[0063] The Hop Count BAP Control PDU 500 also includes a Source field that provides a source address for the corresponding Hop Count BAP Control PDU 500 .

[0064] Hop Count The BAP Control PDU 500 also includes a Hop Count field, which carries the current hop count to the parent IAB node.

[0065] As shown, the hop count BAP control PDU 500 also includes various reserved bits (labeled "R"). This can help facilitate octet alignment within the hop count BAP control PDU 500 between the various data fields in the manner shown. In some embodiments, the hop count BAP control PDU is sent without the reserved bits (and the various data fields are adjusted to fit adjacently by ignoring any octet alignment considerations). In these embodiments, such a hop count BAP control PDU can use fewer resources (bits) than the hop count BAP control PDU 500.

[0066] An aggregate throughput metric per BH RLC channel ID and / or an aggregate throughput metric per route ID may be received, which corresponds to one or more data flows at a downstream IAB node. The aggregate throughput metric per BH RLC channel ID or the aggregate throughput metric per route ID may allow the CU of the IAB donor to know the amount of traffic carried by each IAB node. It may also allow the IAB node receiving such metrics to come up with its own solution to re-adjust the priority of flows based on the authorized availability of child IAB nodes, rather than relying solely on the recommendation of the CU of the IAB donor. This may promote a more responsive IAB network.

[0067] In these cases, in order to track the IAB node where data flow aggregation occurs, it may be helpful to also make 5G QoS Identifier (5QI) information available (e.g., in scenarios where multiple UEs are in far cell conditions corresponding to related BH RLC flows).

[0068] Implementation of an aggregate throughput metric per BH RLC channel ID or per route ID may involve calculating the number of RLC service data unit (SDU) bytes transmitted divided by the number of acknowledgments corresponding to those RLC SDUs (per BH RLC channel ID or per route ID, as appropriate).

[0069] Figure 6 The aggregate throughput of the BAP control PDU 600 per BH RLC channel ID, which is used to transmit the aggregate throughput metric per BH RLC channel ID, is shown according to an embodiment. As shown, the aggregate throughput of the BAP control PDU 600 per BH RLC channel ID includes a D / C bit, which is used to indicate whether the aggregate throughput of the BAP control PDU 600 per BH RLC channel ID is a control PDU or a data PDU (in some cases, for a control PDU, the D / C bit can be set to 0 for control).

[0070] The aggregate throughput per BH RLC channel ID BAP control PDU 600 also includes a PDU type field. The appropriate PDU type ID (101) of the aggregate throughput per BH RLC channel ID BAP control PDU 600 may be inserted into this field.

[0071] The aggregate throughput per BH RLC channel ID BAP control PDU 600 also includes one or more BH RLC channel ID fields that identify one or more BH RLC channels for which the aggregate throughput metric per BH RLC channel ID is being sent.

[0072] The aggregate throughput per BH RLC channel ID BAP control PDU 600 also includes one or more aggregate throughput fields that relate to the aggregate throughput metric per BH RLC channel ID itself for the corresponding BH RLC channel ID, as shown.

[0073] As shown, the aggregate throughput per BH RLC channel ID BAP control PDU 600 also includes various reserved bits (marked "R"). This can help facilitate octet alignment within the aggregate throughput per BH RLC channel ID BAP control PDU 600 between the various data fields in the manner shown. In some embodiments, the aggregate throughput per BH RLC channel ID BAP control PDU is sent without the reserved bits (and the various data fields are adjusted to fit adjacently by ignoring any octet alignment considerations). In these embodiments, such aggregate throughput per BH RLC channel ID BAP control PDU can use fewer resources (bits) than the aggregate throughput per BH RLC channel ID BAP control PDU 600.

[0074] Figure 7 The aggregate throughput of the per-route ID BAP control PDU 700, which is used to transmit the aggregate throughput metric per route ID, is shown according to an embodiment. As shown, the aggregate throughput of the per-route ID BAP control PDU 700 includes a D / C bit, which is used to indicate whether the aggregate throughput of the per-route ID BAP control PDU 700 is a control PDU or a data PDU (in some cases, for a control PDU, the D / C bit can be set to 0 for control).

[0075] The aggregate throughput per route ID BAP control PDU 700 also includes a PDU type field. The appropriate PDU type ID (110) of the aggregate throughput per route ID BAP control PDU 700 may be inserted into this field.

[0076] The aggregate throughput per route ID BAP control PDU 700 also includes one or more route ID fields that identify the one or more route IDs for which the aggregate throughput per route ID metric is being sent.

[0077] The aggregate throughput per route ID BAP control PDU 700 also includes one or more aggregate throughput fields that relate to the aggregate throughput metric per route ID itself for the corresponding route ID, as shown.

[0078] As shown, the aggregate throughput of the per-route ID BAP control PDU 700 also includes various reserved bits (labeled "R"). This can help facilitate octet alignment within the aggregate throughput of the per-route ID BAP control PDU 700 between the various data fields in the manner shown. In some embodiments, the aggregate throughput of the per-route ID BAP control PDU is sent without the reserved bits (and the various data fields are adjusted to fit adjacently by ignoring any octet alignment considerations). In these embodiments, such aggregate throughput of the per-route ID BAP control PDU may use fewer resources (bits) than the aggregate throughput of the per-route ID BAP control PDU 700.

[0079] The fairness index metric per BH RLC channel ID or per route ID can be calculated at the CU of the IAB donor, which can indicate to the IAB node (the percentage of duration that the IAB donor communicates with the IAB node) that the IAB node should allow packets of different LCIDs to flow from a global perspective.

[0080] The fairness index metric per BH RLC channel ID or the fairness index metric per route ID is calculated based on the current rate conditions at the IAB node for various BH RLC channel IDs or various route IDs (as the case may be). The index can be calculated using, for example, the aggregate throughput metric per BH RLC channel ID or the aggregate throughput metric per route ID received from the IAB node in question at the CU of the IAB donor.

[0081] For an IAB node that has been configured with any type of fairness index by the CU, any changes made by the IAB node to the mode of the configured fairness index should be reported back to the CU.

[0082] Figure 8 A fairness index per BH RLC channel ID BAP control PDU 800 is shown for transmitting a fairness index metric per BH RLC channel ID according to an embodiment. As shown, the fairness index per BH RLC channel ID BAP control PDU 800 includes a D / C bit for indicating whether the fairness index per BH RLC channel ID BAP control PDU 800 is a control PDU or a data PDU (in some cases, for a control PDU, the D / C bit may be set to 0 for control).

[0083] The fairness index per BH RLC channel ID BAP control PDU 800 also includes a PDU type field. The appropriate PDU type ID (111) of the fairness index per BH RLC channel ID BAP control PDU 800 may be inserted into this field.

[0084] The fairness index per BH RLC channel ID BAP control PDU 800 also includes one or more BH RLC channel ID fields that identify one or more BH RLC channels for which the fairness index metric per BH RLC channel ID is being sent.

[0085] The fairness index per BH RLC channel ID BAP control PDU 800 also includes one or more fairness index fields that relate to the fairness index metric per BH RLC channel ID itself for the corresponding BH RLC channel, as shown.

[0086] As shown, the fairness index per BH RLC channel ID BAP control PDU 800 also includes various reserved bits (marked "R"). This can help facilitate octet alignment within the aggregate fairness index per BH RLC channel ID BAP control PDU 800 between the various data fields in the manner shown. In some embodiments, the fairness index per BH RLC channel ID BAP control PDU is sent without the reserved bits (and the various data fields are adjusted to fit adjacently by ignoring any octet alignment considerations). In these embodiments, such fairness index per BH RLC channel ID BAP control PDU can use fewer resources (bits) than the fairness index per BH RLC channel ID BAP control PDU 800.

[0087] Fig. 9 A fairness index per route ID BAP control PDU 900 is shown for transmitting a fairness index metric per route ID according to an embodiment. As shown, the fairness index per route ID BAP control PDU 900 includes a D / C bit for indicating whether the fairness index per route ID BAP control PDU 900 is a control PDU or a data PDU (in some cases, for a control PDU, the D / C bit may be set to 0 for control).

[0088] The fairness index per route ID BAP control PDU 900 also includes a PDU type field. The appropriate PDU type ID (1000) of the fairness index per route ID BAP control PDU 900 may be inserted into this field.

[0089] The fairness index per route ID BAP control PDU 900 also includes one or more route ID fields that identify the one or more route IDs for which the fairness index metric per route ID is being sent.

[0090] The fairness index per route ID BAP control PDU 900 also includes one or more fairness index fields that relate to the fairness index metric per route ID itself for the corresponding route ID, as shown.

[0091] As shown, the fairness index of the per-route ID BAP control PDU 900 also includes various reserved bits (labeled "R"). This can help facilitate octet alignment within the aggregate fairness index of the per-route ID BAP control PDU 900 between the various data fields in the manner shown. In some embodiments, the fairness index of the per-route ID BAP control PDU is sent without the reserved bits (and the various data fields are adjusted to fit adjacently by ignoring any octet alignment considerations). In these embodiments, such fairness index of the per-route ID BAP control PDU can use fewer resources (bits) than the fairness index of the per-route ID BAP control PDU 900.

[0092] Packet drop metrics may be determined at the CU and may be transmitted to the IAB node to instruct it to drop certain packets. The use of packet drop metrics as described herein may allow tracking of packet drops that exceed conventional targets maintained using an active queue management (AQM) scheme. This may ensure that multi-hop flows of the IAB network may still meet QoS requirements.

[0093] The CU of the IAB donor may receive from the 5GC how to maintain UE QoS in terms of packet loss rate (PLR). Using this information and based on one or more of, for example, per-hop delay metrics for aggregated traffic per routing ID per IAB node and / or per-hop delay metrics for aggregated traffic per BHRLC channel ID per IAB node (described below, respectively), in the case of N:1 mapping of the sub-IAB or mapping using 38.314 and packet error rates at different hops using 38.314, the CU may determine a relative list of packets to be dropped at a particular hop.

[0094] Fig.10A fairness index of a per-route ID packet discard BAP control PDU 1000, which is used to transmit packet discard metrics, is shown according to an embodiment. As shown, the packet discard BAP control PDU 1000 includes a D / C bit, which is used to indicate whether the packet discard BAP control PDU 1000 is a control PDU or a data PDU (in some cases, for a control PDU, the D / C bit can be set to 0 for control).

[0095] The Packet Drop BAP Control PDU 1000 also includes a PDU Type field. The appropriate PDU Type ID (1001) of the Packet Drop BAP Control PDU 1000 may be inserted into this field.

[0096] The Packet Drop BAP Control PDU 1000 also includes a destination field indicating the sub-IAB that should implement the indicated packet drop. The destination field may be used by intermediate IAB nodes for routing purposes.

[0097] The Packet Discard BAP Control PDU 1000 also includes a Sequence Number (SN)-Start field, which indicates the starting sequence number of the packets to be discarded. This field may have been taken from the RLC layer.

[0098] The Packet Discard BAP Control PDU 1000 also includes a Sequence Number (SN)-End field, which indicates the ending sequence number of the packet to be discarded. This field may have been taken from the RLC layer.

[0099] The Packet Discard BAP Control PDU 1000 also includes a SO-End field, which is used to identify the packet to be discarded in case of segmentation at the RLC layer. This field may have been taken from the RLC layer.

[0100] The Packet Drop BAP Control PDU 1000 also includes a BH RLC Channel ID field, which indicates the applicable BR RLC channel ID to which the packet drop instruction should apply.

[0101] As shown, the Packet Drop BAP Control PDU 1000 also includes various reserved bits (labeled "R"). This can help facilitate octet alignment within the Packet Drop BAP Control PDU 1000 between the various data fields in the manner shown. In some embodiments, the Packet Drop BAP Control PDU is sent without the reserved bits (and the various data fields are adjusted to fit adjacently by ignoring any octet alignment considerations). In these embodiments, such a Packet Drop BAP Control PDU can use fewer resources (bits) than the Packet Drop BAP Control PDU 1000.

[0102] A per-hop delay metric for aggregated traffic per BH RLC channel ID per IAB node and / or a per-hop delay metric for aggregated traffic per route ID per IAB node may be received, corresponding to one or more data flows at a downstream IAB node. The per-hop delay metric for aggregated traffic per BH RLC channel ID per IAB node and / or the per-hop delay metric for aggregated traffic per BH RLC channel ID per IAB node may give a direct relationship to the available delay budget per hop for the CU when combined with the hop count metric. The metric may also be calculated at the IAB node, which may allow for further IAB node optimization.

[0103] One way to implement the per-hop delay metric for aggregated traffic per BH RLC channel ID per IAB node and / or the per-hop delay metric for aggregated traffic per route ID per IAB node can be the user system frame number (SFN) or subframe number from sender to receiver as a timestamp. Such SFN and / or subframe number can be implemented in a relative manner, where the first IAB node can start the clock at zero.

[0104] Another way to implement per-hop delay metrics for aggregated traffic per BH RLC channel ID per IAB node and / or per-hop delay metrics for aggregated traffic per route ID per IAB node may be to add timestamps to random packets selected from different BH RLC channels in the IAB network topology. The granularity of such calculations may be handled by the CU of the IAB donor.

[0105] Fig.11 The per-hop delay of the aggregated traffic per BH RLC channel ID of each IAB node BAP control PDU 1100 according to the implementation scheme is shown, and the per-hop delay is used to transmit the per-hop delay metric of the aggregated traffic per BH RLC channel ID of each IAB node. As shown in the figure, the per-hop delay of the aggregated traffic per BH RLC channel ID of each IAB node BAP control PDU 1100 includes a D / C bit, which is used to indicate whether the per-hop delay of the aggregated traffic per BH RLC channel ID of each IAB node BAP control PDU 1100 is a control PDU or a data PDU (in some cases, for the control PDU, the D / C bit can be set to 0 for control).

[0106] The per-hop delay of aggregated traffic per BH RLC channel ID per IAB Node BAP control PDU 1100 also includes a PDU type field. An appropriate PDU type ID (1010) of the per-hop delay of aggregated traffic per BH RLC channel ID per IAB Node BAP control PDU 1100 may be inserted into this field.

[0107] The per-hop delay of the aggregated traffic per BH RLC channel ID per IAB node BAP control PDU 1100 also includes one or more path IDs (BH RLC channel ID field), which identify one or more paths (BH RLC channels) for which the per-hop delay metric of the aggregated traffic per BH RLC channel ID per IAB node is being transmitted.

[0108] The per-hop delay of aggregated traffic per BH RLC channel ID per IAB node BAP control PDU 1100 also includes one or more hop delay indices that relate to the delay index (per IAB node) itself for the corresponding path (BH RLC channel), as shown (which together may represent a per-hop delay metric for aggregated traffic per BH RLC channel ID per IAB node). These may be the number necessary to represent all necessary frequency hops (and may accordingly increase in number as the per-hop delay of aggregated traffic per BH RLC channel ID per IAB node BAP control PDU 1100 hops across IAB nodes of the system).

[0109] As shown, the per-hop delay of the aggregated traffic per BH RLC channel ID per IAB Node BAP control PDU 1100 includes various reserved bits (marked as "R"). This can help facilitate octet alignment within the per-hop delay of the aggregated traffic per BH RLC channel ID per IAB Node BAP control PDU 1100 between the various data fields in the manner shown. In some embodiments, the per-hop delay of the aggregated traffic per BH RLC channel ID per IAB Node BAP control PDU is sent without the reserved bits (and the various data fields are adjusted to fit adjacently by ignoring any octet alignment considerations). In these embodiments, such per-hop delay of the aggregated traffic per BH RLC channel ID per IAB Node BAP control PDU can use fewer resources (bits) than the per-hop delay of the aggregated traffic per BH RLC channel ID per IAB Node BAP control PDU 1100.

[0110] Fig.12The per-hop delay of the aggregated traffic per routing ID of each IAB node BAP control PDU 1200 according to the embodiment is shown, and the per-hop delay is used to transmit the per-hop delay metric of the aggregated traffic per routing ID of each IAB node. As shown in the figure, the per-hop delay of the aggregated traffic per routing ID of each IAB node BAP control PDU 1200 includes a D / C bit, which is used to indicate whether the per-hop delay of the aggregated traffic per routing ID of each IAB node BAP control PDU 1200 is a control PDU or a data PDU (in some cases, for the control PDU, the D / C bit can be set to 0 for control).

[0111] The per-hop delay of aggregated traffic per route ID per IAB Node BAP control PDU 1200 also includes a PDU type field. An appropriate PDU type ID (1011) of the per-hop delay of aggregated traffic per route ID per IAB Node BAP control PDU 1200 may be inserted into this field.

[0112] The per-hop delay for aggregated traffic per routing ID per IAB node BAP control PDU 1200 also includes one or more routing ID fields that identify one or more routing IDs for which the per-hop delay metric for aggregated traffic per routing ID per IAB node is being sent.

[0113] The per-hop delay of aggregate traffic per routing ID per IAB node BAP control PDU 1200 also includes one or more hop delay indices that relate to the delay index (per IAB node) itself for the corresponding routing ID, as shown (which together may represent the per-hop delay of aggregate traffic per routing ID per IAB node). These may be the number necessary to represent all necessary hops (and may accordingly increase in number as the per-hop delay of aggregate traffic per routing ID per IAB node BAP control PDU 1200 hops through IAB nodes of the system).

[0114] As shown, the per-hop delay of the aggregated traffic per route ID per IAB Node BAP control PDU 1200 also includes various reserved bits (marked as "R"). This can help facilitate the octet alignment within the per-hop delay of the aggregated traffic per route ID per IAB Node BAP control PDU 1200 between the various data fields in the manner shown. In some embodiments, the per-hop delay of the aggregated traffic per route ID per IAB Node BAP control PDU is sent without the reserved bits (and the various data fields are adjusted to fit adjacently by ignoring any octet alignment considerations). In these embodiments, such per-hop delay of the aggregated traffic per route ID per IAB Node BAP control PDU can use fewer resources (bits) than the per-hop delay of the aggregated traffic per route ID per IAB Node BAP control PDU 1200.

[0115] Fig.13 A method 1300 of a parent integrated access and backhaul (IAB) node of a wireless communication system is shown according to an embodiment.

[0116] The method 1300 includes receiving 1302 information including one or more of the following from a child IAB node: one or more hop count metrics corresponding to one or more data flows received at the child IAB node; one or more aggregate throughput metrics per BH RLC channel ID or one or more aggregate throughput metrics per route ID corresponding to one or more data flows received at the child IAB node; and one or more per-hop delay metrics of aggregated traffic per BH RLC channel ID per IAB node or one or more per-hop delay metrics of aggregated traffic per route ID per IAB node corresponding to one or more data flows received at the child IAB node.

[0117] The method 1300 also includes determining 1304 a data flow prioritization configuration of the child IAB node based on the received information.

[0118] The method 1300 also includes sending 1306 the data flow prioritization configuration to the child IAB node.

[0119] In some embodiments of the method 1300, the data flow prioritization configuration is sent to the child IAB node in a BH BAP PDU.

[0120] In some embodiments of the method 1300, the data flow prioritization configuration is sent to the child IAB node over the F1AP interface.

[0121] Embodiments contemplated herein include an apparatus comprising means for performing one or more elements of the method 1300. The apparatus may be, for example, an apparatus of a UE 1600 as described below.

[0122] Embodiments contemplated herein include one or more non-transitory computer-readable media that include instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of method 1300. The non-transitory computer-readable medium may be, for example, memory 1606 of UE 1600 described below, and / or peripheral device 2004, memory / storage device 2014, and / or database 2020 of component 1300 described below.

[0123] Embodiments contemplated herein include an apparatus comprising logical components, modules, or circuits for performing one or more elements of the method 1300. The apparatus may be, for example, an apparatus of a UE 1600 as described below.

[0124] Embodiments contemplated herein 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 one or more elements of the method 1300. The apparatus may be, for example, an apparatus of a UE 1600 as described below.

[0125] Embodiments contemplated herein include signals as described in or associated with one or more elements of method 1300 .

[0126] Implementations contemplated herein include datagrams, packets, frames, segments, protocol data units (PDUs), or messages as described in or associated with one or more elements of method 1300 .

[0127] Implementations contemplated herein include a signal encoded with data as described in or associated with one or more elements of method 1300 .

[0128] Embodiments contemplated herein include signals encoded with a datagram, packet, frame, segment, PDU, or message as described in or associated with one or more elements of method 1300 .

[0129] Embodiments contemplated herein include electromagnetic signals carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform one or more elements of method 1300 .

[0130] Embodiments contemplated herein include a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform one or more elements of method 1300. These instructions may be, for example, instructions 2012 of component 2000 as described below.

[0131] Fig.14 A method 1400 of a donor integrated access and backhaul (IAB) node of a wireless communication system is shown according to an embodiment.

[0132] The method 1400 includes receiving 1402 information regarding one or more data flows received at a descendant IAB node.

[0133] The method 1400 also includes determining 1404 a data flow prioritization configuration for a descendant IAB node based on the received information.

[0134] The method 1400 also optionally includes calculating 1406 a fairness index using the received information, wherein the fairness index indicates a time duration percentage for which the descendant IAB node should prioritize packets of one of the one or more data flows received at the descendant IAB node.

[0135] The method 1400 also optionally includes configuring 1408 descendant nodes to time stamp packets of the one or more data flows.

[0136] The method 1400 also optionally includes determining 1410 a list of packets to be dropped at a descendant IAB node, wherein the data flow prioritization configuration includes the list of packets to be dropped at the descendant IAB node.

[0137] The method 1400 also includes sending 1412 the data flow prioritization configuration to descendant IAB nodes.

[0138] In some embodiments of method 1400, information about one or more data flows received at the descendant node is received from the descendant node over the F1AP interface.

[0139] In some embodiments of the method 1400, information about one or more data flows received at the descendant node is received in a BH Adaptation Header (BAP) PDU from a child node that is not a descendant node.

[0140] In some embodiments of method 1400 (which includes calculating 1406 a fairness index), one or more data flows received at the descendant node include: one or more hop count metrics corresponding to the one or more data flows received at the descendant IAB node; and 1) one or more aggregate throughput metrics per backhaul BH RLC channel ID or 2) one or more aggregate throughput metrics per route ID corresponding to the one or more data flows received at the descendant IAB node; the fairness index indicates a time duration percentage for which the descendant IAB node should prioritize packets of one of the one or more data flows received at the descendant IAB node; and the data flow prioritization configuration includes the fairness index.

[0141] In some embodiments of the method 1400, which includes determining 1410 a list of packets to be discarded, the data stream prioritization configuration includes a list of packets to be discarded at a descendant IAB node. In some of these embodiments, one or more per-hop delay metrics corresponding to the one or more data streams are indicated according to a BH RLC channel of each of the one or more data streams. In some of these embodiments of the method 1400, which also includes configuring 1408 the descendant node to add timestamps to packets of the one or more data streams, the received information about the one or more data streams includes timestamps for packets of the one or more data streams.

[0142] Embodiments contemplated herein include an apparatus comprising means for performing one or more elements of the method 1400. The apparatus may be, for example, an apparatus of a UE 1600 as described below.

[0143] Embodiments contemplated herein include one or more non-transitory computer-readable media that include instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of method 1400. The non-transitory computer-readable medium may be, for example, memory 1606 of UE 1600 described below, and / or peripheral device 2004, memory / storage device 2014, and / or database 2020 of component 1300 described below.

[0144] Embodiments contemplated herein include an apparatus comprising logical components, modules, or circuits for performing one or more elements of the method 1400. The apparatus may be, for example, an apparatus of a UE 1600 as described below.

[0145] Embodiments contemplated herein 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 one or more elements of the method 1400. The apparatus may be, for example, an apparatus of a UE 1600 as described below.

[0146] Embodiments contemplated herein include signals as described in or associated with one or more elements of method 1400 .

[0147] Implementations contemplated herein include datagrams, packets, frames, segments, protocol data units (PDUs), or messages as described in or associated with one or more elements of method 1400 .

[0148] Implementations contemplated herein include a signal encoded with data as described in or associated with one or more elements of method 1400 .

[0149] Embodiments contemplated herein include signals encoded with a datagram, packet, frame, segment, PDU, or message as described in or associated with one or more elements of method 1400 .

[0150] Embodiments contemplated herein include electromagnetic signals carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform one or more elements of method 1400 .

[0151] Embodiments contemplated herein include a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform one or more elements of method 1400. These instructions may be, for example, instructions 2012 of component 2000 as described below.

[0152] Fig.15 A method 1500 of a sub-integrated access and backhaul (IAB) node of a wireless communication system according to an embodiment is shown.

[0153] The method 1500 includes calculating 1502 a plurality of metrics for one or more data flows received at a sub-IAB, the plurality of metrics including: one or more hop count metrics for the one or more data flows; one or more aggregate throughput metrics per BH RLC channel ID or one or more aggregate throughput metrics per route ID for the one or more data flows; and one or more per-hop delay metrics for aggregated traffic per BH RLC channel ID per IAB node or one or more per-hop delay metrics for aggregated traffic per route ID per IAB node for the one or more data flows.

[0154] The method 1500 also includes sending 1504 a metric of the one or more metrics to a parent IAB node.

[0155] In some embodiments of the method 1500, a metric among the plurality of metrics is sent to the parent IAB node in a BH Adaptation Header (BAP) PDU.

[0156] In some embodiments of the method 1500, a metric among the plurality of metrics is sent to a parent IAB node using the F1AP interface.

[0157] In some embodiments of the method 1500, the one or more hop count metrics are respectively calculated by incrementing a counter received at the child IAB node corresponding to the data flow received at the child IAB node.

[0158] In some embodiments of method 1500, one or more aggregate throughput metrics per BH RLC channel ID or one or more aggregate throughput metrics per route ID for one or more data flows are respectively calculated by dividing the number of RLC SDUs by the corresponding number of acknowledgments received for the RLC SDUs.

[0159] In some embodiments of the method 1500, the one or more per-hop delay metrics are respectively calculated per BH RLC channel ID by referencing one of a SFN and a subframe number received in each of the one or more data streams.

[0160] Embodiments contemplated herein include an apparatus comprising means for performing one or more elements of the method 1500. The apparatus may be, for example, an apparatus of a UE 1600 as described below.

[0161] Embodiments contemplated herein include one or more non-transitory computer-readable media that include instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of method 1500. The non-transitory computer-readable medium may be, for example, memory 1606 of UE 1600 described below, and / or peripheral device 2004, memory / storage device 2014, and / or database 2020 of component 1300 described below.

[0162] Embodiments contemplated herein include an apparatus comprising logical components, modules, or circuits for performing one or more elements of the method 1500. The apparatus may be, for example, an apparatus of a UE 1600 as described below.

[0163] Embodiments contemplated herein 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 one or more elements of the method 1500. The apparatus may be, for example, an apparatus of a UE 1600 as described below.

[0164] Embodiments contemplated herein include signals as described in or associated with one or more elements of method 1500 .

[0165] Implementations contemplated herein include datagrams, packets, frames, segments, protocol data units (PDUs), or messages as described in or associated with one or more elements of method 1500 .

[0166] Implementations contemplated herein include signals encoded with data as described in or related to one or more elements of method 1500 .

[0167] Embodiments contemplated herein include signals encoded with a datagram, packet, frame, segment, PDU, or message as described in or associated with one or more elements of method 1500 .

[0168] Embodiments contemplated herein include electromagnetic signals carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform one or more elements of method 1500 .

[0169] Embodiments contemplated herein include a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform one or more elements of method 1500. These instructions may be, for example, instructions 2012 of component 2000 as described below.

[0170] Fig.16 1 is a block diagram of an exemplary UE 1600 that can be configured according to various embodiments of the present disclosure, including by executing instructions corresponding to any exemplary method and / or process described herein on a computer-readable medium. The UE 1600 includes one or more processors 1602, a transceiver 1604, a memory 1606, a user interface 1608, and a control interface 1610.

[0171] The one or more processors 1602 may include, for example, an application processor, an audio digital signal processor, a central processing unit, and / or one or more baseband processors. Each of the one or more processors 1602 may include an internal memory and / or may include an interface for communicating with an external memory (including memory 1606). The internal or external memory may store software code, programs, and / or instructions for execution by the one or more processors 1602 to configure and / or facilitate UE1600 to perform various operations, including the operations described herein. For example, the execution of the instructions may configure UE 1600 to communicate using one or more wired or wireless communication protocols, including one or more wireless communication protocols standardized by 3GPP, such as those commonly referred to as 5G / NR, LTE, LTE-A, UMTS, HSPA, GSM, GPRS, EDGE, etc., or any other current or future protocol that may be used in conjunction with one or more transceivers 1604, user interface 1608, and / or control interface 1610. As another example, the one or more processors 1602 may execute program code stored in the memory 1606 or other memory corresponding to the MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP (e.g., for NR and / or LTE). As another example, the processor 1602 may execute program code stored in the memory 1606 or other memory that, together with the one or more transceivers 1604, implements a corresponding PHY layer protocol, such as orthogonal frequency division multiplexing (OFDM), orthogonal frequency division multiple access (OFDMA), and single carrier frequency division multiple access (SC-FDMA).

[0172] The memory 1606 may include a memory area for one or more processors 1602 to store variables used in protocols, configurations, controls, and other functions of the UE 1600 (including operations corresponding to or including any of the exemplary methods and / or processes described herein). In addition, the memory 1606 may include non-volatile memory (e.g., flash memory), volatile memory (e.g., static or dynamic RAM), or a combination thereof. In addition, the memory 1606 may interact with a memory slot through which removable memory cards of one or more formats (e.g., SD card, memory stick, compact flash, etc.) may be inserted and removed.

[0173] One or more transceivers 1604 may include radio frequency transmitter and / or receiver circuits that facilitate UE 1600 to communicate with other equipment supporting similar wireless communication standards and / or protocols. For example, one or more transceivers 1604 may include switches, mixer circuits, amplifier circuits, filter circuits, and synthesizer circuits. Such RF circuit systems may include a receive signal path having a circuit for down-converting an RF signal received from a front-end module (FEM) and providing a baseband signal to a baseband processor of one or more processors 1602. The RF circuit may also include a transmit signal path, which may include a circuit for up-converting a baseband signal provided by a baseband processor and providing an RF output signal for transmission to the FEM. The FEM may include a receive signal path, which may include a circuit configured to operate on an RF signal received from one or more antennas, amplify the receive signal, and provide an amplified version of the receive signal to the RF circuit for further processing. The FEM may also include a transmit signal path, which may include a circuit configured to amplify a transmit signal provided by the RF circuit for transmission by one or more antennas. In various embodiments, amplification through the transmit or receive signal path may be accomplished in the RF circuitry only, in the FEM only, or in both the RF circuitry and the FEM circuitry. In some embodiments, the FEM circuitry may include a TX / RX switch to switch between transmit mode and receive mode operation.

[0174] In some exemplary embodiments, one or more transceivers 1604 include transmitters and receivers that enable UE 1600 to communicate with various 5G / NR networks according to various protocols and / or methods proposed for standardization by 3GPP and / or other standards bodies. For example, such functionality may operate in cooperation with one or more processors 1602 to implement a PHY layer based on OFDM, OFDMA, and / or SC-FDMA techniques, such as described herein with reference to other figures.

[0175] The user interface 1608 may take various forms according to a particular embodiment, or may not be present in the UE 1600. In some embodiments, the user interface 1608 includes a microphone, a speaker, a slidable button, a depressible button, a display, a touch screen display, a mechanical or virtual keypad, a mechanical or virtual keyboard, and / or any other user interface features that are typically present on a mobile phone. In other embodiments, the UE 1600 may include a tablet computing device with a larger touch screen display. In such embodiments, one or more of the mechanical features of the user interface 1608 may be replaced by virtual user interface features (e.g., virtual keypads, virtual buttons, etc.) that are comparable or functionally equivalent using a touch screen display, as is familiar to those of ordinary skill in the art. In other embodiments, the UE 1600 may be a digital computing device, such as a laptop computer, a desktop computer, a workstation, etc., which includes a mechanical keyboard that may be integrated, detachable, or detachable according to a particular exemplary embodiment. Such a digital computing device may also include a touch screen display. Many exemplary embodiments of the UE 1600 with a touch screen display are capable of receiving user input, such as input related to the exemplary methods and / or processes described herein or known to those of ordinary skill in the art.

[0176] In some exemplary embodiments of the present disclosure, UE 1600 includes an orientation sensor that can be used in various ways by the features and functions of UE 1600. For example, UE 1600 can use the output of the orientation sensor to determine when a user has changed the physical orientation of the touch screen display of UE 1600. The indication signal from the orientation sensor can be used for any application executed on UE 1600, so that the application can automatically change the orientation of the screen display (e.g., from portrait to landscape) when the indication signal indicates an approximately 90-degree change in the physical orientation of the device. In this way, regardless of the physical orientation of the device, the application can maintain the screen display in a user-readable manner. In addition, the output of the orientation sensor can be used in conjunction with various exemplary embodiments of the present disclosure.

[0177] The control interface 1610 can take various forms depending on the particular implementation. For example, the control interface 1610 can include an RS-232 interface, an RS-485 interface, a USB interface, an HDMI interface, a Bluetooth interface, an IEEE ("FireWire") interface, an I 2 C interface, PCMCIA interface, etc. In some exemplary embodiments of the present disclosure, the control interface 1260 may include an IEEE 802.3 Ethernet interface, such as described above. In some exemplary embodiments of the present disclosure, the control interface 1610 may include an analog interface circuit, which includes, for example, one or more digital-to-analog (D / A) converters and / or analog-to-digital (A / D) converters.

[0178] Those skilled in the art will recognize that the above list of features, interfaces, and radio frequency communication standards is merely exemplary and does not limit the scope of the present disclosure. Fig.16 The UE 1600 may include more functions as shown, including, for example, video and / or still image cameras, microphones, media players and / or recorders, etc. In addition, the one or more transceivers 1604 may include circuits for communicating using additional radio frequency communication standards including Bluetooth, GPS and / or others. In addition, the one or more processors 1602 may execute software code stored in the memory 1606 to control such additional functions. For example, the directional speed and / or position estimate output from the GPS receiver may be used for any application executed on the UE 1600, including various exemplary methods and / or computer-readable media according to various exemplary embodiments of the present disclosure.

[0179] Fig.17 is a block diagram of an exemplary network node 1700 that may be configured according to various embodiments of the present disclosure, including by executing instructions on a computer-readable medium corresponding to any of the exemplary methods and / or processes described herein.

[0180] The network node 1700 includes one or more processors 1702, a radio network interface 1704, a memory 1706, a core network interface 1708, and other interfaces 1710. The network node 1700 may include, for example, a base station, an eNB, a gNB, an access node, or a component thereof.

[0181] The one or more processors 1702 may include any type of processor or processing circuit, and may be configured to perform one of the methods or processes disclosed herein. The memory 1706 may store software codes, programs and / or instructions executed by the one or more processors 1702 to configure the network node 1700 to perform various operations, including the operations described herein. For example, the execution of such stored instructions may configure the network node 1700 to communicate with one or more other devices using protocols according to various embodiments of the present disclosure (including one or more methods and / or processes described above). In addition, the execution of such stored instructions may also configure and / or facilitate the network node 1700 to communicate with one or more other devices using other protocols or protocol layers (such as one or more of the PHY, MAC, RLC, PDCP and RRC layer protocols standardized by 3GPP for LTE, LTE-A and / or NR, or any other higher layer protocol used in combination with the radio network interface 1704 and the core network interface 1708). By way of example and not limitation, the core network interface 1708 includes an S1 interface, and the radio network interface 1704 may include a Uu interface, such as standardized by 3GPP. The memory 1706 may also store variables used in protocols, configurations, controls, and other functions of the network node 1700. Thus, the memory 1706 may include non-volatile memory (e.g., flash memory, hard disk, etc.), volatile memory (e.g., static or dynamic RAM), network-based (e.g., "cloud") storage, or a combination thereof.

[0182] The radio network interface 1704 may include a transmitter, a receiver, a signal processor, an ASIC, an antenna, a beamforming unit, and other circuits that enable the network node 1700 to communicate with other equipment (in some embodiments, such as multiple compatible user equipments (UEs)). In some embodiments, the network node 1700 may include various protocols or protocol layers, such as PHY, MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP for LTE, LTE-A, and / or 5G / NR. According to other embodiments of the present disclosure, the radio network interface 1704 may include a PHY layer based on OFDM, OFDMA, and / or SC-FDMA technology. In some embodiments, the functions of such a PHY layer may be provided collaboratively by the radio network interface 1704 and one or more processors 1702.

[0183] The core network interface 1708 may include a transmitter, a receiver, and other circuits that enable the network node 1700 to communicate with other equipment in the core network (in some embodiments, such as circuit switching (CS) and / or packet switching core (PS) network). In some embodiments, the core network interface 1708 may include an S1 interface standardized by 3GPP. In some embodiments, the core network interface 1708 may include one or more interfaces to one or more SGWs, MEEs, SGSNs, GGSNs, and other physical devices, and the one or more interfaces include functions known to those of ordinary skill in the art that exist in GERAN, UTRAN, E-UTRAN, and CDMA2000 core networks. In some embodiments, these one or more interfaces may be multiplexed together on a single physical interface. In some embodiments, the lower layer of the core network interface 1708 may include one or more of asynchronous transfer mode (ATM), Internet protocol on Ethernet (IP), SDH on optical fiber, T1 / E1 / PDH on copper wire, microwave radio, or other wired or wireless transmission technologies known to those of ordinary skill in the art.

[0184] Other interfaces 1710 may include transmitters, receivers, and other circuits that enable network node 1700 to communicate with external networks, computers, databases, etc., for operation, management, and maintenance of network node 1700 or other network equipment operably connected thereto.

[0185] Exemplary System Architecture

[0186] In certain embodiments, the 5G system architecture supports data connectivity and services, enabling deployment to use technologies such as network function virtualization and software defined networks. The 5G system architecture can utilize service-based interactions between control plane network functions. Separating user plane functions from control plane functions allows independent scalability, evolution, and flexible deployment (e.g., centralized locations or distributed (remote) locations). Modular function design allows functional reuse, and flexible and effective network slicing can be achieved. Network functions and their network function services can interact with another NF and its network function services directly or indirectly via a service communication agent. Another intermediate function can help route control plane messages. The architecture minimizes the dependency between AN and CN. The architecture may include an aggregated core network with a public AN-CN interface that integrates different access types (e.g., 3GPP access and non-3GPP access). The architecture may also support a unified authentication framework, stateless NFs with decoupling of computing resources from storage resources, capability exposure, concurrent access to local and centralized services (to support low-latency services and access to local data networks, user plane functions may be deployed near the AN), and / or roaming in the visited PLMN with both home-routed traffic as well as local breakout traffic.

[0187] The 5G architecture may be defined as service-based, and the interactions between network functions may include a service-based representation, where a network function (e.g., AMF) within the control plane enables other authorized network functions to access its services. The service-based representation may also include a point-to-point reference point. The reference point representation may also be used to show the interactions between NF services in a network function described by a point-to-point reference point (e.g., N11) between any two network functions (e.g., AMF and SMF).

[0188] Fig.18 A service-based architecture 1800 in 5GS according to one embodiment is shown. As described in 3GPP TS23.501, the service-based architecture 1800 includes NFs such as NSSF 1808, NEF 1810, NRF 1814, PCF 1812, UDM 1826, AUSF 1818, AMF 1820, SMF 1822 for communicating with UE 1816, (R) AN 1806, UPF 1802, and DN 1804. NFs and NF services can communicate directly (referred to as direct communication) or indirectly via SCP 1824 (referred to as indirect communication). Fig.18 Also shown are corresponding service-based interfaces including Nutm, Naf, Nudm, Npcf, Nsmf, Nnrf, Namf, Nnef, Nnssf and Nausf and reference points N1, N2, N3, N4 and N6. Fig.18 Some exemplary functions provided by the NF shown.

[0189] NSSF 1808 supports functions such as: selecting a set of network slice instances to serve the UE; determining the allowed NSSAIs and, if necessary, determining the mapping to the subscribed S-NSSAI; determining the configured NSSAI and, if necessary, determining the mapping to the subscribed S-NSSAI; and / or determining the set of AMFs to be used to serve the UE, or based on the configuration, possibly determining a list of candidate AMFs by querying the NRF.

[0190] NEF 1810 supports the exposure of capabilities and events. NF capabilities and events can be securely exposed by NEF 1810 (e.g., for third parties, application functions and / or edge computing). NEF 1810 can store / retrieve information as structured data using a standardized interface (Nudr) to UDR. NEF 1810 can also securely provide information to the 3GPP network from external applications, and can provide application functions to securely provide information to the 3GPP network (e.g., expected UE behavior, 5GLAN group information, and service-specific information), where NEF 1810 can authenticate and authorize and help limit application functions. NEF 1810 can provide internal-external information conversion by converting between information exchanged with AF 1828 and information exchanged with internal network functions. For example, NEF 1810 converts between AF service identifiers and internal 5G core information (such as DNN and S-NSSAI). NEF 1810 can handle the masking of network and user sensitive information of external AF according to network policies. NEF 1810 may receive information from other network functions (based on the exposed capabilities of other network functions) and store the received information as structured data using a standardized interface to UDR. The stored information may then be accessed by NEF 1810 and re-exposed to other network functions and application functions, and used for other purposes such as analysis. For external exposure of services related to a specific UE, NEF 1810 may reside in the HPLMN. Depending on the operator agreement, the NEF 1810 in the HPLMN may have an interface with the NF in the VPLMN. SCEF+NEF may be used for service exposure when the UE is able to switch between EPC and 5GC.

[0191] NRF 1814 supports service discovery functionality by receiving NF discovery requests from NF instances or SCPs and providing information of discovered NF instances to NF instances or SCPs. NRF 1814 may also support P-CSCF discovery (a special case of SMF discovery of AFs), maintain NF profiles of available NF instances and their supported services, and / or notify subscribed NF service consumers or SCPs of newly registered / updated / deregistered NF instances together with their NF services. In the context of network slicing, multiple NRFs may be deployed at different levels, such as PLMN level (NRF configured with information of the entire PLMN), shared slice level (NRF configured with information belonging to a network slice set), and / or slice-specific level (NRF configured with information belonging to S-NSSAI), based on network specific implementation. In the context of roaming, multiple NRFs may be deployed in different networks, wherein the NRF in the visited PLMN (referred to as vNRF) is configured with information of the visited PLMN, and wherein the NRF in the home PLMN (referred to as hNRF) is configured with information of the home PLMN, referenced by the vNRF via the N27 interface.

[0192] PCF 1812 supports a unified policy framework to govern network behavior. PCF 1812 provides policy rules for control plane functions to implement them. PCF 1812 accesses subscription information related to policy decisions in a unified data repository (UDR). PCF 1812 can access a UDR located in the same PLMN as the PCF.

[0193] UDM 1826 supports generation of 3GPP AKA authentication credentials, user identification processing (e.g., storage and management of SUPI for each subscriber in the 5G system), unhiding of the privacy-preserving subscription identifier (SUCI), access authorization based on subscription data (e.g., roaming restrictions), UE's serving NF registration management (e.g., storing the service AMF for the UE, storing the PDU session storage service SMF for the UE), service / session continuity (e.g., by maintaining SMF / DNN allocation for ongoing sessions), MT-SMS delivery, lawful interception functionality (especially in outbound roaming situations where the UDM is the only contact point for the LI), subscription management, SMS management, 5GLAN group management processing, and / or external parameter configuration (expected UE behavior parameters or network configuration parameters). To provide such functionality, UDM 1826 uses subscription data (including authentication data) that may be stored in the UDR, in which case the UDM implements the application logic and may not require internal user data storage, and several different UDMs may serve the same user in different transactions. UDM 1826 may be located in the HPLMN of the subscriber it serves and may access information of UDRs located in the same PLMN.

[0194] AUSF 1818 supports authentication for 3GPP access and untrusted non-3GPP access. AUSF 1818 can also provide support for network slice-specific authentication and authorization.

[0195] AMF 1820 supports termination of RAN CP interface (N2), termination of NAS (N1) for NAS encryption and integrity protection, registration management, connection management, reachability management, mobility management, lawful interception (for AMF events and interfaces to LI system), transmission of SM messages between UE and SMF, transparent proxy for routing SM messages, access authentication, access authorization, transmission of SMS messages between UE and SMSF, SEAF, location service management for regulatory services, transmission of location service messages between UE and LMF and between RAN and LMF, EPS bearer ID allocation for interworking with EPS, UE mobility event notification, control plane CIoT 5GS optimization, user plane CIoT 5GS optimization, configuration of external parameters (expected UE behavior parameters or network configuration parameters) and / or network slice-specific authentication and authorization. Some or all of the AMF functions may be supported in a single instance of AMF 1820. Regardless of the number of network functions, in some embodiments, only one NAS interface instance per access network between UE and CN terminates at one of the network functions that implements at least NAS security and mobility management. AMF 1820 may also include policy-related functions.

[0196] In addition to the above functions, AMF 1820 may also include the following functions to support non-3GPP access networks: support N2 interface with N3IWF / TNGF, on which some information (e.g., 3GPP cell identity) and procedures (e.g., handover related) defined on 3GPP access may not be applicable, and non-3GPP access specific information not applicable to 3GPP access may be applied; support NAS signaling with UE through N3IWF / TNGF, where some procedures supported by NAS signaling through 3GPP access may not be applicable to untrusted non-3GPP (e.g., paging) access; support verification of UE connected through N3IWF / TNGF; management of mobility, authentication and separate security context states of UE connected via non-3GPP access or via 3GPP access or non-3GPP access at the same time; support coordinated RM management context valid on 3GPP access and non-3GPP access; and / or support dedicated CM management context for UE connected via non-3GPP access. It may not be necessary to support all of the above functions in the instance of network slicing.

[0197] SMF 1822 supports session management (e.g., session establishment, modification, and release, including tunnel maintenance between UPF and AN nodes), UE IP address allocation and management (including optional authorization) (where the UE IP address can be received from the UPF or from an external data network), DHCPv4 (server and client) and DHCPv6 (server and client) functions, functions for responding to address resolution protocol requests and / or IPv6 neighbor request requests based on local cache information of Ethernet PDUs (e.g., SMF responds to ARP and / or IPv6 neighbor request requests by providing a MAC address corresponding to the IP address sent in the request), selection and control of user plane functions (including controlling UPF to proxy ARP or IPv6 neighbor discovery or forwarding all ARP / IPv6 neighbor request traffic to SMF for Ethernet PDU sessions), traffic steering configuration at UPF to route traffic to the appropriate destination, 5G VN group management (e.g., maintaining the topology of the PSA UPFs involved, in the PSA Establish and publish N19 tunnels between UPFs, configure traffic forwarding at UPF to apply local switching and / or N6-based forwarding or N19-based forwarding), terminate interfaces towards policy control functions, lawful interception (for SM events and interfaces to LI systems), charge for data collection and support charging interfaces, control and coordinate charging data collection at UPF, terminate the SM part of NAS messages, downlink data notification, initiator of AN-specific SM information sent to AN via AMF over N2, determination of SSC mode for session, control plane CIoT 5GS optimization, header compression, act as I-SMF in deployments where I-SMF can be inserted / removed / relocated, configure external parameters (expected UE behavior parameters or network configuration parameters), P-CSCF discovery for IMS services, roaming functions (e.g., handling local implementation to apply QoS SLA (VPLMN), charging data collection and charging interface (VPLMN) and / or lawful interception (in VPLMN for SM events and interface to LI system), interaction with external DN to transmit signaling for PDU session authentication / authorization for external DN and / or instructing UPF and NG-RAN to perform redundant transmission on N3 / N9 interface. Some or all of the SMF functions may be supported in a single instance of SMF. However, in some embodiments, not all functions need to be supported in an instance of a network slice. In addition to the functions, SMF 1822 may include policy-related functions.

[0198] SCP 1824 includes one or more of the following functions: indirect communication; delegated discovery; message forwarding and routing to destination NF / NF service; communication security (e.g., authorization of NF service consumer to access NF service manufacturer API), load balancing, monitoring, overload control, etc.; and / or optionally interacting with UDR to resolve UDM group ID / UDR group ID / AUSF group ID / PCF group ID / CHF group ID / HSS group ID based on UE identity (e.g., SUPI or IMPI / IMPU). Some or all of the SCP functions may be supported in a single instance of SCP. In some embodiments, SCP 1824 can be deployed in a distributed manner and / or more than one SCP may be present in the communication path between NF services. SCP can be deployed at PLMN level, shared slice level, and slice-specific level. Operator deployment may be left to ensure that SCP can communicate with relevant NRFs.

[0199] UE 1816 may include a device with radio communication capabilities. For example, UE 1816 may include a smart phone (e.g., a handheld touch screen mobile computing device that can be connected to one or more cellular networks). UE 1816 may also include any mobile or non-mobile computing device, such as a personal data assistant (PDA), a pager, a laptop computer, a desktop computer, a wireless handheld device, or any computing device including a wireless communication interface. UE is also referred to as a client, a mobile phone, a mobile device, a mobile terminal, a user terminal, a mobile unit, a mobile station, a mobile user, a subscriber, a user, a remote station, an access agent, a user agent, a receiver, a radio equipment, a reconfigurable radio equipment, or a reconfigurable mobile device. UE 1816 may include an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. IoT UE may utilize technology (e.g., M2M, MTC, or mMTC technology) to exchange data with an MTC server or device via a PLMN, other UEs using ProSe or D2D communication, a sensor network, or an IoT network. M2M or MTC data exchange may be machine-initiated data exchange. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure). The IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity to the IoT network.

[0200] UE 1816 may be configured to be connected or communicatively coupled to (R)AN 1806 via a radio interface 1830, which may be a physical communication interface or layer configured to operate with a cellular communication protocol (such as a GSM protocol, a CDMA network protocol, a push-to-talk (PTT) protocol, a cellular PTT (POC) protocol, a UMTS protocol, a 3GPP LTE protocol, a 5G protocol, a NR protocol, etc.). For example, UE 1816 and (R)AN 1806 may use a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack including a PHY layer, a MAC layer, an RLC layer, a PDCP layer, and an RRC layer. DL transmissions may be from (R)AN 1806 to UE 1816, and UL transmissions may be from UE 1816 to (R)AN 1806. UE 1816 may also communicate directly with another UE (not shown) using a side link for D2D, P2P, and / or ProSe communications. For example, the ProSe interface may include one or more logical channels, including but not limited to a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), a physical sidelink discovery channel (PSDCH), and a physical sidelink broadcast channel (PSBCH).

[0201] (R)AN 1806 may include one or more access nodes, which may be referred to as base stations (BS), node Bs, evolved node Bs (eNBs), next generation node Bs (gNBs), RAN nodes, controllers, transmission reception points (TRPs), etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). (R)AN 1806 may include one or more RAN nodes for providing macro cells, pico cells, femto cells, or other types of cells. A macro cell may cover a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access by a UE with a service subscription. A pico cell may cover a relatively small geographic area and may allow unrestricted access by a UE with a service subscription. A femto cell may cover a relatively small geographic area (e.g., a home) and may allow restricted access to UEs associated with the femto cell (e.g., UEs in a closed subscriber group (CSG), UEs of users in a home, etc.).

[0202] Although not shown, multiple RAN nodes (such as (R)AN 1806) may be used, with an Xn interface defined between two or more nodes. In some specific implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U may provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and flow control functions. The Xn-C may provide management and error handling functions for managing the functions of the Xn-C interface; mobility support for UE 1816 in connected mode (e.g., CM-CONNECTED) includes functions for managing UE mobility in connected mode between one or more (R)AN nodes. The mobility support may include context transfer from an old (source) serving (R)AN node to a new (target) serving (R)AN node; and control of a user plane tunnel between the old (source) serving (R)AN node and the new (target) serving (R)AN node.

[0203] UPF 1802 may serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point interconnected with DN 1804, and a branch point to support multi-host PDU sessions. UPF 1802 may also perform packet routing and forwarding, packet inspection, execute the user plane portion of policy rules, legally intercept packets (UP collection); traffic usage reporting, perform QoS processing on the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS flow mapping), transport level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. UPF 1802 may include an uplink classifier for supporting routing of traffic flows to data networks. DN 1804 may represent various network operator services, Internet access, or third-party services. DN 1804 may include, for example, an application server.

[0204] Fig.19 An NG-RAN architecture 1900 is shown according to one embodiment, which includes a 5GC 1904 and a NG-RAN 1902. The NG-RAN 1902 includes multiple gNBs (two gNBs shown as gNB 1906 and gNB 1908) connected to the 5GC 1904 via an NG interface. The gNB 1906 and gNB 1908 may support FDD mode, TDD mode, or dual mode operation and are connected to each other via an Xn-C interface. As shown, the gNB 1908 includes a gNB-CU 1910 connected to a gNB-DU 1912 and a gNB-DU 1914 via an F1 interface. The gNB 1908 may include only a single gNB-DU or more than the two gNB-DUs shown. The NG interface, the Xn-C interface, and the F1 interface are logical interfaces.

[0205] Fig. 20 is a block diagram illustrating a component 2000 capable of reading instructions from a machine-readable medium or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein, according to some exemplary embodiments. Specifically, Fig. 20 A diagrammatic representation of hardware resources 2002 is shown including one or more processors 2006 (or processor cores), one or more memory / storage devices 2014, and one or more communication resources 2024, each of which may be communicatively coupled via a bus 2016. For embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 2022 may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 2002.

[0206] Processor 2006 (e.g., 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 digital signal processor (DSP) (such as a baseband processor), an application specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 2008 and processor 2010.

[0207] The memory / storage device 2014 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 2014 may include, but is not limited to, any type of volatile or non-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage, etc.

[0208] The communication resources 2024 may include interconnect or network interface components or other suitable devices to communicate with one or more peripheral devices 2004 or one or more databases 2020 via the network 2018. For example, the communication resources 2024 may include wired communication components (e.g., for coupling via a universal serial bus (USB)), cellular communication components, NFC components, Parts (e.g. Low power consumption), components and other communication components.

[0209] The instructions 2012 may include software, programs, applications, applet, applications, or other executable code for causing at least any one of the processors 2006 to perform any one or more of the methods discussed herein. The instructions 2012 may reside in whole or in part in at least one of the processor 2006 (e.g., in a cache memory of the processor), the memory / storage device 2014, or any suitable combination thereof. In addition, any portion of the instructions 2012 may be transmitted to the hardware resources 2002 from any combination of the peripheral device 2004 or the database 2020. Therefore, the memory of the processor 2006, the memory / storage device 2014, the peripheral device 2004, and the database 2020 are examples of computer-readable and machine-readable media.

[0210] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes and / or methods as described herein. For example, the baseband circuit described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the following examples. For another example, the circuits associated with the UE, base station, network element, etc. described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples shown in the example section below.

[0211] Unless otherwise expressly stated, any of the above embodiments may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. In view of the above teachings, modifications and variations are possible or can be obtained from the practice of various embodiments.

[0212] Embodiments and implementations of the systems and methods described herein may include various operations that may be embodied in machine executable instructions to be executed by a computer system. A computer system may include one or more general or special purpose computers (or other electronic devices). A computer system may include hardware components that include specific logic components for performing operations, or may include a combination of hardware, software, and / or firmware.

[0213] It should be appreciated that the systems described herein include descriptions of specific embodiments. These embodiments may be combined into a single system, partially incorporated into other systems, separated into multiple systems, or otherwise divided or combined. In addition, it is contemplated that parameters, attributes, aspects, etc. of one embodiment may be used in another embodiment. For clarity, these parameters, attributes, aspects, etc. are described only in one or more embodiments, and it should be appreciated that unless otherwise stated herein, these parameters, attributes, aspects, etc. may be combined with or substituted for parameters, attributes, aspects, etc. of another embodiment.

[0214] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

[0215] Although the foregoing has been described in considerable detail for the sake of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles of the invention. It should be noted that there are many alternative ways to implement both the processes and the apparatus described herein. Therefore, the embodiments of the present invention are to be regarded as illustrative rather than restrictive, and the specification is not limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1. A method for a parent integrated access and backhaul IAB node of a wireless communication system, the method comprising: Receive information from the child IAB node including one or more of the following: one or more hop count metrics corresponding to one or more data flows received at the child IAB node; one or more aggregate throughput metrics per backhaul BH radio link control RLC channel identifier ID or one or more aggregate throughput metrics per route ID corresponding to the one or more data flows received at the child IAB node; and one or more per-hop delay metrics of aggregated traffic per BH RLC channel ID per IAB node or one or more per-hop delay metrics of aggregated traffic per route ID per IAB node, corresponding to the one or more data flows received at the child IAB node; calculating a fairness index using the received information, wherein the fairness index indicates a percentage of time duration for which the child IAB node should prioritize packets of one of the one or more data flows received at the child IAB node; determining a data stream prioritization configuration of the child IAB node based on the received information, wherein the data stream prioritization configuration includes the fairness index; and The data flow prioritization configuration is sent to the child IAB node.

2. The method of claim 1, wherein the data stream prioritization configuration is sent to the child IAB node in a BH Adaptation Header (BAP) Protocol Data Unit (PDU).

3. The method of claim 1, wherein the data flow prioritization configuration is sent to the child IAB node over an F1 Application Protocol (F1AP) interface.

4. A method for integrating donor access and backhaul IAB nodes of a wireless communication system, the method comprising: receiving information about one or more data flows received at a descendant IAB node; calculating a fairness index using the received information, wherein the fairness index indicates a percentage of time duration for which the descendant IAB node should prioritize packets of one of the one or more data flows received at the descendant IAB node; determining a data flow prioritization configuration for the descendant IAB node based on the received information, wherein the data flow prioritization configuration includes the fairness index; as well as The data flow prioritization configuration is sent to the descendant IAB node.

5. The method of claim 4, wherein the information about the one or more data flows received at the descendant IAB node is received from the descendant IAB node over an F1 Application Protocol (F1AP) interface.

6. The method of claim 4, wherein the information about the one or more data flows received at the descendant IAB node is received in a backhaul BH adaptation header (BAP) protocol data unit (PDU) from a child node that is not the descendant IAB node.

7. The method of claim 4, wherein the information about the one or more data flows received at the descendant IAB node comprises: one or more hop count metrics corresponding to the one or more data flows received at the descendant IAB node; and One or more aggregate throughput metrics per backhaul BH radio link control RLC channel identifier ID or one or more aggregate throughput metrics per route ID corresponding to the one or more data flows received at the descendant IAB node.

8. The method of claim 4, wherein the information about the one or more data flows received at the descendant IAB node comprises one or more per-hop delay metrics corresponding to the one or more data flows; and The method further includes determining a list of packets to be discarded at the descendant IAB node, wherein the data flow prioritization configuration includes the list of packets to be discarded at the descendant IAB node.

9. The method of claim 8, wherein the one or more per-hop delay metrics corresponding to the one or more data flows are indicated per backhaul (BH) radio link control (RLC) channel of each of the one or more data flows.

10. The method of claim 8, further comprising configuring the descendant IAB node to add time stamps to packets of the one or more data flows; wherein the received information about one or more data flows includes the time stamps of the packets of the one or more data flows.

11. A method for a sub-integrated access and backhaul IAB node of a wireless communication system, the method comprising: calculating a plurality of metrics for one or more data streams received at the sub-IAB, the plurality of metrics comprising: one or more hop count metrics of the one or more data flows; one or more aggregate throughput metrics per backhaul BH radio link control RLC channel identifier ID or one or more aggregate throughput metrics per route ID of the one or more data flows; and one or more per-hop delay metrics of aggregated traffic per BH RLC channel ID per IAB node or one or more per-hop delay metrics of aggregated traffic per routing ID per IAB node of the one or more data flows; and sending a metric from the plurality of metrics to a parent IAB node; and A data stream prioritization configuration is received from the parent IAB node, the data stream prioritization configuration including a fairness index indicating a time duration percentage for which the child IAB node should prioritize packets of one of the one or more data streams received at the child IAB node.

12. The method of claim 11, wherein the one metric of the plurality of metrics is sent to the parent IAB node in a BH Adaptation Header (BAP) Protocol Data Unit (PDU).

13. The method of claim 11, wherein the one of the plurality of metrics is sent to the parent IAB node using an F1 Application Protocol (F1AP) interface.

14. The method of claim 11, wherein the one or more hop count metrics are respectively calculated by incrementing a counter received at the child IAB node corresponding to a data flow received at the child IAB node.

15. The method of claim 11, wherein the one or more aggregate throughput metrics per BH RLC channel ID or the one or more aggregate throughput metrics per route ID of the one or more data flows are respectively calculated by dividing the number of RLC service data units (SDUs) by the corresponding number of acknowledgments received for the RLC SDUs.

16. The method of claim 11, wherein the per-hop delay metrics of the one or more per-BH RLC channel IDs are respectively calculated by referring to one of a system frame number SFN and a subframe number received in each of the one or more data streams.

Images