P-BSR Enhanced Method for IAB Networks to Improve E2E Latency

Abstract

The present disclosure relates to methods for enhancing pre-BSR in IAB networks for improving E2E latency. Disclosed herein are systems and methods for enhancing the use of preemptive buffer status reporting (pre-BSR) in wireless communication systems implementing integrated access and backhaul (IAB) networks. In some cases, an IAB node can reclassify the LCGs of one or more incoming data flows based on such pre-BSR use. This can involve extending the medium access control (MAC) control element (MAC CE) and its use, including more LCG bits than previously envisioned, sub-LCG bits, or other LCG classification information bits. Other embodiments utilize a priority index for the LCG in the extended pre-BSR MAC CE. The priority index can include one or more of a priority field reported to the IAB donor, a priority bit rate (PBR), and / or a token bucket depth (BSD). Other embodiments mitigate undesirable pre-BSR effects by providing additional grants from the IAB node to the sub-IAB nodes.

Description

Technical Field

[0001] The present application generally relates to wireless communication systems, including using preemptive buffer status reporting (pre-BSR) in wireless communication systems implementing an integrated access and backhaul (IAB) network. 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 commonly referred to by industry organizations as Worldwide Interoperability for Microwave Access (WiMAX); and the IEEE 802.11 standard for Wireless Local Area Networks (WLANs), which is commonly referred to by industry organizations as Wi-Fi. In the 3GPP Radio Access Network (RAN) in an LTE system, a 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, enhanced Node B, eNodeB, or 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 known as 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 Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), and / or E-UTRAN, which provide access to communication services through the core network. Each RAN in the RAN operates according to a specific 3GPP RAT. For example, GERAN implements GSM and / or EDGE RATs, UTRAN implements Universal Mobile Telecommunications System (UMTS) RATs or other 3GPP RATs, E-UTRAN implements LTE RATs, and NG-RAN implements 5G RATs. In some deployments, E-UTRAN may also implement 5G RATs.

[0004] The frequency bands for 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 over time or from 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 A signaling flow for an IAB network using preemptive buffer status reporting (pre-BSR) is shown, according to an embodiment.

[0009] Figure 4 The format of a medium access control (MAC) control element (MACCE) for transmitting a pre-BSR according to an embodiment is shown.

[0010] Figure 5 A signaling flow is shown that illustrates various fairness issues that may arise when using various pre-BSR implementations across an IAB network, according to an embodiment.

[0011] Figure 6 A method of an IAB node of a wireless communication system according to an embodiment is shown.

[0012] Figure 7 A method of an IAB node of a wireless communication system according to an embodiment is shown.

[0013] Figure 8 A method of an IAB node of a wireless communication system according to an embodiment is shown.

[0014] Figure 9 A UE according to one embodiment is shown.

[0015] Figure 10A network node according to one embodiment is shown.

[0016] Figure 11 An exemplary service-based architecture is shown in accordance with certain embodiments.

[0017] Figure 12 An NG-RAN architecture according to one embodiment is shown.

[0018] Figure 13 Components according to one embodiment are shown. DETAILED DESCRIPTION

[0019] Millimeter wave (mmWave) deployments of wireless networks can use fiber backhaul to carry traffic at NR speeds. However, providing fiber backhaul for the many nodes used for mmWave coverage can be difficult or costly. 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 to relay access traffic.

[0020] The IAB architecture supports multi-hop routing, where IAB nodes act as both access nodes for UEs and provide backhaul (BH) links to other IAB nodes. In wireless backhaul, the IP layer is carried on the Backhaul Adaptation Protocol (BAP) sublayer, enabling multi-hop routing. The BAP allows IAB nodes to communicate with each other and provides multiple functions, including, for example, mapping of next-hop Radio Link Control (RLC) channels, traffic-based routing to next-hop IAB nodes (both child and parent), indication of network events (e.g., radio link failures), data transfer, and / or flow control feedback signaling.

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

[0022] Figure 1An exemplary IAB network 100 for certain embodiments is shown. The IAB network 100 includes an IAB donor 102 having a fiber backhaul connection (e.g., via an NG interface) to a 5G core network (5GC) 104. In this example, the IAB network 100 also includes an IAB node 106 (shown as IAB node 1-1), an IAB node 108 (shown as IAB node 2-1), and an IAB node 110 (shown as IAB node 3-1), although any number of IAB nodes or hops can be used to establish a connection between a UE 112 and the 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). As will be appreciated by those skilled in the art from the disclosure herein, any of the IAB nodes can also provide communication with other UEs. For example, the IAB node 106 can establish communication between the UE 114 and the 5GC 104. It is contemplated that an IAB donor may also, in at least some circumstances, 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).

[0023] 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, child nodes, or relay nodes, and each includes two subcomponents: a DU and a mobile terminal (MT). The CU generally provides basic control plane functionality. In certain embodiments, the CU includes a CU control plane (CU-CP), a CU-user plane (CU-UP), and / or other functionality.

[0024] The MT includes components that configure a network node (e.g., a gNB) to behave similarly to a conventional UE. For example, in an MT with additional enhancements discussed in 3GPP Release 16 and Release 17, protocols that typical UEs use to connect to the network are supported. 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 which parent to join and establishes and utilizes RLC through the BAP layer, which provides functionality for routing data for different UEs over different routes through the network.

[0025] Figure 2An exemplary protocol architecture for an IAB 200 according to one embodiment is shown. The exemplary protocol architecture for the IAB 200 illustrates various protocol layers for a UE 202, a first IAB node 208 (IAB Node 1), a second IAB node 204 (IAB Node 2), and an 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 the IAB donor 206 may communicate via an intra-donor F1-U interface. In this example, the UE 202 wirelessly communicates with the second IAB node 204 via the UE's dedicated radio bearer (DRB), and the second IAB node 204 wirelessly relays uplink traffic to the first IAB node 208 via a 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).

[0026] The exemplary protocol architecture for IAB 200 also includes a Backhaul Adaptation Protocol (BAP) layer, which provides functionality for routing data for different UE bearers over different routes through the network. This is accomplished by having an adaptation layer header that includes information identifying the bearer. This routing includes mapping incoming data to outgoing links based on the bearer identifier.

[0027] 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 that node and the IAB nodes on those routes.

[0028] Embodiments herein contemplate the use of buffer status reports (BSRs) and preemptive BSRs (pre-BSRs). A BSR allows a transmitting entity to indicate to a receiving entity the size of a data buffer that it intends to send to the receiving entity. The data buffer may include one or more PDUs, the corresponding sizes of which are being sent. This allows the receiving entity to provide an appropriate UL grant for resources that the transmitting entity can use to send the data in the data buffer to the receiving entity. The UL grant can be appropriate because its size can be set to roughly correspond to the amount of data to be sent. In the manner shown, BSRs can be used between a UE and an IAB node and / or between IAB nodes. The transmitting entity may be restricted (e.g., by pre-configuration) in the frequency with which it is permitted to send BSRs to the receiving entity. For example, once the transmitting entity sends a first BSR to the receiving entity, it may start a timer that only allows the transmission of a second BSR (corresponding to additional UL data) upon expiration of the timer. A BSR (in contrast to, for example, a pre-BSR) may sometimes be referred to herein as a "regular BSR."

[0029] In an IAB implementation, a pre-BSR may be used in place of one or more BSRs between a pair of IAB nodes. The pre-BSR is sent by a transmitting IAB node to a receiving IAB node to provide the receiving IAB node with information about the amount of data the transmitting IAB node expects to receive from UEs and / or IAB nodes that are children of the transmitting IAB node. This information may be known at the transmitting IAB node due to a BSR (or pre-BSR) previously received at the transmitting IAB node. Therefore, the pre-BSR may be triggered by receiving this BSR (or pre-BSR) at the transmitting IAB node. In some implementations, the pre-BSR sent by the transmitting node is instead triggered by the transmitting IAB node sending a UL grant corresponding to such a BSR (or pre-BSR) received at the transmitting IAB node.

[0030] It is contemplated that the technical solutions described herein may add additional utility to the use of, for example, pre-BSR in the context of IAB in the manner described below.

[0031] Figure 3 A signaling flow 300 for an IAB network using preemptive buffer status reporting (pre-BSR) 334 is shown, according to an embodiment.

[0032] The IAB network implementing signaling flow 300 includes UE B 302, UE A 304, IAB Node 1 306, IAB Node 2 308, IAB Donor 310, and 5GC 312. From the perspective of UE B 302 and UE A 304, IAB Node 1 306 and IAB Node 2 308 may be relay IAB nodes within the IAB network. Therefore, each may include a protocol stack including a DU and a MT, as shown. IAB Donor 310 may be a donor node of the IAB network. Therefore, IAB Donor 310 may include a protocol stack including a DU and a CU, as shown. It is contemplated that either UE B 302 and / or UE A 304 may each represent a group of UEs.

[0033] Signaling flow 300 proceeds as shown, with UE A 304 sending a BSR 314 and UE B 302 sending a BSR 316 toward the DU of IAB node 1 306. In response to BSR 314, IAB node 1 306 sends an UL grant 318 to UE A 304. In response to BSR 316, IAB node 1 306 sends an UL grant 320 to UE B 302. In response to UL grant 318 received at UE A 304, UE A 304 sends PDU A1 322 to the DU of IAB node 1 306. In response to UL grant 320 received at UE B 302, UE B 302 sends PDU B1 324 to the DU of IAB node 1 306. It is contemplated that PDU A1 322 and / or PDU B1 324 may each represent a group of PDUs.

[0034] The DU of IAB Node 1 306 then performs a first IAB Node PDU A1 transmission 326 to the MT of IAB Node 1 306. Because IAB Node 1 306 is a relay node between UE A 304 and IAB Node 2 308, it should forward PDU A1 322 to IAB Node 2 308. Therefore, the MT of IAB Node 1 306 responds to the first IAB Node PDU A1 transmission 326 by sending a BSR 330 to the DU of IAB Node 2 308 to request uplink resources for forwarding PDU A1 322. The DU of IAB Node 2 308 responds to the BSR 330 with a UL Grant 332, and the MT of IAB Node 1 306 may responsively send PDU A1 322 to the DU of IAB Node 2 308, as shown.

[0035] As shown, the DU of IAB node 1 306 also performs a first IAB node PDU B1 transmission 328 to the MT of IAB node 1 306. However, at this point, the MT of IAB node 1 306 may be prevented from immediately sending a (regular) BSR corresponding to PDU B1 324 to the DU of IAB node 2 308. This may be because the timer for the BSR 330 previously sent by the MT of IAB node 1 306 to the DU of IAB node 2 308 has not yet expired. Therefore, instead of waiting for the timer to expire and then sending the (regular) BSR corresponding to PDU B1 324, the MT of IAB node 1 306 instead sends a pre-BSR 334 to the MT of IAB node 2 308, because the pre-BSR 334 may not have the same timer restrictions as the regular BSR. Because BSR 316 has already been sent to IAB Node 1 306 (and, in some embodiments, because IAB Node 1 306 responded with UL Grant 320), the triggering conditions for using pre-BSR 334 are met (and it should be noted that IAB Node 1 306 does not necessarily need to wait for first IAB Node PDU B1 transmission 328 to occur before sending pre-BSR 334, as these previous triggering conditions may have informed it to request an UL Grant for PDU B1 324 from IAB Node 2 308). The sending of pre-BSR 334 before the expiration of the BSR timer at IAB Node 1 306 corresponding to BSR 330 may allow the DU of IAB Node 2 308 to send UL Grant 338 for PDU B1 324 to the MT of IAB Node 1 306 more quickly than in the case of a conventional BSR. Then, faster receipt of UL grant 338 for PDU B1 324 at the MT of IAB Node 1 306 may correspond to faster sending of PDU B1 324 from the MT of IAB Node 1 306 to the DU of IAB Node 2 308. In this way, signaling flow 300 is improved relative to a "pure" conventional BSR case.

[0036] As shown, the signaling flow 300 further continues with the DU of the IAB node 2 308 performing a second IAB node PDU A1 transmission 336 to the MT of the IAB node 2 308 with a corresponding BSR 342, UL grant 344, and sending PDU A1 322 between the MT of the IAB node 2 308 and the DU of the IAB donor 310. The DU of the IAB node 2 308 also performs a second PDU B1 transmission 340 to the MT of the IAB node 2 308. Here, the MT of the IAB node 2 308 may use a pre-BSR to request an UL grant for PDU B1 324 if the timer for the BSR 342 has not expired (not shown), or it may continue to request an UL grant for PDU B1 324 if the timer for the BSR 342 expires at this stage.

[0037] At the same time, UE B 302, UE A 304 and IAB node 1 306 may perform the previously performed operations for new PDU A2 354 and new PDU B2 356. Figure 3 , as illustrated by the use of BSR 346 and BSR 348, the corresponding responses to UL Grant 350 and UL Grant 352, and the corresponding transmission of PDU A2 354 and PDU B2 356.

[0038] Figure 4 4 shows a format of a medium access control (MAC) control element (MAC CE) 400 for sending a pre-BSR according to an embodiment. The MAC CE 400 includes a logical channel group (LCG) bit 402 and a buffer size bit 404. The LCG bit 402 may be used to indicate an LCG corresponding to or for a data flow. The data flow may include a first entity and a second entity corresponding to each other over time (e.g., as described with respect to FIG. 4 ). Figure 3 ) (e.g., one or more such PDUs each corresponding to a VoIP application of a UE, etc.). It is contemplated that in some embodiments, the IAB node may combine multiple incoming data streams into one or more outgoing data streams, as described in further detail below.

[0039] The LCG to which a data flow is assigned can indicate the priority of processing the data flow. For example, data that is or includes VoIP data can be assigned to a first LCG corresponding to a certain desired quality of service (QoS) level, while a data flow that is or includes Short Message Service (SMS) data can be assigned to a second LCG corresponding to a best effort (BE) indication. The first LCG can be understood as having a higher priority than the second LCG.

[0040] The buffer size bits 404 may indicate (as part of the pre-BSR message) the amount of data that the sending IAB node expects to receive (and / or has received) from the IAB node and / or UE in the manner described above.

[0041] In some embodiments, the format of the MAC CE 400 for a pre-BSR may match the format for a regular BSR.

[0042] One consideration in developing wireless communication systems using IAB is fairness. 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 more 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 receives QoS treatment for one or more of its data flows that is (in effect) similar to the QoS treatment it would receive if UE 112 were connected to, for example, a gNB of a wireless communication system (without traversing IAB network 100). Furthermore, it may be desirable to have a mechanism for preventing UE 114 from being unfairly favored relative to UE 112 due to its closer proximity (in terms of hop distance) to IAB donor 102 / 5GC 104.

[0043] Figure 5 A signaling flow 500 is shown that illustrates various fairness issues that may arise when using various pre-BSR implementations across an IAB network, according to an embodiment. These issues may correspond to variations in pre-BSR implementations based on various different vendors of IAB nodes.

[0044] The signaling flow 500 includes UE B 502, UE A 504, IAB Node 1 506, IAB Node 2 508, IAB Donor 510, and 5GC 512. Figure 3 Signaling flow 300, Figure 5The signaling flow 500 includes a BSR 514 for a DU from UE A 504 to IAB Node 1 506 and a BSR 516 for a DU from UE B 502 to IAB Node 1 506. The DU of IAB Node 1 506 responds with an UL grant 518 for UE A 504 and an UL grant 520 for UE B 502. UE A 504 transmits PDU A1 522 using the resources indicated in the UL grant 518, and UE B 502 transmits PDU B1 524 using the resources indicated in the UL grant 520. The DU of IAB Node 1 506 performs a first IAB node PDU A1 transmission 526 (corresponding to PDU A1 522) and a first IAB node PDU B1 transmission 528 (corresponding to PDU B1 524) to IAB Node 1 506. Similar to FIG. Figure 3 It is conceivable that either UE B 502 and / or UE A 504 may respectively represent a group of UEs, and / or PDU A1 522 and / or PDU B1 524 may respectively represent a group of PDUs.

[0045] IAB node 1 506 may then choose to perform a first forwarding implementation 530 with respect to forwarding PDU A1 522 and PDU B1 524. The forwarding implementation may involve using a BSR and / or pre-BSR accompanying the forwarding of the PDUs as described above. In the first such scenario using the first forwarding implementation 530, IAB node 1 506 determines not to perform a pre-BSR, but instead waits for a window to send a common BSR for both PDU A1 522 and PDU B1 524. However, in this scenario, a delay may be introduced for PDU A1 522 relative to other possible approaches.

[0046] In a second such case using the first forwarding implementation 530, the IAB node 1 506 performs a BSR for the PDU A1 522 and a pre-BSR for the PDU B1 524 during the first forwarding implementation 530. This case may correspond to Figure 3 In this case, the priority of PDU B1 524 may not be maintained. This may be because PDU A1 522 arrives before PDU B1 524 and the BSR timer expires.

[0047] In a third such scenario using the first forwarding implementation 530, the IAB node 1 506 may not have any mechanism to re-prioritize data flows using dynamic priority updates during the first forwarding implementation 530. This may not allow the IAB node 1 506 to respond to issues such as residual packet delay budget (PDB).

[0048] Downstream fairness issues also arise in situations where different forwarding implementations at different IAB nodes (e.g., corresponding to different IAB node vendors) interact. In one such scenario, IAB node 1 506 may be provided by a first vendor and may use a first forwarding implementation 530 of a first type that triggers a pre-BSR based on residual latency. IAB node 2 508 may be provided by a second vendor and may use a second forwarding implementation 532 that prioritizes (e.g., triggers a pre-BSR) based on a different algorithm that does not prioritize responding to residual latency or using a conventional BSR. In these situations, QoS performance and targets depend on the IAB implementation (and therefore may vary). Consequently, UE-side applications may receive uneven treatment across the entire IAB network represented by signaling flow 500.

[0049] Therefore, it may be beneficial to enhance existing implementations so that data flow prioritization and latency bounds can be met in IAB networks. Such modifications may allow pre-BSR to be more than just a BSR bypass mechanism. Additionally, such modifications may promote standardization of pre-BSR usage across various vendors, such as IAB nodes.

[0050] As before, UE B 502, UE A 504, and IAB node 1 506 may continue to perform the illustrated process for new PDU A2 542 and new PDU B2 544, as illustrated by the use of BSR 534 and BSR 536, the corresponding responses to UL Grant 538 and UL Grant 540, and the corresponding sending of PDU A2 542 and PDU B2 544.

[0051] A first enhancement to pre-BSR usage may be to allow an IAB node to reclassify the LCGs of one or more incoming data flows based on such pre-BSR usage. Such modifications may enable additional resolution and / or granularity in the use of priorities corresponding to outgoing LCGs compared to what is currently provided in the standard. In such a reclassification scheme, it is contemplated that the first incoming LCG for a first incoming data flow, the incoming LCG for a second incoming data flow, and the outgoing LCGs to which the first and second incoming data flows are assigned may all be different. In some embodiments, the reclassification may be performed based on configuration performed at the IAB node by the CU of the IAB donor. In some embodiments, the IAB node may perform such reclassification unilaterally.

[0052] A first approach to reclassifying incoming LCGs is to use more additional outgoing LCGs than previously envisioned. For example, a standard may limit the number of LCGs within an IAB network to 16. However, the number of data flows that a single IAB node of an IAB network may need to process may be quite large. Furthermore, the upper limit of 16 LCGs may not be sufficient to allow for a more complete set of re-prioritization that could otherwise be achieved. For example, if only 16 LCGs were available, then as multiple data flows with minor QoS variations (in some cases corresponding to a single logical channel (LCH)) propagated through the system, these flows could be aggregated into LCGs with only a coarse resolution (e.g., using the 16 available LCGs). This merging may include increasingly extensive merging as the various data flows of the IAB network travel closer to the IAB donor (due to the need to merge more and more QoS types into the 16 available LCGs). Therefore, allowing additional LCGs within the IAB network may be beneficial.

[0053] The use of additional LCGs can allow space in the IAB network for various data flows to be re-prioritized based on the latency requirements of the data flows (e.g., by reallocating to LCGs with higher priorities). In some cases, this can happen in real time at the local IAB node. In other cases, the CU of the IAB donor can reallocate LCGs based on priority needs based on the latency metrics it collects about one or more data flows. The collection of such metrics at the CU can occur via an FP1AP interface between one or more IAB nodes, which reports information related to latency metrics to the CU of the IAB donor. This configuration of CUs can address / eliminate any interoperability issues that might otherwise occur between the various IAB nodes, thereby preserving a centralized architecture.

[0054] Due to this dynamic mapping of BH RLC flows (data flows), intra-UE Logical Channel ID (LCID) prioritization and inter-UE prioritization can be achieved.

[0055] One approach for using additional LCGs in an IAB network may be to extend the MAC CE for pre-BSR to include more LCG bits than allowed by the standards. For example, a standard may specify that up to 16 bits may be used to represent an LCG in a MAC CE. Thus, more than 16 bits may be used. This may be done in the current MAC CE structure (e.g., regarding Figure 4 These bits are provided at the end of the MAC CE structure shown.

[0056] In some of these cases, the CU of the IAB donor may create a list for this extension of the LCG and broadcast it to the various IAB nodes. In some cases, this list is pre-configured to each IAB node of the IAB network. The extended list of LCGs can be based on adding new QoS parameters (e.g., beyond those previously used in the standard), thus allowing for more nuanced differentiation between different flows. In some embodiments, each IAB node of the IAB network can independently and dynamically reallocate incoming data flows to outgoing LCGs using the methods described herein (e.g., without CU intervention). In some cases, the dynamic allocation of IAB nodes can be reported to the CU of the IAB donor over the FIAP interface.

[0057] When additional LCGs are used, various new possibilities become possible. For example, under existing systems, a first conversation voice stream with a 10ms PDB might have previously been grouped in the same LCG as a second conversation voice stream with a 5ms PDB. This could result in the 10ms stream being given too high a priority or the 5ms stream being given insufficient priority. With the availability of additional LCGs, these data streams can now be grouped separately according to separate LCGs corresponding to 10ms and 5ms, respectively.

[0058] As a second example, perhaps both data flows have a PDB of 10ms. However, the IAB node determines that while it can properly service the first of the two data flows, it cannot properly service the second of the two data flows (such that the 10ms PDB can be met without upstream adjustments). Therefore, the IAB node can reassign the second of the two data flows to an outgoing data flow with an LCG that has a higher priority than the LCG of the first of the two data flows, so that its data is processed with a higher priority at the parent IAB node. This may be possible due to the additional availability of LCGs in the IAB network (even if both data flows have the same PDB).

[0059] In some embodiments, the CU sends the threshold to the downstream IAB node (or the IAB node is pre-configured with the threshold). In these cases, if there are not a threshold number of data flows with one particular QoS (e.g., a particular PDB) among the slightly different QoS being used (e.g., slightly different, but close PDBs such as 5ms and 7ms), the IAB node may initially aggregate the data flows with slightly different QoS characteristics into a single outgoing data flow (with a single LCG). Once there are a threshold number of data flows with this particular QoS (e.g., 5ms), such data flows can be disconnected and assigned their own outgoing data flows (with corresponding unique LCGs). This may be possible due to the additional availability of LCGs in the IAB network (even if both data flows have the same PDB).

[0060] A second method of reclassifying incoming LCGs may include using sub-LCGs. In other words, the system may have one set of LCGs in use, but may also extend the MAC CE for pre-BSR to include sub-LCG bits. This may be done in the current MAC CE structure (such as for Figure 4 These bits are provided at the end of the MAC CE structure shown. In some cases, this may occur at the local IAB node as determined individually. In other cases, the CU of the IAB donor may instead configure the IAB node to use a specific sub-LCG scheme.

[0061] Thus, incoming data flows with the same LCG but different sub-LCGs can be handled differently (e.g., assigned to different outgoing data flows). For example, the IAB node may interpret the first sub-LCG as having a higher priority than the second sub-LCG. In response, the IAB node may assign the first data flow to the outgoing LCG of the sub-LCG with the first higher priority, and the IAB node may assign the second data flow to the same outgoing DCG (but with the sub-LCG with the second lower priority).

[0062] In some embodiments, the size of the sub-LCG bits may be consistent for all LCGs (e.g., 4 bits). In other embodiments, the size of the sub-LCG bits may depend on the LCG with which the LCG bits are being used. For example, a first LCG (perhaps corresponding to a high QoS requirement) may be configured to use 2 sub-LCG bits, and a second LCG (perhaps corresponding to a best effort (BE) requirement) may be configured to use 8 sub-LCG bits. This may be because in the BE case, a wider range of priority variations (corresponding to more sub-LCG bits) may be allowed than in the high QoS case. The correspondence between the size of a single LCG and its sub-LCG indications may be configured by the CU, or may be a correspondence broadcast by the IAB node in question.

[0063] A third method of reclassifying incoming LCGs may be to use the buffer size itself to indicate to the parent IAB node the priority of the outgoing data flow for a particular outgoing LCG to which the incoming data flow is assigned.

[0064] This third method can use additional grants for all LCGs that continuously request pre-BSRs or BSRs exceeding a certain threshold. Therefore, a child node can request additional resources from the parent IAB node. In such cases, the parent IAB node can provide the additional resources for a period of time using the configured grants until fairness, latency, and / or congestion constraints imposed on the child IAB node are resolved.

[0065] In some embodiments of the third method, the system may extend the MAC CE for pre-BSR to include other LCG classification information bits in the buffer size area of the MAC CE in concert with the buffer size information.

[0066] In some embodiments of this third method, for each outgoing LCG, the child node may indicate the number of incoming data flows that have been assigned to the outgoing LCG (e.g., the number of aggregated incoming data flows). For each outgoing LCG, the child node may additionally indicate how many incoming LCG variants the incoming data flows assigned to the outgoing LCG represent (e.g., the number of variants of the incoming LCG that have been merged together). This allows the parent IAB node to use such aggregation and variant information to make decisions in order to determine how to prioritize the outgoing data flow (its incoming data flow) higher or lower than, for example, one or more of its other incoming data flows.

[0067] In some embodiments of this third approach, the classification (either as a threshold or as an inline request) may occur as determined solely at the local IAB node. In other cases, the IAB donor's CU may configure the IAB node in the manner described to use such other classification bits.

[0068] Figure 6 A method 600 of an IAB node of a wireless communication system according to an embodiment is shown.

[0069] The method 600 includes assigning 602 one or more incoming data flows received by the IAB node to outgoing data flows having outgoing LCGs based on an incoming LCG of each of the one or more incoming data flows, wherein the outgoing LCG indicates a priority of the outgoing data flows.

[0070] The method 600 also optionally includes assigning 604 one or more incoming data streams to a sub-LCG for outgoing LCG.

[0071] The method 600 also includes sending 606 the pre-BSR to a second IAB node of the wireless communication system using an extended MAC CE conveying the outgoing LCG corresponding to the outgoing data flow and the requested buffer size.

[0072] In some embodiments of method 600 including allocating 604, the extended MAC CE also includes an indication of a sub-LCG. In some of these embodiments, the size of the indication of the sub-LCG in the extended MAC CE corresponds to the outgoing LCG. In some of these embodiments, the sub-LCG is one of a plurality of sub-LCGs configured by an integrated access and backhaul (IAB) control unit (CU) for use with the outgoing LCG.

[0073] In some embodiments of method 600, assigning one or more incoming data flows to outgoing data flows is based on a configuration provided to the IAB node by the IAB CU.

[0074] In some embodiments of method 600, the incoming LCG of a first one of the one or more incoming data streams, the incoming LCG and the outgoing LCG of a second one of the one or more incoming data streams are all different.

[0075] In some implementations of method 600, the size of the outgoing LCG is extended beyond the range of the current MAC CE. For example, in some implementations of method 600, more than 16 bits are used to represent the outgoing LCG in the extended MAC CE.

[0076] In some embodiments of method 600, the outgoing LCG for the one or more incoming data flows is determined based on a comparison of a quantity of the one or more incoming data flows to a threshold value received from the IAB CU.

[0077] In some implementations of method 600, the extended MAC CE also indicates the number of one or more incoming data flows.

[0078] In some embodiments of method 600, the extended MAC CE also indicates the number of unique LCGs among the one or more incoming data flows.

[0079] Embodiments contemplated herein include an apparatus comprising one or more elements for performing the method 600. The apparatus may be, for example, an apparatus of the UE 900 as described below.

[0080] Embodiments contemplated herein include one or more non-transitory computer-readable media including 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 600. The non-transitory computer-readable medium may be, for example, the memory 906 of the UE 900 described below and / or the peripherals 1304, memory / storage 1314, and / or database 1320 of the component 1300 described below.

[0081] Embodiments contemplated herein include an apparatus comprising logic, modules, or circuitry operable to perform one or more elements of the method 600. The apparatus may be, for example, a UE 900 as described below.

[0082] 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 method 600. The apparatus may be, for example, a UE 900 as described below.

[0083] Embodiments contemplated herein include a signal as described in or in connection with one or more elements of method 600 .

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

[0085] Embodiments contemplated herein include a signal encoded with data as described in or in connection with one or more elements of method 600 .

[0086] Embodiments contemplated herein include a signal encoded with a datagram, packet, frame, segment, PDU, or message as described in or in connection with one or more elements of method 600.

[0087] Embodiments contemplated herein include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors causes the one or more processors to perform one or more elements of method 600 .

[0088] 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 600. These instructions may be, for example, instructions 1312 of component 1300 as described below.

[0089] A second enhancement to pre-BSR usage may be the introduction of a new priority index for LCGs in the pre-BSR MAC CE. In other words, the MAC CE can be extended to additionally include a priority index corresponding to outgoing data flows. The priority index used at the IAB node may be based on residual PDB information for outgoing data flows provided to the IAB node by the IAB donor's CU. The various fields or fields used for the priority index for outgoing LCGs at the IAB node may be updated in real time by the IAB node or CU based on current traffic conditions at the IAB node.

[0090] The priority index may include a priority field corresponding to the priority of the outgoing LCG at the IAB node. The IAB node may determine whether to increase or decrease the priority of the outgoing LCG in question. The extended MAC CE with the priority index is then used to (ultimately) signal the new priority of the outgoing LCG to the CU of the IAB donor.

[0091] The priority index may include a prioritized bit rate (PBR) corresponding to the PBR of the outgoing LCG at the IAB node. The IAB node may determine whether to increase or decrease the PBR of the outgoing LCG in question. The indication of the new PBR of the outgoing LCG is then (eventually) communicated to the IAB donor's CU using an extended MAC CE with the priority index.

[0092] The priority index may include the token bucket depth (BSD) corresponding to the BSD of the outgoing LCG at the IAB node. The IAB node may determine whether to increase or decrease the BSD of the outgoing LCG in question. The IAB donor's CU is then informed (ultimately) of the new BSD of the outgoing LCG using an extended MAC CE with the priority index. This indication can be made across UEs in both 1:1 and N:1 BH RLC configurations.

[0093] In some embodiments, the IAB node may extend the MAC CE to include a priority index for each outgoing data flow (each transmit LCG). This may allow the parent IAB node to use its own averaging algorithm based on overall system performance to propagate it back to the CU. In some cases, if the modified priority condition at the IAB node persists, the CU (using an RRC reconfiguration message, a BAP message, or a F1AP message) may modify the priority field of the priority index of the IAB node in the affected data path where the information is needed.

[0094] Figure 7 A method 700 of an IAB node of a wireless communication system according to an embodiment is shown.

[0095] The method 700 includes assigning 702 one or more incoming data flows received by the IAB node to outgoing data flows having an outgoing LCG and an outgoing priority index based on an incoming LCG of each of the one or more incoming data flows, wherein the outgoing LCG and the outgoing priority index together indicate a priority of the outgoing data flow.

[0096] The method 700 also includes sending 704 the pre-BSR to a second IAB node of the wireless communication system using an extended MAC CE conveying an outgoing LCG corresponding to the outgoing data flow, an outgoing priority index, and a requested buffer size.

[0097] In some embodiments of the method 700, assigning the one or more incoming data flows to the outgoing data flow is further based on an incoming priority index of each of the one or more incoming data flows.

[0098] In some implementations of method 700, the outgoing priority index of the outgoing LCG is determined based on PDB parameters received from the IAB CU.

[0099] In some implementations of method 700, the outgoing priority index includes one or more of a priority field, a PBR field, and a BSD field.

[0100] In some embodiments of the method 700, the outgoing priority index is selected by an integrated access and backhaul (IAB) control unit (CU) based on a configuration received from the IAB node.

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

[0102] Embodiments contemplated herein include one or more non-transitory computer-readable media including 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 700. The non-transitory computer-readable medium may be, for example, the memory 906 of the UE 900 described below and / or the peripherals 1304, memory / storage 1314, and / or database 1320 of the component 1300 described below.

[0103] Embodiments contemplated herein include an apparatus comprising logic, modules, or circuitry operable to perform one or more elements of the method 700. The apparatus may be, for example, a UE 900 as described below.

[0104] 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 method 700. The apparatus may be, for example, a UE 900 as described below.

[0105] Embodiments contemplated herein include a signal as described in or in connection with one or more elements of method 700 .

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

[0107] Embodiments contemplated herein include a signal encoded with data as described in or in connection with one or more elements of method 700 .

[0108] Embodiments contemplated herein include a signal encoded with a datagram, packet, frame, segment, PDU, or message as described in or in connection with one or more elements of method 700.

[0109] Embodiments contemplated herein include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors causes the one or more processors to perform one or more elements of method 700 .

[0110] 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 700. These instructions may be, for example, instructions 1312 of component 1300 as described below.

[0111] Imagine about Figure 6 The reclassification described is similar to Figure 7 The combination of the priority indexes described in

[15] is used.

[0112] A third enhancement to pre-BSR can be by providing additional grants. For example, in these situations, the IAB node may determine that the traffic conditions are above a threshold for the BH RLC channel or route ID corresponding to the incoming data flow (with the associated LCG). This threshold may be, for example, the maximum number of data flows received at the child IAB node that the child IAB node includes in the child IAB node's outgoing data flow as the IAB node's incoming data flow. This may correspond to unforeseen adverse conditions such as excessive delay or excessive load. The IAB node may then provide additional grants to the child node to address the unforeseen conditions. It is conceivable that the IAB node may provide additional grants to the child IAB node based on the configuration of the IAB node by the CU of the IAB donor. These additional grants can effectively increase the priority of the incoming data flow (a group of incoming data flows) from the child IAB node to the IAB node.

[0113] It is envisaged that in these cases the child IAB node may provide information to the IAB node regarding the aggregate number of BH RLC flows that are part of the child IAB node's outgoing LCG. This may represent an overall latency metric.

[0114] Using an additional authorization mechanism may allow child IAB nodes to use pre-BSR implementations without incurring (at least often) such as Figure 5 The problem of pre-BSR described in (more generally, since the additional grant results in a decrease in the frequency of pre-BSR usage)

[0115] Figure 8 A method 800 of an IAB node of a wireless communication system according to an embodiment is shown.

[0116] The method 800 includes determining 802 that a condition corresponding to an incoming data flow received from a child IAB node into an LCG is above a threshold.

[0117] The method 800 also includes providing 804 an additional UL grant for the incoming LCG to the child IAB node based on determining that the condition is above the threshold.

[0118] In some embodiments of the method 800, the threshold is configured at the IAB node by an integrated access and backhaul (IAB) control unit (CU).

[0119] In some embodiments of method 800, the condition is a number of data flows received at the child IAB node included in the incoming data flow, and the threshold is a maximum number of data flows received at the child IAB node included in the incoming data flow.

[0120] In some embodiments of method 800, the child IAB node communicates the status of the condition to the IAB node.

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

[0122] Embodiments contemplated herein include one or more non-transitory computer-readable media including 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 800. The non-transitory computer-readable medium may be, for example, the memory 906 of the UE 900 described below and / or the peripherals 1304, memory / storage 1314, and / or database 1320 of the component 1300 described below.

[0123] Embodiments contemplated herein include an apparatus comprising logic, modules, or circuitry operable to perform one or more elements of the method 800. The apparatus may be, for example, a UE 900 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 method 800. The apparatus may be, for example, a UE 900 as described below.

[0125] Embodiments contemplated herein include a signal as described in or in connection with one or more elements of method 800 .

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

[0127] Embodiments contemplated herein include a signal encoded with data as described in or in connection with one or more elements of method 800 .

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

[0129] Embodiments contemplated herein include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors causes the one or more processors to perform one or more elements of method 800 .

[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 800. These instructions may be, for example, instructions 1312 of component 1300 as described below.

[0131] Imagine about Figure 6 Reclassification of descriptions, such as Figure 7 The use of priority indexes as described in and / or as described in Figure 8 Describes the combination of additional authorized uses.

[0132] It is conceivable that, for example Figures 6 to 8 Any of the methods represented in can be used as part of an enhanced IAB (eIAB) network.

[0133] Figure 9 is a block diagram of an example UE 900 that can be configured according to various embodiments of the present disclosure, including by executing instructions corresponding to any of the example methods and / or processes described herein on a computer-readable medium. UE 900 includes one or more processors 902, a transceiver 904, a memory 906, a user interface 908, and a control interface 910.

[0134] The one or more processors 902 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 902 may include internal memory and / or may include an interface for communicating with external memory (including memory 906). The internal or external memory may store software code, programs, and / or instructions for execution by the one or more processors 902 to configure and / or facilitate the UE 900 to perform various operations, including the operations described herein. For example, execution of the instructions may configure the UE 900 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 the one or more transceivers 904, the user interface 908, and / or the control interface 910. For another example, the one or more processors 902 may execute program code stored in the memory 906 or other memory corresponding to the MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP (e.g., for NR and / or LTE). For another example, the processor 902 may execute program code stored in the memory 906 or other memory that, together with the one or more transceivers 904, implements corresponding PHY layer protocols such as orthogonal frequency division multiplexing (OFDM), orthogonal frequency division multiple access (OFDMA), and single carrier frequency division multiple access (SC-FDMA).

[0135] The memory 906 may include a memory area for the one or more processors 902 to store variables used in protocols, configurations, controls, and other functions of the UE 900 (including operations corresponding to or including any of the example methods and / or processes described herein). In addition, the memory 906 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 906 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.

[0136] The one or more transceivers 904 may include radio frequency transmitter and / or receiver circuitry that facilitates communication between the UE 900 and other equipment supporting similar wireless communication standards and / or protocols. For example, the one or more transceivers 904 may include switches, mixer circuitry, amplifier circuitry, filter circuitry, and synthesizer circuitry. Such RF circuitry may include a receive signal path having circuitry for downconverting RF signals received from a front-end module (FEM) and providing baseband signals to a baseband processor of the one or more processors 902. The RF circuitry may also include a transmit signal path having circuitry for upconverting baseband signals provided by the baseband processor and providing an RF output signal to the FEM for transmission. The FEM may include a receive signal path having circuitry configured to operate on RF signals received from one or more antennas, amplify the received signals, and provide an amplified version of the received signals to the RF circuitry for further processing. The FEM may also include a transmit signal path having circuitry configured to amplify transmit signals provided by the RF circuitry for transmission from the one or more antennas. In various embodiments, amplification through the transmit or receive signal path may be accomplished in only the RF circuitry, only the FEM, 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 and receive mode operation.

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

[0138] The user interface 908 may take various forms depending on the particular embodiment, or may not be present in the UE 900. In some embodiments, the user interface 908 includes a microphone, a speaker, a slideable button, a depressible button, a display, a touchscreen display, a mechanical or virtual keypad, a mechanical or virtual keyboard, and / or any other user interface features typically present on mobile phones. In other embodiments, the UE 900 may include a tablet computing device with a larger touchscreen display. In such embodiments, one or more of the mechanical features of the user interface 908 may be replaced with comparable or functionally equivalent virtual user interface features (e.g., a virtual keypad, virtual buttons, etc.) implemented using a touchscreen display, as will be familiar to those skilled in the art. In other embodiments, the UE 900 may be a digital computing device, such as a laptop computer, desktop computer, workstation, etc., that includes a mechanical keyboard that may be integrated, detachable, or removable depending on the particular exemplary embodiment. Such digital computing devices may also include a touchscreen display. Many exemplary embodiments of the UE 900 with a touchscreen display are capable of receiving user input, such as input related to the exemplary methods and / or processes described herein or known to those skilled in the art.

[0139] In some exemplary embodiments of the present disclosure, UE 900 may include an orientation sensor that can be used in various ways by the features and functions of UE 900. For example, UE 900 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 900. The indication signal from the orientation sensor can be used for any application executed on UE 900, 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.

[0140] The control interface 910 can take various forms depending on the particular implementation. For example, the control interface 910 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 910 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.

[0141] 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. Figure 9 The UE 900 may include further functionality, including, for example, a video and / or still image camera, a microphone, a media player and / or recorder, and the like. Furthermore, the one or more transceivers 904 may include circuitry for communicating using additional radio frequency communication standards, including Bluetooth, GPS, and / or others. Furthermore, the one or more processors 902 may execute software code stored in the memory 906 to control such additional functionality. For example, the directional velocity and / or position estimate output from the GPS receiver may be used by any application executing on the UE 900, including various exemplary methods and / or computer-readable media according to various exemplary embodiments of the present disclosure.

[0142] Figure 10 is a block diagram of an example network node 1000 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 example methods and / or processes described herein.

[0143] The network node 1000 includes one or more processors 1002, a radio network interface 1004, a memory 1006, a core network interface 1008, and other interfaces 1010. The network node 1000 may comprise, for example, a base station, an eNB, a gNB, an access node, or components thereof.

[0144] The one or more processors 1002 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 1006 may store software code, programs and / or instructions executed by the one or more processors 1002 to configure the network node 1000 to perform various operations, including the operations described herein. For example, the execution of such stored instructions may configure the network node 1000 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 1000 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 protocols used in conjunction with the radio network interface 1004 and the core network interface 1008). By way of example and not limitation, the core network interface 1008 includes an S1 interface, and the radio network interface 1004 may include a Uu interface, such as standardized by 3GPP. The memory 1006 may also store variables used in protocols, configuration, control, and other functions of the network node 1000. Thus, the memory 1006 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.

[0145] The radio network interface 1004 may include a transmitter, a receiver, a signal processor, an ASIC, an antenna, a beamforming unit, and other circuits that enable the network node 1000 to communicate with other equipment (in some embodiments, such as multiple compatible user equipment (UE)). In some embodiments, the network node 1000 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 further embodiments of the present disclosure, the radio network interface 1004 may include a PHY layer based on OFDM, OFDMA, and / or SC-FDMA technology. In some embodiments, the functionality of such a PHY layer may be provided collaboratively by the radio network interface 1004 and the one or more processors 1002.

[0146] The core network interface 1008 may include a transmitter, a receiver, and other circuits that enable the network node 1000 to communicate with other equipment in the core network (in some embodiments, such as a circuit-switched (CS) and / or packet-switched core (PS) network). In some embodiments, the core network interface 1008 may include an S1 interface standardized by 3GPP. In some embodiments, the core network interface 1008 may include one or more interfaces to one or more SGWs, MMEs, SGSNs, GGSNs, and other physical devices, including functions known to those skilled 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 layers of the core network interface 1008 may include one or more of asynchronous transfer mode (ATM), Internet Protocol (IP) over Ethernet, SDH over fiber, T1 / E1 / PDH over copper, microwave radio, or other wired or wireless transmission technologies known to those skilled in the art.

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

[0148] Exemplary system architecture

[0149] In certain embodiments, the 5G system architecture supports data connectivity and services, enabling deployment using technologies such as network function virtualization and software-defined networking. 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 location or distributed (remote) location). Modular function design allows functional reuse and enables flexible and efficient network slicing. A network function and its network function service can interact with another NF and its network function service 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 decoupled compute and 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 and local breakout traffic.

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

[0151] Figure 11 A service-based architecture 1100 in 5GS according to one embodiment is shown. As described in 3GPP TS 23.501, the service-based architecture 1100 includes NFs such as NSSF 1108, NEF 1110, NRF 1114, PCF 1112, UDM 1126, AUSF 1118, AMF 1120, and SMF 1122 for communicating with UE 1116, (R)AN 1106, UPF 1102, and DN 1104. NFs and NF services can communicate directly (referred to as direct communication) or indirectly via SCP 1124 (referred to as indirect communication). Figure 11 Also shown are the 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. Figure 11 Some exemplary functions provided by NF are shown in FIG.

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

[0153] NEF 1110 supports the exposure of capabilities and events. NF capabilities and events can be securely exposed by NEF 1110 (e.g., for third parties, application functions, and / or edge computing). NEF 1110 can use a standardized interface to UDR (Nudr) to store / retrieve information as structured data. NEF 1110 can also securely provide information from external applications to the 3GPP network, and can provide application functions to securely provide information (e.g., expected UE behavior, 5GLAN group information, and service-specific information) to the 3GPP network, where NEF 1110 can authenticate and authorize and help restrict application functions. NEF 1110 can provide internal-external information conversion by converting between information exchanged with AF 1128 and information exchanged with internal network functions. For example, NEF 1110 converts between AF service identifiers and internal 5G core information (such as DNN and S-NSSAI). NEF 1110 can handle the masking of network and user sensitive information of external AFs based on network policies. NEF 1110 can 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 the UDR. The stored information can then be accessed by NEF 1110 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 1110 can reside in the HPLMN. Depending on the operator agreement, the NEF 1110 in the HPLMN may have an interface with the NF in the VPLMN. When the UE is able to switch between the EPC and 5GC, the SCEF+NEF can be used for service exposure.

[0154] The NRF 1114 supports service discovery functionality by receiving NF discovery requests from NF instances or SCPs and providing information about the discovered NF instances to the NF instances or SCPs. The NRF 1114 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 along with their NF services. In the context of network slicing, multiple NRFs may be deployed at different levels based on network implementation, such as PLMN level (NRF configured with information about 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 the S-NSSAI). In the context of roaming, multiple NRFs may be deployed in different networks, where the NRF in the visited PLMN (called vNRF) is configured with information about the visited PLMN, and where the NRF in the home PLMN (called hNRF) is configured with information about the home PLMN, referenced by the vNRF via the N27 interface.

[0155] The PCF 1112 supports a unified policy framework to govern network behavior. The PCF 1112 provides policy rules for control plane functions to enforce them. The PCF 1112 accesses subscription information related to policy decisions in the Unified Data Repository (UDR). The PCF 1112 can access the UDR located in the same PLMN as the PCF.

[0156] The UDM 1126 supports the generation of 3GPP AKA authentication credentials, user identification processing (e.g., storage and management of the 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 registration with the serving NF (e.g., storing the service AMF for the UE and storing the service SMF for the UE's PDU session), service / session continuity (e.g., by maintaining SMF / DNN allocation for ongoing sessions), MT-SMS delivery, lawful intercept functionality (particularly in outbound roaming scenarios where the UDM is the sole point of contact for the LI), subscription management, SMS management, 5G LAN group management processing, and / or external parameter configuration (expected UE behavior parameters or network configuration parameters). To provide such functionality, the UDM 1126 uses subscription data (including authentication data) that may be stored in the UDR. In this 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. The UDM 1126 may be located in the HPLMN of the subscriber it serves and may access information from UDRs located in the same PLMN.

[0157] The AUSF 1118 supports authentication for 3GPP access and untrusted non-3GPP access. The AUSF 1118 also provides support for network slice-specific authentication and authorization.

[0158] The AMF 1120 supports termination of the 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 the LI system), transport of SMS messages between the UE and SMF, transparent proxy for routing SM messages, access authentication, access authorization, transport of SMS messages between the UE and SMSF, SEAF, location service management for regulated services, transport of location service messages between the UE and LMF and between the 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 the AMF 1120. Regardless of the number of network functions, in some embodiments, only one NAS interface instance per access network between the UE and the CN terminates at one of the network functions that implements at least NAS security and mobility management. AMF 1120 may also include policy-related functions.

[0159] In addition to the above functions, the AMF 1120 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 that is 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 UEs connected through N3IWF / TNGF; management of mobility, authentication, and separate security context states for UEs connected via non-3GPP access or via both 3GPP access and non-3GPP access; support coordinated RM management context valid on 3GPP access and non-3GPP access; and / or support dedicated CM management context for UEs connected via non-3GPP access. It may not be necessary to support all of the above functions in the instance of network slicing.

[0160] The SMF 1122 supports session management (e.g., session establishment, modification, and release, including tunnel maintenance between the UPF and AN nodes), UE IP address allocation and management (including optional authorization) (where the UE IP address may 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 locally cached information in Ethernet PDUs (e.g., the 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 the UPF to proxy ARP or IPv6 neighbor discovery or forwarding all ARP / IPv6 neighbor request traffic to the SMF for Ethernet PDU sessions), traffic steering configuration at the UPF to route traffic to the appropriate destination, 5G VN group management (e.g., maintaining the topology of the involved PSA UPFs, in which case the SMF Establish and issue N19 tunnels between UPFs, configure traffic forwarding at UPF to apply local switching and / or N6-based forwarding or N19-based forwarding), terminate the interface towards the policy control function, lawful interception (for SM events and interface to LI system), charge data collection and support charging interface, control and coordination of charging data collection at UPF, terminate the SM part of the NAS message, downlink data notification, initiator of AN-specific SM information sent to AN via AMF over N2, determination of SSC mode for the 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 1122 may include policy-related functions.

[0161] SCP 1124 includes one or more of the following functions: indirect communication; delegated discovery; message forwarding and routing to the destination NF / NF service; communication security (e.g., authorization of NF service consumers to access NF service manufacturer APIs), load balancing, monitoring, overload control, etc.; and / or optionally interacting with the 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 the SCP. In some embodiments, SCP 1124 may be deployed in a distributed manner and / or more than one SCP may be present in the communication path between NF services. SCPs may be deployed at the PLMN level, shared slice level, and slice-specific level. Operator deployment may be left to ensure that the SCP can communicate with the relevant NRFs.

[0162] UE 1116 may include a device with radio communication capabilities. For example, UE 1116 may include a smartphone (e.g., a handheld touchscreen mobile computing device that can connect to one or more cellular networks). UE 1116 may also include any mobile or non-mobile computing device, such as a personal data assistant (PDA), a pager, a laptop, a desktop computer, a wireless handheld device, or any computing device that includes a wireless communication interface. UE is also referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, or reconfigurable mobile device. UE 1116 may include an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. The IoT UE may exchange data with an MTC server or device via a PLMN, other UEs using ProSe or D2D communications, a sensor network, or an IoT network using technologies (e.g., M2M, MTC, or mMTC technologies). M2M or MTC data exchanges may be machine-initiated data exchanges. 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.

[0163] The UE 1116 may be configured to connect or communicatively couple with the (R)AN 1106 via a radio interface 1130, 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 PTT over cellular (POC) protocol, a UMTS protocol, a 3GPP LTE protocol, a 5G protocol, a NR protocol, etc. For example, the UE 1116 and the (R)AN 1106 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 the (R)AN 1106 to the UE 1116, and UL transmissions may be from the UE 1116 to the (R)AN 1106. The UE 1116 may also communicate directly with another UE (not shown) using a side link for D2D, P2P, and / or ProSe communication. 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).

[0164] The (R)AN 1106 may include one or more access nodes, which may be referred to as base stations (BSs), 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, which provide coverage within a geographic area (e.g., a cell). The (R)AN 1106 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 to a UE with a service subscription. A pico cell may cover a relatively small geographic area and may allow unrestricted access to 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.).

[0165] Although not shown, multiple RAN nodes (such as (R)AN 1106) may be used, with an Xn interface defined between two or more nodes. In some 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 1116 in connected mode (e.g., CM-CONNECTED) includes functions for managing UE mobility in connected mode between one or more (R)AN nodes. This 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.

[0166] The UPF 1102 may serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point interconnected with the DN 1104, and a branch point to support multi-donor PDU sessions. The UPF 1102 may also perform packet routing and forwarding, packet inspection, enforce the user plane portion of policy rules, lawfully 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 validation (e.g., SDF to QoS flow mapping), transport level packet marking in the uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF 1102 may include an uplink classifier to support routing of traffic flows to the data network. The DN 1104 may represent various network operator services, Internet access, or third-party services. The DN 1104 may include, for example, an application server.

[0167] Figure 12An NG-RAN architecture 1200 is shown according to one embodiment, including a 5GC 1204 and an NG-RAN 1202. The NG-RAN 1202 includes multiple gNBs (two gNBs shown are gNB 1206 and gNB 1208) connected to the 5GC 1204 via an NG interface. gNB 1206 and gNB 1208 can support FDD mode, TDD mode, or dual mode operation and are connected to each other via an Xn-C interface. As shown, gNB 1208 includes a gNB-CU 1210 connected to gNB-DU 1212 and gNB-DU 1214 via an F1 interface. gNB 1208 can include only a single gNB-DU or more than the two gNB-DUs shown. The NG interface, Xn-C interface, and F1 interface are logical interfaces.

[0168] Figure 13 is a block diagram illustrating a component 1300 capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and capable of performing any one or more of the methods discussed herein, according to some exemplary embodiments. Specifically, Figure 13 A schematic diagram of hardware resources 1302 is shown, including one or more processors 1306 (or processor cores), one or more memory / storage devices 1314, and one or more communication resources 1324, each of which may be communicatively coupled via a bus 1316. For embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 1322 may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources 1302.

[0169] Processor 1306 (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 1308 and processor 1310.

[0170] The memory / storage device 1314 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 1314 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.

[0171] The communication resources 1324 may include interconnect or network interface components or other suitable devices to communicate with one or more peripheral devices 1304 or one or more databases 1320 via the network 1318. For example, the communication resources 1324 may include wired communication components (e.g., for coupling via a universal serial bus (USB)), cellular communication components, NFC components, Components (e.g. Low power consumption), components and other communication components.

[0172] The instructions 1312 may include software, a program, an application, an applet, an application, or other executable code for causing at least one of the processors 1306 to perform any one or more of the methods discussed herein. The instructions 1312 may reside entirely or partially within at least one of the processors 1306 (e.g., within a cache memory of the processor), the memory / storage device 1314, or any suitable combination thereof. Furthermore, any portion of the instructions 1312 may be transferred to the hardware resources 1302 from any combination of the peripheral devices 1304 or the database 1320. Thus, the memory of the processor 1306, the memory / storage device 1314, the peripheral devices 1304, and the database 1320 are examples of computer-readable and machine-readable media.

[0173] 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 circuitry 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, circuitry 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 below in the Examples section.

[0174] Unless expressly stated otherwise, 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 forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the various embodiments.

[0175] 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-purpose or special-purpose computers (or other electronic devices). A computer system may include hardware components that include specific logic components for performing the operations, or may include a combination of hardware, software, and / or firmware.

[0176] It should be understood that the systems described herein include descriptions of specific embodiments. These embodiments can be combined into a single system, partially integrated 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 can be used in another embodiment. For clarity, these parameters, attributes, aspects, etc. are described only in one or more embodiments, and it should be understood that unless otherwise stated herein, these parameters, attributes, aspects, etc. can be combined with or substituted for parameters, attributes, aspects, etc. of another embodiment.

[0177] 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 authorized use should be clearly stated to users.

[0178] Although the foregoing has been described in considerable detail for purposes 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 of implementing both the processes and the apparatus described herein. The embodiments of the present invention are therefore to be considered illustrative and not restrictive, and the description is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1. A method for integrating access and backhauling an IAB node in a wireless communication system, the method comprising: assigning, based on an incoming logical channel group (LCG) of each of one or more incoming data flows received by the IAB node, the one or more incoming data flows to outgoing data flows having an outgoing LCG, wherein the outgoing LCG indicates a priority of the outgoing data flow, wherein the one or more incoming data flows are assigned to the outgoing data flows based on a configuration provided to the IAB node by an IAB control unit (CU), and wherein the outgoing LCG is determined based on a comparison of a number of the one or more incoming data flows and a threshold amount of data flows received from the IAB CU; as well as A preemptive buffer status report (pre-BSR) is sent to a second IAB node of the wireless communication system using an extended medium access control element (MAC CE), the extended MAC CE conveying the outgoing LCG corresponding to the outgoing data flow and the requested buffer size.

2. The method of claim 1, wherein an incoming LCG of a first incoming data stream of the one or more incoming data streams, an incoming LCG of a second incoming data stream of the one or more incoming data streams, and the outgoing LCG are all different.

3. The method of claim 1, wherein more than 16 bits are used to represent the outgoing LCG in the extended MAC CE.

4. The method of claim 1 , further comprising assigning the one or more incoming data flows to a sub-LCG of the outgoing LCG, and wherein the extended MAC CE further comprises an indication of the sub-LCG.

5. The method of claim 4, wherein the indicated size of the sub-LCG in the extended MAC CE corresponds to the outgoing LCG.

6. The method of claim 4, wherein the sub-LCG is one of a plurality of sub-LCGs configured by the IAB CU for use with the outgoing LCG.

7. The method of claim 1, wherein the extended MAC CE further indicates a number of the one or more incoming data flows.

8. The method of claim 1, wherein the extended MAC CE further indicates a number of unique LCGs among the one or more incoming data flows.

9. The method according to claim 1, further comprising: determining that a condition of an incoming data flow corresponding to an incoming LCG received from a child IAB node is above a threshold; as well as An additional UL grant for the incoming LCG is provided to the child IAB node based on determining that the condition is above the threshold. 10 . The method of claim 9 , wherein the threshold is configured by the IAB CU at the IAB node.

11. The method of claim 9, wherein the condition is the number of data flows received at the child IAB node included in the incoming data flow, and the threshold is a maximum number of data flows received at the child IAB node included in the incoming data flow.

12. The method of claim 9, wherein the child IAB node transmits the status of the condition to the IAB node.

13. A method for integrating access and backhauling an IAB node in a wireless communication system, the method comprising: allocating, based on an incoming logical channel group (LCG) of each of the one or more incoming data flows received by the IAB node, the one or more incoming data flows to an outgoing data flow having an outgoing LCG and an outgoing priority index, wherein the outgoing LCG and the outgoing priority index together indicate a priority of the outgoing data flow, wherein the outgoing priority index comprises one or more of a priority bit rate (PBR) field and a token bucket depth (BSD) field; and A preemptive buffer status report (pre-BSR) is sent to a second IAB node of the wireless communication system using an extended medium access control element (MAC CE), the extended MAC CE conveying the outgoing LCG corresponding to the outgoing data flow, the outgoing priority index, and the requested buffer size.

14. The method of claim 13, wherein assigning the one or more incoming data flows to the outgoing data flow is further based on an incoming priority index of each of the one or more incoming data flows.

15. The method of claim 13, wherein the outgoing priority index of the outgoing LCG is determined based on a packet delay budget (PDB) parameter received from an IAB control unit (CU). The method of claim 13 , wherein the outgoing priority index further comprises a priority field.

17. The method of claim 13, wherein the outgoing priority index is selected by the IAB node according to a configuration received from an IAB control unit (CU).

Images