Method and system for temporary and adaptive load distribution for integrated and wireless access backhaul

Abstract

A method (700) by a first central unit (CU1) (20) in an integrated access and backhaul (IAB) network includes sending (702) a first message to a second CU (CU2) (30) or receiving a first message from CU2, the first message including information indicating that a portion of offloaded traffic should be returned to CU1, the offloaded traffic having been previously offloaded from CU1 to CU2.

Description

Technical Field

[0001] The present disclosure generally relates to wireless communication, and more particularly, to systems and methods for temporary and adaptive load distribution for integrated and wireless access backhaul.

Background Art

[0002] The 3rd Generation Partnership Project (3GPP) has completed integrated access and wireless access backhaul in New Radio (IAB) Rel-16 and is currently proceeding with the standardization of IAB Rel-17.

[0003] By using the short-distance millimeter wave spectrum for New Radio (NR), high-density deployment by multi-hop backhauling is required. However, laying optical fibers for all base stations is too costly and sometimes impossible (such as historical locations). The main principle of IAB is to use a wireless link (instead of fiber) for the backhaul, so that cells can be arranged flexibly and densely without increasing the density of the transport network. The use case scenarios of IAB include coverage expansion, deployment of a large number of small cells, and fixed wireless access (FWA) (such as access to residential and office buildings). Since the bandwidth available for NR in the millimeter wave spectrum is wide, opportunities for self-backhauling can be obtained without restricting the spectrum used for the access link. Moreover, the support for multi-beam and MIMO (Multiple Input Multiple Output) inherently possessed by NR reduces the cross-link interference between the backhaul and the access link, enabling high density.

[0004] At the stage of the IAB research project, it has been agreed to adopt a solution that utilizes the central unit (CU) / distributed unit (DU) separation architecture of NR. Here, the IAB node hosts a DU part that is controlled by a central unit. See 3GPP TR 38.874. The IAB node also has mobile termination (MT) used for communication with the parent node.

[0005] The IAB specification endeavors to reuse existing functions and interfaces defined in NR. In particular, MT, gNodeB - distributed unit (gNB - DU), gNodeB - central unit (gNB - CU), user plane function (UPF), application management function (AMF), and session management function (SMF), as well as the corresponding interfaces NR Uu (between MT and gNB), F1, NG, X2, and N4, are used as the baseline of the IAB architecture. Changes or extensions to these functions and interfaces to support IAB are described in the architecture discussion below. Additional functions such as multi - hop forwarding are necessary to understand the operation of IAB and may require standardization in some aspects, so they are included in the architecture discussion.

[0006] The MT function is defined as a component of the IAB node. In this study, MT is resident in the IAB node and is called the function that terminates the radio interface layer of the backhaul Uu interface towards the IAB donor or other IAB nodes.

[0007] Figure 1 is a high-level architecture diagram of the IAB network. Specifically, Figure 1 is a reference diagram of IAB in the stand-alone mode discussed in 3GPP TR 38.874. The IAB network includes one IAB donor and multiple IAB nodes. The IAB donor is treated as one logical node composed of a series of functions such as gNodeB-DU (gNB-DU), gNodeB-CPU control plane (gNB-CPU-CP), gNodeB-CPU user plane (gNB-CPU-UP), and potentially other functions. In terms of placement, the IAB donor can be split according to these functions and can be placed either co-located or non-co-located as permitted in the 3GPP NG-RAN architecture. When such separation is used, situations related to IAB may occur. Also, if it becomes clear that some of the functions currently carried out by the IAB donor are not IAB-specific tasks, they may be moved outside the donor in the future.

[0008] Figure 2 is a diagram showing the baseline user plane (UP) protocol stack of IAB in Rel-16, and Figure 3 is a diagram showing the baseline control plane (CP) protocol stack of IAB in Rel-16.

[0009] As described above, the selected protocol stack reuses the current CU-DU split specification of Rel-15. The full user plane F1-U (GTP-U / UDP / IP) is terminated at the IAB node (like a normal DU), and the full control plane F1-C (F1-AP / SCTP / IP) is also terminated at the IAB node (like a normal DU). In the above case, network domain security (NDS) is adopted to protect the traffic of both UP and CP (IPsec for UP and datagram transport layer security (DTLS) for CP). It is also possible to use IPsec for CP protection instead of DTLS (in this case, the DTLS layer is not used).

[0010] A new protocol layer called Backhaul Adaptation Protocol (BAP) is introduced in IAB nodes and IAB donors and is used for routing packets to appropriate downstream / upstream nodes. In addition, to meet the end-to-end Quality of Service (QoS) requirements of the bearer, the bearer data of the User Equipment (UE) is mapped to an appropriate backhaul Radio Link Control (RLC) channel (further, it is also mapped between the incoming / outgoing backhaul RLC channels of intermediate IAB nodes). Therefore, the BAP layer is responsible for processing the backhaul (BH) RLC channels, for example, mapping the incoming BH RLC channel from a parent / child IAB node to the outgoing BH RLC channel of the link towards the child / parent IAB node. In particular, one BH RLC channel can transmit end-user traffic for multiple Data Radio Bearers (DRBs) and different User Equipments (UEs) that may be connected to different IAB nodes in the network.

[0011] 3GPP provides two possible configurations for the BH RLC channel. The first configuration involves a 1:1 mapping between the BH RLC channel and a specific user's DRB. The second configuration involves an N:1 bearer mapping where N DRBs that may be associated with different UEs are mapped to one BH RLC channel. In the first case, since there is a 1:1 mapping between the QoS of the BH RLC channel and the QoS of the associated DRB, it can be easily processed by the scheduler of the IAB node. However, such a 1:1 configuration is not easily scalable when the IAB node is serving a large number of UEs / DRBs. On the other hand, the N:1 configuration is more flexible / scalable, but since the amount of DRBs / UEs provided by one BH RLC channel may be different from that provided by another BH RLC channel, it may be difficult to ensure fairness between the various provided BH RLC channels. : 1 bearer mapping. In the first case, since there is a 1:1 mapping between the QoS of the BH RLC channel Requirement and the QoS of the associated DRB, Requirement it can be easily processed by the scheduler of the IAB node. However, such a 1:1 configuration is not easily scalable when the IAB node is serving a large number of UEs / DRBs. On the other hand, : the N:1 configuration is more flexible / scalable, but since the amount of DRBs / UEs provided by one BH RLC channel may be different from that provided by another BH RLC channel, it may be difficult to ensure fairness between the various provided BH RLC channels.

[0012] On the IAB node, the BAP sublayer includes one BAP entity for the MT function and another co-located BAP entity for the DU function. On the IAB donor DU, the BAP sublayer includes only one BAP entity. Each BAP entity has a transmitting part and a receiving part. The transmitting part of the BAP entity has a corresponding receiving part of the BAP entity of the IAB node or the IAB donor DU via the backhaul link.

[0013] Figure 4 shows an example of the functional diagram of the BAP sublayer. This figure is based on the radio interface protocol architecture defined in 3GPP TS 38.300, but this functional diagram does not limit the implementation. In the example of Figure 4, the receiving part on the BAP entity distributes the BAP protocol data unit (PDU) to the transmitting part on the co-located BAP entity. Alternatively, the receiving part may distribute the BAP service data unit (SDU) to the co-located transmitting part. When delivering the BAP SDU, the receiving part deletes the BAP header, and the transmitting part adds the same BAP routing ID as that included in the BAP PDU header before deletion to the BAP header. Therefore, delivering the BAP SDU in this way is functionally equivalent to delivering the BAP PDU in terms of implementation.

[0014] The following services are provided by the BAP sublayer to the upper layer. - Data transfer,

[0015] The BAP sublayer expects the following services from the lower layer for each RLC entity (see 3GPP TS 38.322 for detailed description): - Acknowledged data transfer service, - Unacknowledged data transfer service.

[0016] The BAP sublayer supports the following functions: - Data transfer, - Determination of the BAP destination and path for packets from the upper layer, - Determination of the outgoing BH RLC channel for the packet to be routed to the next hop, - Packet routing to the next hop, - Identification of traffic delivered to the upper layer and traffic delivered to the outgoing link, - Feedback and polling signaling for flow control.

[0017] Therefore, the BAP layer is important for determining how to route received packets. For the downstream, this means determining whether the packet has reached the final destination. In that case, the packet is sent to the UE connected to this IAB node as an access node or transferred to another IAB node on the correct path. In the first case, the BAP layer delivers the packet to the upper layer within the IAB node. This upper layer maps the packet to various QoS flows and maps the DRB contained in the packet. In the second case, instead, the BAP layer determines the appropriate outgoing BH RLC channel based on the BAP destination, path ID, and incoming BH RLC channel. The above description also applies to the upstream, except that the final destination is always a specific donor DU / CU. To achieve the above tasks, the BAP layer of the IAB node needs to set up a routing table that maps different incoming and outgoing RLC channels depending on the specific BAP destination and the path of the packet. Therefore, the BAP destination and path identifier (ID) are included in the header of the BAP packet so that the BAP layer can determine the transfer destination of the packet.

[0018] Furthermore, the BAP layer also plays an important role in hop-by-hop flow control. In particular, a child node can notify its parent node about potential congestion that may occur locally at the child node so that the parent node can adjust the traffic directed towards the child node. The parent node can also use the BAP layer to notify the child node when the parent node experiences a radio link failure (RLF) problem so that the child node can re-establish a connection with another parent node.

[0019] Topology adaptation in an IAB network may be required for various reasons such as changes in radio conditions, changes in the load of the serving CU, radio link failures, etc. As a result of IAB topology adaptation, an IAB node may be migrated (i.e., handed over) to a new parent (which may be controlled by the same CU or a different CU), or a portion of the traffic currently served by such an IAB node may be offloaded via a new route (which may be controlled by the same CU or a different CU). If the new parent of that IAB node is under the control of the same CU or a different CU, the migration is an in-donor migration and an inter-donor migration, respectively (also referred to as in-CU migration and inter-CU migration in this specification).

[0020] Figure 5 shows examples of several different possible IAB node migration (i.e., topology adaptation) scenarios for IAB topology adaptation. The scenarios are arranged in order of complexity.

[0021] In case (A) within the CU, the IAB node (e) is moved to a new parent node (IAB node (b)) under the control of the same donor DU (1) together with the UE providing the service. To successfully perform the migration within the DU, it is necessary to establish the MT UE context setup of the IAB node (e) within the DU of the new parent node (IAB node (b)), update the routing table of the IAB nodes in the path to the IAB node (e), and allocate resources to the new path. The IP address of the IAB node (e) is not changed, but the F1-U tunnel / connection between the donor CU (1) and the DU of the IAB node (e) is redirected via the IAB node (b).

[0022] The procedure requirements / complexity of case (B) within the CU are the same as those of case (A). Also, since the new IAB donor DU (i.e., DU2) is connected to the same L2 network, the IAB node (e) can use the same IP address under the new donor DU. However, the new donor DU (i.e., DU2) needs to notify the network using the L2 address of the IAB node (e) in order to obtain / maintain the same IP address for the IAB node (e) using a mechanism such as ARP (Address Resolution Protocol).

[0023] Case (C) within the CU is more complex than case (A) because it is necessary to assign a new IP address to the IAB node (e). When IPsec is used to protect the F1-U tunnel / connection between the donor CU (1) and the IAB node (e) DU, it may be possible to use the existing IP address for the path segment between the donor CU (1) and the security gateway (SeGW), and use the new IP address for the IPsec tunnel between the SeGW and the IAB node (e) DU.

[0024] Case (D) between CUs is the most complex case in terms of procedure requirements, and new specification procedures (such as enhanced RRC, F1AP, XnAP, Ng signaling, etc.) beyond the scope of 3GPP Rel-16 may be required.

[0025] In the 3GPP Rel-16 specification, only the procedures for in-CU migration are considered. For inter-CU migration, since the IAB node operation can continue at the target CU and the QoS does not degrade, new signaling procedures are required between the source CU and the target CU to migrate the context of the IAB node and its traffic to the target CU. Inter-CU migration will be specified in 3GPP Rel17.

[0026] During in-CU topology adaptation, both the source and target parent nodes receive services from the same IAB-donor CU. The target parent node can use a different IAB donor DU from the source parent node. The source path may further have common nodes with the target path.

[0027] Figure 6 is a diagram showing an example of the topology adaptation procedure when the target parent node uses a different IAB-donor DU from the source parent node. As shown in the figure, the in-IAB CU topology adaptation procedure includes the following. 1. The migrating IAB-MT sends a MeasurementReport message to the source parent node IAB-DU. This report is based on the measurement configuration that the migrating IAB-MT previously received from the IAB donor CU. 2. The source parent node IAB-DU sends a UL RRC MESSAGE TRANSFER message to the IAB donor CU to carry the received MeasurementReport. 3. The IAB donor CU generates the UE context of the migrating IAB-MT and sends a UE CONTEXT SETUP REQUEST message to the target parent node IAB-DU to set up one or more bearers. These bearers can be used by the migrating IAB-MT for its signaling and, optionally, for data traffic. 4. The target parent node IAB-DU responds to the IAB donor CU in a UE CONTEXT SETUP RESPONSE message. 5. The IAB donor CU sends a UE CONTEXT MODIFICATION REQUEST message containing the generated RRCReconfiguration message to the source parent node IAB-DU. The RRCReconfiguration message includes the default BH RLC channel for UL F1-C / non-F1 traffic mapping on the target path and the default BAP routing ID setting. It can also include additional BH RLC channels. This step includes the allocation of (one or more) TNL addresses that can be routed via the target IAB donor DU. Possible . Instead of (one or more) TNL addresses that can be routed via the source IAB donor DU, (one or more) new TNL addresses may be included in the RRCReconfiguration message. When the IPsec tunnel mode is used to protect F1 and non-F1 traffic, the allocated TNL address is the outer IP address. When the source path and the target path use the same IAB donor DU, the replacement of the TNL address is not required. The Transmission Action Indicator of the UE context modification request message indicates to stop data transmission to the migrating IAB node. 6. The source parent node IAB-DU transfers the received RRCReconfiguration message to the migrating IAB-MT. 7. The source parent node IAB-DU responds to the IAB donor CU in a UE CONTEXT MODIFICATION RESPONSE message. 8. A random access procedure is executed at the target parent node IAB-DU. 9. The migrating IAB-MT responds to the target parent node IAB-DU in an RRCReconfigurationComplete message. 10. The target parent node IAB-DU sends a UL RRC MESSAGE TRANSFER message to the IAB donor CU to carry the received RRCReconfigurationComplete message. Also, it can send uplink packets from the migrating IAB-MT, and these packets are transferred to the IAB donor CU via the target parent node IAB - DU. These UL packets belong to the signaling of the IAB-MT itself (and optionally to the data traffic). 11. The IAB donor CU configures the BHRLC channel and the BAP sublayer routing entry on the target path between the target parent IAB node and the target IAB donor DU, and configures the DL mapping on the target IAB donor DU for the target path of the migrating IAB node. These configurations may be performed at an earlier stage, for example, immediately after step 3. The IAB donor CU can establish an additional BH RLC channel for the migrating IAB-MT using the RRC message. 12. The F1-C connection is switched to use the new TNL address(es) of the migrating IAB node(s), and the IAB donor CU updates the UL BH information associated with each GTP tunnel to the migrating IAB node. This step may also update the UL FTEID and DL FTEID associated with each GTP tunnel. All F1-U tunnels are switched to use the new TNL address(es) of the migrating IAB node(s). This step may use non-UE related signaling in the E1 and / or F1 interface to provide an updated UP configuration for the F1-U tunnels of multiple connected UEs or child IAB-MTs. The IAB donor CU can also update the UL BH information related to non-UP traffic. In implementation, it is necessary to avoid potential race conditions, that is, to ensure that conflicting configurations are not executed simultaneously using UE-related procedures and non-UE related procedures. 13. The IAB donor CU sends a UE context release command (UL CONTEXT RELEASE COMMAND) message to the source parent node IAB-DU. 14. The source parent node IAB-DU releases the context of the migrating IAB-MT and responds to the IAB donor CU with a UE context release complete (UL CONTEXT RELEASE COMPLETE) message. 15. The IAB donor CU releases the BH RLC channel and the BAP sublayer routing entry on the source path between the source parent IAB node and the source IAB donor DU.

[0028] Note: If the source path and the target path have common nodes, the BH RLC channels and BAP sublayer routing entries of those nodes may not need to be released in step 15.

[0029] Steps 11, 12, and 15 need to be executed as follows for the descendant nodes of the migrating IAB node. · The IAB donor CU can allocate one or more new TNL addresses that can be routed via the target IAB donor DU to the descendant nodes by means of an RRCReconfiguration message. · If necessary, the IAB donor CU can also provide the descendant nodes with a new default UL mapping including the default BH RLC channel and the default BAP routing ID for UL F1-C / non-F1 traffic on the target path by means of an RRCReconfiguration message. · If necessary, the IAB donor CU configures the BH RLC channel, the BAP-sublayer routing entry on the target path of the descendant nodes, and the BH RLC channel mapping on the descendant nodes in the same way as described for the migrating IAB node in step 11. · The descendant nodes switch the F1-C connection and the F1-U tunnel to the new TNL address fixed to the new IAB-donor DU in the same way as described for the migrating IAB node in step 12. Depending on the implementation, these steps can be executed after the handover of the migrating IAB node or in parallel with the handover.

[0030] Note: In the upstream direction, the in-flight packets between the source parent node and the IAB donor CU can be delivered even after the target path is established.

[0031] Note: Until the implementation using the NR user plane protocol (3GPP TS 38.425), the in-flight downlink data of the source path can be discarded.

[0032] Note: The IAB donor CU can determine, depending on the implementation, the downlink data that failed to be transmitted on the backhaul link.

[0033] As described above, in 3GPP Rel-16, only the CU-internal topology adaptation procedure is standardized. Considering that the CU-to-CU migration is an important function in the IAB Rel-17 work item, it is necessary to enhance the existing procedure to reduce the service interruption and signaling load (due to the IAB node migration).

[0034] The use cases of the donor-to-donor topology adaptation (also known as CU-to-CU migration) are as follows. · One possible scenario for load distribution among donors is that the link between an IAB node and its parent node becomes congested. In this case, traffic below the IAB node (referred to here as the top-level IAB node) and throughout the network branch containing the IAB node can be redirected to reach the top-level node via another route. If the new route for the offloaded traffic involves traversing the network under another donor before reaching the top-level node, the scenario is inter-donor routing. The offloaded traffic can include both traffic that terminates at the top-level IAB node and the UEs served by it, or traffic that passes through the top-level IAB node and terminates at its descendant IAB nodes and UEs. In this case, the MT of the top-level IAB node (i.e., the top-level IAB-MT) can establish an RRC connection to another donor (thus releasing the RRC connection to the old donor), and traffic destined for this node and its descendant devices will now be sent via the new donor. · For RLF recovery between donors, an IAB node that experiences RLF on its own parent link attempts to re-establish RRC towards a new parent of another donor (this node is also referred to as the top-level IAB node). According to the 3GPP decision, if the descendant IAB nodes and UEs of the top-level node "follow" the new donor, the parent-child relationship is maintained even after the top-level node connects to another donor.

[0035] The above cases assume that the IAB-MT of the top-level node can only be connected to one donor at a time. However, in the Rel-17 work, the case where the top-level IAB-MT can be connected to two donors simultaneously will also be considered in the following situations. · For load distribution, traffic reaching the top-level IAB node via one leg can be offloaded to reach the top-level IAB node (and potentially its descendant nodes) via another leg established by the node to another donor. · For RLF recovery, traffic reaching the top-level IAB node via a broken leg can be redirected to another donor as described above to reach that node via a "good" leg.

[0036] Regarding donor - to - donor topology adaptation, two options will be allowed in the 3GPP Rel - 17 specification. · Proxy - based solution: Assuming that the top - level IAB - MT can connect to only one donor at a time, while the top - level IAB - MT migrates to a new donor, the F1 and RRC connections of the co - located IAB - DU and all descendant IAB - MTs, IAB - DUs, and UEs remain fixed to the old donor even after donor - to - donor topology adaptation. · The proxy - based solution is also applicable when the top - level IAB - MT is connected to two donors simultaneously. In this case, some or all of the traffic terminating at the top - level node is offloaded via a leg towards the "other" donor. · Full - migration - based solution: All F1 and RRC connections of the top - level node and its descendant devices and UEs are moved to the new donor. Details of both solutions are currently under discussion in 3GPP.

[0037] One problem with the full - migration - based solution for CU - to - CU migration is that a new F1 connection is established from IAB node E to the new CU (i.e., CU(2)), and the old F1 connection to the old CU (i.e., CU(1)) is released.

[0038] The release and rearrangement of the F1 connection affect all UEs (i.e., UE c , UE d , and UE e ) and descendant IAB nodes (and the UEs receiving their services). 1. Service interruption to UEs and IAB nodes provided by the top-level IAB node (i.e., IAB node E). This is because these UEs may need to re-establish their connections or perform handover operations. (Even if these UEs continue to exist under the same IAB node, according to the 3GPP security principle, every time the serving CU / gNB changes (e.g., during handover or re-establishment), it is obligatory to perform key refresh, that is, it is necessary to send RRC reconfiguration using reconfigurationWithSync to each UE.) 2. A signaling storm occurs because a large number of UEs, IAB-MTs, and IAB-DUs need to perform re-establishment or handover simultaneously.

[0039] Furthermore, according to certain embodiments, it may be preferable to avoid reconfiguring the descendant nodes of the top-level node. That is, it is desirable for the descendant nodes not to know the fact that traffic is proxied via CU2.

[0040] To address these problems, a proxy-based mechanism has been proposed to perform CU-to-CU migration without handing over UEs or IAB nodes directly or indirectly served by the top-level IAB node, thereby making the handover of UEs directly and indirectly served transparent to the target CU. In particular, only the radio resource control (RRC) connection of the top-level IAB node is transferred to the target CU, and the CU-side termination of its F1 connection, and the CU-side terminations of the F1 and RRC connections of the IAB nodes and UEs directly and indirectly served are retained by the source CU. In this case, the target CU functions as a proxy for those F1 and RRC connections held by the source CU. Therefore, in this case, the target CU only needs to ensure that the ancestor node of the top-level IAB node is appropriately configured to handle traffic from the top-level node to the target donor and from the target donor to the top-level node. On the other hand, the configuration of the descendant IAB nodes of the top-level node remains under the control of the source donor. Therefore, in this case, the target donor does not need to know the network topology, QoS requirements, or the configuration of the descendant IAB nodes or UEs.

[0041] Figure 7 shows an example of the signal flow before the migration of IAB node 3. Figure 8 shows an example of the signal flow after the migration of IAB node 3. Specifically, Figure 7 shows the signaling connection when the F1 connection is maintained at CU-1, and Figure 8 emphasizes the way in which F1-U is tunneled over Xn and transparently transferred to IAB donor DU-2 after the IAB node is moved to the target donor CU (i.e., CU2).

[0042] Figure 9 shows an example of a proxy-based solution for load distribution between donors. Specifically, IAB3 and its descendant node IAB4, and the UEs served by these two IAB nodes are involved in the solution.

[0043] When applied to the scenario of Figure 9, the proxy-based solution operates as follows. · IAB3-MT changes the RRC connection (i.e., association) from CU1 to CU2. · On the other hand, while the RRC connections of IAB4-MT and all UEs served by IAB3 and IAB4, and the F1 connections of IAB3-DU and IAB4-DU remain fixed to CU1 (i.e., are not moved to CU2), the corresponding traffic of these connections is transmitted and received between IAB3 / IAB4 and the UEs they serve using a path via CU2.

[0044] Therefore, the traffic that was being sent from the source donor (i.e., CU1 in FIGS. 2 to 9) to the top-level IAB node (IAB3) and its descendants (such as IAB4) is offloaded (i.e., proxied) via CU2. Specifically, · The old traffic path from CU1 to IAB4, i.e., CU1 - donor DU1 - IAB2 - IAB3 - IAB4, is changed to CU1 - donor DU_2 - IAB5 - IAB3 - IAB4 for load balancing purposes.

[0045] Here, instead of an indirect routing such as CU1 - CU2 - donor DU1 - etc., a direct routing between CU1 and donor DU_2 is applied (i.e., CU1 - donor DU1 - etc......). The direct routing can be supported, for example, using IP routing between (source donor) CU1 and donor DU2 (target donor DU), or using an Xn connection between the two. In indirect routing, data can be sent between CU1 - CU2 via the Xn interface and between CU2 - donor DU_2 via F1 or IP routing. Both direct routing and indirect routing are applicable to the embodiments described herein. The advantage of direct routing is that the delay is likely to be smaller.

[0046] 3GPP defines a Dual Active Protocol Stack (DAPS) handover procedure that maintains the connection of the source gNB after receiving an RRC message (HO command) for handover and until the source cell is released after a successful random access to the target gNB.

[0047] DAPS handover can be used for RLC-AM or RLC-UM bearers. For DRBs configured with DAPS, the following additional principles apply.

[0048] Regarding the downlink: - During the preparation of HO, the transfer tunnel is always established. - The source gNB is responsible for allocating the downlink PDCP (Packet Data Convergence Protocol) sequence number (SN) until the SN allocation is handed over to the target gNB and data transfer is performed. That is, the source gNB does not stop allocating PDCP SN to downlink packets until it receives a HANDOVER SUCCESS message and sends an SN STATUS TRANSFER message to the target gNB. - When the downlink PDCP SN is allocated by the source gNB, the source gNB starts scheduling downlink data on the source radio link and also starts transferring the downlink PDCP SDU to the target gNB together with the allocated PDCP SN. - For security synchronization, the hyperframe number (HFN) is maintained for the transferred downlink SDU with the PDCP SN allocated by the source gNB. The source gNB sends an EARLY STATUS TRANSFER message to carry the DL COUNT value indicating the PDCP SN and HFN of the first PDCP SDU to be transferred to the target gNB. - The HFN and PDCP SN are maintained even after the SN allocation is handed over to the target gNB. The SN STATUS TRANSFER message also indicates the next DL PDCP SN to be allocated to packets that do not yet have a PDCP sequence number for RLC-UM (Radio Link Control-Unacknowledge Mode). - During the handover execution period, the source gNB and the target gNB perform robust header compression (ROHC), encryption, and addition of the PDCP header individually. - During the handover execution period, the UE continues to receive downlink data from both the source and target gNBs until the source gNB connection is released by an explicit release command from the target gNB. - During the handover execution period, the PDCP entity of the UE configured with DAPS maintains separate security functions and ROHC header decompression functions associated with each gNB while maintaining common functions for reordering, duplicate detection and discard, and sequential delivery of PDCP SDUs to the upper layer. The continuity of the PDCP SN is supported by both RLC AM and UM DRB configured with DAPS.

[0049] Regarding the uplink: - The UE transmits UL data to the source gNB until the random access procedure to the target gNB is successfully completed. Thereafter, the UE switches the UL data transmission to the target gNB. - Even after switching the UL data transmission towards the target gNB, the UE continues to transmit UL layer 1 channel state information (CSI) feedback, hybrid automatic repeat request (HARQ) feedback, layer 2 radio link control (RLC) feedback, ROHC feedback, HARQ data retransmission, and RLC data retransmission to the source gNB. - During the handover execution period, the UE maintains separate security contexts and ROHC header compression contexts for uplink transmissions towards the source and target gNBs. The UE maintains a common UL PDCP SN assignment. The continuity of the PDCP SN is supported by both radio link control acknowledged mode (RLC AM) and RLC-UM DRB configured with dual active protocol stack (DAPS). - During the handover execution period, the source and target gNBs maintain their own security and ROHC header decompression contexts to process the UL data received from the UE. - The establishment of the transfer tunnel is optional. - The HFN and PDCP SN are maintained at the target gNB. The SN STATUS TRANSFER message indicates the COUNT of the first missing PDCP SDU for which the target should start delivery even if it is RLC-UM.

[0050] At the RAN3#110-e meeting, RAN3 agreed that potential solutions for simultaneous connection to two donors could include solutions "like DAPS". In this regard, a solution called Dual IAB Protocol Stack (DIPS) has been proposed in 3GPP. Figure 10 shows an example of the DIPS solution.

[0051] DIPS is based on the following. · Two independent protocol stacks, each connecting to a different CU, which may include Radio Link Control (RLC) / Medium Access Control (MAC) / Physical Layer (PHY). · One or two independent BAP entities with some common functions and some independent functions. · Each CU allocates its own resources (address, BH RLC channel, etc.) without the need for coordination and also configures each protocol stack.

[0052] In short, this solution has two protocol stacks like DAPS, but differs in that there is a BAP entity instead of the PDCP layer. It is also possible to make the set of BAP functions common and keep another set of functions independent for each parent node.

[0053] This type of solution minimizes complexity and achieves all the goals of the work item. Because · Each protocol stack can be configured individually using current signaling and procedures, thus improving robustness. Minimal signaling updates may be required. · Only the top-level IAB nodes are reconfigured. For other nodes and UEs, it is all transparent and no reconfiguration is required, thus reducing the signaling load and improving robustness. · Since data can continue to flow on the first link until the second link is set up, service interruption can be eliminated. · Adjustment of the IP / BAP address and route ID between CUs is no longer necessary, significantly reducing complexity and network signaling.

[0054] When the CU determines that load distribution is required, the CU starts a procedure to request that a part of the traffic of a specific (i.e., top-level) IAB node be offloaded to the second CU resource. The CU negotiates the configuration, and the second CU prepares the configuration to be applied to the second protocol stack of the IAB-MT, the RLC backhaul channel, the BAP address, etc.

[0055] The top-level IAB-MT routes specific traffic to the first or second CU using the routing rules provided by the CU. In the DL, the IAB-MT converts the BAP address from the second CU to the BAP address from the first CU in order to reach the nodes under the control of the first CU.

[0056] This all means that only the top-level IAB nodes (the IAB nodes to which the traffic is offloaded) are affected, and other nodes and UEs are unaware of this situation. All of these procedures can be executed with the current signaling with only minor modifications.

[0057] Figure 11 shows two scenarios regarding donor-to-donor topology redundancy agreed upon in RAN3. Specifically, the two scenarios regarding donor-to-donor topology redundancy include the following. - Scenario 1: The IAB is multi-connected to two donors. - Scenario 2: The parent / ancestor node of the IAB is multi-connected to two donors.

[0058] In these two scenarios, RAN3 uses the following terms. - Boundary IAB node: This node is, for example, IAB3 in the figure above, and accesses two different parent nodes each connected to two different donor CUs. - Descendant IAB node: A (one or more) node that accesses the network via a boundary IAB node, and each node is singly connected to a parent node. For example, IAB4 in scenario 2. - F1 termination node: A donor CU that terminates the F1 interface of a boundary IAB node and (one or more) descendant nodes. - Non-F1 termination node: A CU with a donor function that does not terminate the F1 interface of a boundary IAB node and (one or more) descendant nodes.

[0059] However, currently, there are certain (one or more) problems. For example, as described above, adaptation of the topology can be achieved by using a proxy-based solution (currently called partial donor-to-donor handover in 3GPP), in which case, for the scenario shown in Figure 9, the top-level IAB3-MT changes its RRC connection (i.e., association) from CU1 to CU2. On the other hand, while the RRC connections of IAB4-MT and all UEs served by IAB3 and IAB4, and the F1 connections of IAB3-DU and IAB4-DU remain fixed to CU1, the corresponding traffic of these connections will be transmitted and received between IAB3 / IAB4 and the UEs they serve using a new path (as described above).

[0060] However, the following should be considered. · The need to offload traffic to another donor is temporary (e.g., during peak hours of a day), and it is expected that after a while, the traffic will be able to return to the network of the original donor. · Also, millimeter-wave links are generally very stable, and interruptions are expected to be rare and short-lived. In that sense, if the factor for topology adaptation was RLF recovery between donors, it is expected that it will be possible to (re)establish a stable link to the (old) parent under the old donor.

[0061] Previous methods have included canceling proxy-based load distribution to another CU. The following scenarios were addressed. · For a top-level node connected to a certain donor, canceling traffic, i.e., undoing the configuration of traffic offloading to another donor (e.g., by a proxy-based approach for both load distribution and RLF recovery between donors), i.e., returning traffic from a (one or more) proxied path under the first donor (e.g., the first CU (CU1)) to the (one or more) original paths under the first donor (e.g., the first CU (CU1)). · For the case where the top-level node is connected to two donors simultaneously, canceling traffic offloading to another CU. The offloaded traffic is moved to go from the leg of the top-level node towards the second donor (e.g., CU2) and returned to the original leg to go towards the first donor (e.g., CU1).

[0062] However, after offloading is set up and starts to function, the method for enabling the following is unknown. · CU1 offloading additional traffic to CU2, · Instead of CU1 dealing with a complete cancellation of offloading, CU1 canceling the offloading of a part of the traffic that was previously offloaded to CU2. · CU2 requesting CU1 to cancel offloading for a part of the traffic of CU1 that CU2 cannot handle for some reason, such as congestion in the network under the CU2 domain.

Summary of the Invention

[0063] Certain aspects of the present disclosure and their embodiments can provide solutions to these problems or other problems. For example, certain embodiments disclosed herein relate to methods and systems for requiring CU2 to update one or more parameters of a previously executed migration (complete migration or proxy-based migration) by CU1. As another example, certain embodiments relate to methods and systems for requiring CU1 to update one or more parameters of a previously executed migration (complete migration or proxy-based migration) by CU2.

[0064] According to certain embodiments, a method by CU1 in an IAB network includes transmitting a first message to CU2 or receiving a first message from CU2. The first message includes information indicating that a portion of the offloaded traffic is to be returned to CU1. The offloaded traffic was previously offloaded from CU1 to CU2.

[0065] According to certain embodiments, CU1 in an IAB network is configured to transmit a first message to CU2 or receive a first message from CU2. The first message includes information indicating that a portion of the offloaded traffic is to be returned to CU1. The offloaded traffic was previously offloaded from CU1 to CU2.

[0066] According to certain embodiments, a method by CU2 in an IAB network includes transmitting a first message to CU1 or receiving a first message from CU1. The first message has information indicating that a portion of the offloaded traffic is to be returned to CU1. The offloaded traffic was previously offloaded from CU1 to CU2.

[0067] According to certain embodiments, the CU2 of the IAB network is configured to send a first message to the CU1 or receive a first message from the CU1, and the first message has information indicating that a part of the offloaded traffic is returned to the CU1. The offloaded traffic was previously offloaded from the CU1 to the CU2.

[0068] Certain embodiments may provide one or more of the following (one or more) technical advantages. For example, certain embodiments can provide the technical advantage of enabling dynamic control of network resources for traffic load distribution when two CUs are involved in a procedure.

[0069] Other advantages will be readily apparent to those skilled in the art. Certain embodiments may have none, some, or all of the described advantages.

Brief Description of the Drawings

[0070] To more fully understand the disclosed embodiments and their features and advantages, the following description is to be read in conjunction with the accompanying drawings.

[0071]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Best Mode for Carrying Out the Invention

[0072] Some of the embodiments contemplated in this disclosure will be described more fully with reference to the accompanying drawings. However, the subject matter disclosed herein encompasses other embodiments within its scope. The disclosed subject matter should not be construed as limited to the described embodiments only. Rather, these embodiments are provided as examples to inform those skilled in the art of the scope of the subject matter.

[0073] In some embodiments, the more general term "network node" may be used, and "network node" may correspond to any type of radio network node or any network node that communicates with a UE (directly or via another node) and / or another network node. Examples of network nodes include network nodes belonging to NodeB, MeNB, eNB, MCG or SCG, base stations (BS), multi-standard radio (MSR) radio nodes such as MSR BS, eNodeB, gNodeB, network controllers, radio network controllers (RNC), base station controllers (BSC), relay stations (relays), donor nodes that control relays, base transceiver stations (BTS), access points (AP), transmission points, transmission nodes, RRU, RRH, nodes of a distributed antenna system (DAS), core network nodes (MSC, MME, etc.), O&M, OSS, SON, positioning nodes (such as E-SMLC), MDT, test equipment (physical nodes or software), etc.

[0074] In some embodiments, the non-limiting terms user equipment (UE) or wireless device may be used, and these terms may mean any type of wireless device that communicates with network nodes and / or another UE in a cellular or mobile communication system. Examples of UEs include target devices, device-to-device (D2D) UEs, machine type UEs or machine-to-machine (M2M) communication-capable UEs, PDAs, PADs, tablets, mobile terminals, smartphones, notebook PC embedded equipment (LEE), notebook PC-mounted equipment (LME), USB dongles, UE category M1, UE category M2, ProSe UEs, V2V UEs, V2X UEs, and the like.

[0075] Furthermore, terms such as base station / gNodeB, UE, etc. should be considered non-limiting and do not particularly imply a specific hierarchical relationship between the two. Generally, "gNodeB" can be considered as device 1 and "UE" as device 2, and these two devices communicate with each other via some wireless channel. And hereinafter, the transmitter or receiver can be either gNB or UE.

[0076] Specific embodiments are described as being illustrated in the case of proxy-based donor-to-donor migration, but the methods and techniques described herein are equally applicable to full-migration-based solutions when the network determines or recognizes that a device that has been fully migrated from CU1 to CU2 needs to be fully migrated back from CU2 to CU1.

[0077] The terms "donor-to-donor traffic offload", "donor-to-donor migration", and "donor-to-donor topology adaptation" are used in the same sense.

[0078] The term "single-connected top-level node" means a top-level IAB-MT that is connected to only one donor at a time.

[0079] The term "dual-connected top-level node" means a top-level IAB-MT that is connected to two donors simultaneously, or an IAB that has two MTs each connected to one donor.

[0080] The term "descendant node" can mean both a child node and the child node of its child node (and so on).

[0081] The terms "CU1", "source donor", and "old donor" are used with the same meaning.

[0082] The terms "CU_2", "target donor", and "new donor" are used with the same meaning.

[0083] The terms "donor DU1", "source donor DU", and "old donor DU" are used with the same meaning.

[0084] The terms "donor DU2", "target donor DU", and "new donor DU" are used with the same meaning.

[0085] The term "parent" can mean an IAB node or an IAB donor DU.

[0086] The terms "migrating IAB node" and "top-level IAB node" are used with the same meaning. · In a proxy-based solution for donor-to-donor topology adaptation, these mean the IAB-MT of this node (e.g., IAB3-MT in Figure 9). Because the co-located IAB-DU of the top-level node does not migrate (maintaining the F1 connection to the source donor). · In a full-migration-based solution, the entire node and its descendants migrate to another donor.

[0087] Some non-limiting examples of scenarios based on specific embodiments are shown below. · Donor - based load distribution for dual - connected top - level nodes (such as IAB3 - MT in Figure 9). Here, the traffic carried to / from / via the top - level IAB node is taken over (i.e., proxied) by the target donor (load distribution), that is, the source donor offloads the traffic related to the incoming / outgoing BH RLC channels between the IAB node and its parent node to the leg of the top - level node towards the target donor. · In the donor - based RLF recovery for dual - connected top - level nodes due to RLF on the link to the parent of the IAB node or on the link between the parent of the IAB node and the grand - parent of the IAB node, the traffic of the node (i.e., the top - level node) is completely transferred to the leg of the node towards the target donor. · The IAB node hands over to another donor. · Local donor - based rerouting (UL and / or DL). The newly selected path towards the donor or the destination IAB node goes via another donor. · In any of the above - described exemplary scenarios, a full - handover - based solution (as described above) is applied (instead of the proxy - based solution).

[0088] According to a particular embodiment, the top - level IAB node is composed of a top - level IAB - MT and its co - located IAB - DU (which may also be called "co - located DU" or "top - level DU"). In a particular scenario, it can be composed of two MTs and one co - located IAB - DU. Some aspects of the embodiments described herein relate to a proxy - based solution for donor - based topology adaptation, and some aspects relate to the full - handover - based solution described above.

[0089] According to a particular embodiment, the term "RRC / F1 connection of descendant devices" refers to the RRC of descendant IAB - MTs and UEs with the donor (in this case, the source donor). Connection It means the top-level IAB-DU of the descendant IAB nodes of the top-level IAB node and the F1 connection between the IAB-DU and the donor (source donor).

[0090] According to a particular embodiment, the traffic (also called proxy traffic) between CU1 and the top-level IAB node and / or its descendant nodes means the traffic between CU1 and the following. 1. The co-located IAB-DU part of the top-level IAB node (due to the IAB-MT part of the top-level IAB node migrating the RRC connection to a new donor), 2. The descendant IAB nodes of the top-level IAB node, and 3. The UEs served by the top-level node and its subordinate nodes.

[0091] According to a particular embodiment, for traffic offloading, it is assumed that direct routing between CU1 and donor DU2 (i.e., CU1-donor DU2-....) is applied instead of the indirect routing where traffic first goes to CU2 such as CU1-CU2-donor DU2-.... Direct routing is supported, for example, by IP routing between (source donor) CU1 and donor DU2 (target donor DU), or by the Xn connection between the two. In indirect routing, data is transmitted between CU1 and CU2 via the Xn interface, and between CU2 and donor DU2 via the F1 interface or IP routing. Both direct routing and indirect routing are applicable to the embodiments described herein. The advantage of direct routing is that the delay is likely to be smaller.

[0092] According to a particular embodiment, it is assumed that the traffic of both the user plane and the control plane is transmitted from the source donor to / from the top-level node and its descendants via the target donor by direct routing and indirect routing.

[0093] The term "destination is IAB-DU" includes both traffic whose final destination is the IAB-DU or a UE or IAB-MT served by the IAB-DU, and includes the top-level IAB-DU.

[0094] The term "data" means both user plane, control plane traffic, and non-F1 traffic.

[0095] The considerations described here apply equally to both fixed IAB nodes and mobile IAB nodes.

[0096] Here, the terms "old donor" and "CU1" mean a donor that has previously offloaded traffic to the "new donor" / "CU2". The starting point is that the connection from CU1 and CU2 to the migrating IAB node has been established.

[0097] FIG. 12 shows an example of a signaling chart 10 showing message exchange between a CU1 20 (e.g., a source donor node) and a CU2 30 (e.g., a target donor node) according to a particular embodiment.

[0098] As shown in FIG. 12, either or both of CU1 20 and CU2 30 may request traffic status information at 40. In certain embodiments, the request(s) (one or more) are timer or trigger based. In response to the request for traffic status information (alternatively, prior to and / or without receiving the request), CU1 20 and / or CU2 30 may provide a traffic load status at 50. Thereafter, at 60, CU1 20 may act based on the traffic load status obtained from CU2 30 or based on information directly obtained by CU1 20. At 70, CU1 20 may offload traffic to CU2 30 or cancel traffic previously offloaded to CU2 30. In the latter case, CU1 20 resumes processing the traffic previously offloaded to CU2 30.

[0099] Dynamic Offload Request by CU1

[0100] According to certain embodiments, a method including a dynamic offload request by CU1 includes the following. · Step 1: CU1 determines that it is necessary to 1) offload additional traffic load to CU2 or 2) return a portion of the traffic previously offloaded to CU2 to CU1. The reference to a portion of the previously offloaded traffic may mean only a portion of the previously offloaded traffic. · Step 2: If CU1 decides to offload additional traffic to CU2: · Step 2.1: CU1 requests additional resources from CU2. These resources may be downlink, uplink, or both. · Step 2.2: CU2 responds to CU1 either negatively, i.e., without providing additional resources, or positively, i.e., providing additional resources. These additional resources may be different from the resources initially requested in Step 2.1. · Step 2.3: Based on the response from CU2, CU1 may update the routing table of the IAB node for the affected routes and UEs / nodes. As a result, additional CU1 traffic is offloaded via CU2. · Step 3: If CU1 decides to return some of the previously offloaded traffic to CU2: · Step 3.1: CU1 may notify CU2 that it can reduce the resource allocation for offloading, i.e., it can return some of the previously offloaded traffic to CU1. These resources (allocated to CU1 offloaded traffic) can be in the downlink, uplink, or both. · Step 3.2: CU2 may respond to CU1 with an acknowledgement response. CU2 may release the corresponding resources associated with the offloaded traffic to be returned to CU1. · Step 3.3: CU1 updates the routing table of the IAB node for the affected routes and UEs / nodes. As a result, the traffic via CU1 increases and the traffic via CU2 decreases (because some of the previously offloaded traffic is returned to CU1).

[0101] Dynamic offloading request by CU2

[0102] According to a particular embodiment, a method including a dynamic offloading request by CU2 includes the following. · Step 1: CU2 determines that 1) it can accept additional traffic from CU1 (if it could not fully provide the resources previously requested from CU1), or 2) for some reason, such as a sudden increase in traffic demand from IAB nodes in its own domain (i.e., under the CU2 domain), it is necessary to reduce the allocated resources to the migrating IAB nodes. Similar to the offloading request from CU1, the reduction of the allocated resources may only mean some of the offloaded traffic. · Step 2: If CU2 determines that it can provide additional resources for offloading traffic from CU1: · Step 2.1: CU2 notifies CU1 that it can accept additional traffic from CU1. These resources may be for the downlink, uplink, or both. CU2 can also inform CU1 of the amount of additional resources it can provide. · Step 2.2: CU1 can respond negatively to CU2 if no more additional resources are needed, or positively if it accepts the provided resources. · Step 2.2’: CU2 can send an acknowledgement response to CU1 to handshake the procedure. · Step 2.3: Based on the response from CU1 in Step 2.2 or 2.2’, CU1 can update the routing table of the IAB node for the affected route and UE and IAB nodes. As a result, additional traffic will be offloaded via CU2. · Step 3: If CU2 determines that it needs to reduce the allocated resources: · Step 3.1: CU2 notifies CU1 that it needs to reduce the resource allocation. These resources may be for the downlink, uplink, or both. The notification also indicates which resources (i.e., the BH RLC channel) will be reduced / terminated. · Step 3.2: CU1 can respond to CU2 in the following ways. · Step 3.2.1: An acknowledgement response indicating acceptance of the CU2 request, or · Step 3.2.2: Alternatively, a second request for resource allocation that may include a different configuration from the previously configured one. This may be done to adapt / coordinate the traffic with the corresponding QoS requirements according to the request from CU2. · As an option, in step 3.2.2.1: CU2 can respond to the request from CU1 by accepting a new request, rejecting it, or providing another resource allocation. This loop may return to step 2.2. · Step 3.3: CU1 updates the routing table of the IAB node for the affected routes and UEs and iAB nodes. As a result, the traffic via CU1 will increase and the traffic via CU2 will decrease.

[0103] A reference to some of the offloaded traffic being returned to the transmitting CU (e.g., CU1), or obtaining some of the previously offloaded traffic, can be considered as a reference to only some of the offloaded traffic, or obtaining only some of the offloaded traffic. Therefore, "part" or "portion" of the traffic means less than the total amount of the previously offloaded traffic, i.e., only some of the previously offloaded traffic.

[0104] Timer-based polling or on-demand status checks for adaptive / dynamic traffic sharing

[0105] According to a particular embodiment, when multiple CUs are involved in load sharing (traffic offloading) (e.g., CU1 and CU2 provided in the example of the above section), the CU (CU1) having the F1 connection can configure a timer for CU2 and / or the top-level IAB node. When such a timer expires, the polled network entity provides the congestion status of the traffic. This status can be indicated by a simple flag (loaded / unloaded, i.e., no capacity / has capacity). Alternatively, this can also be indicated by providing the bit rate, i.e., how much traffic the new CU (e.g., CU2) can handle from the CU (CU1) that needs to offload traffic.

[0106] Based on such feedback regarding the pre - set time - based polling, the CU1 determines, according to certain embodiments, whether it can offload additional traffic or whether it is necessary to take back some of the traffic from the CU2. The timer may be explicitly notified or may be an implicit default value when multiple CUs are involved for load balancing.

[0107] According to certain embodiments, the polling does not depend on a timer, and the CU1 or CU2 may perform an on - demand status check. However, in order to avoid excessive signaling that may occur among multiple CUs when the trigger conditions are not well - defined, in certain embodiments, the trigger or event for such a status check can be pre - set.

[0108] According to certain embodiments, examples of such triggers may be as follows. · In certain embodiments, when there is a sudden or gradual increase in the traffic of the top - level IAB node (when the load increases by a predetermined threshold value within a pre - set period 、 The traffic load threshold can be configured (for example) with respect to the bit rate). In this case, it is necessary to further offload the additional traffic to the CU2. · When the traffic load of the top - level IAB node drops (to a set predetermined threshold value). This may give the CU1 an opportunity to take back some of the traffic from the CU2. · When any of the parent nodes of the CU2 that processes traffic to / from the top - level node becomes congested (by a predetermined margin for a predetermined period) or when the traffic load drops (by a predetermined margin for a predetermined period).

[0109] According to certain embodiments, the start of such polling information can be indicated by using a new lightweight Xn signaling message, such as part of a handover preparation procedure or a secondary node setup procedure (master node, secondary node dual connection procedure), or by adding to existing signaling.

[0110] According to certain embodiments, the response to such polling (e.g., traffic load status response flag) is a new lightweight signaling message.

[0111] FIG. 13 shows an example of a communication system 100 according to some embodiments. In this example, the communication system 100 includes a telecommunications network 102 including an access network 104, such as a radio access network (RAN), and a core network 106 including one or more core network nodes 108. The access network 104 includes one access network node, such as network nodes 110a and 110b (one or more of which may be generally referred to as network node 110), or any other similar 3rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network node 110 enables a direct or indirect connection of a user equipment (UE) by connecting the UEs 112a, 112b, 112c, and 112d (one or more of which may be generally referred to as UE 112) to the core network 106, such as via one or more wireless connections. Above

[0112] Exemplary wireless communication via a wireless connection includes transmitting and / or receiving a wireless signal using electromagnetic waves, radio waves, infrared rays, and / or other types of signals suitable for carrying information without using wires, cables, or other physical conductors. Further, in different embodiments, the communication system 100 can include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals, whether via a wired connection or a wireless connection. The communication system 100 can include and / or interface with any type of communication, telecommunications, data, cellular, wireless network, and / or other similar types of systems.

[0113] UE112 can be any of a variety of communication devices, including a wireless device arranged, configured, and / or operable to wirelessly communicate with network node 110 and other communication devices. Similarly, network node 110 is arranged, capable, configured, and / or operable to communicate directly or indirectly with UE112 and / or other network nodes or devices within the telecommunications network 102 to enable and / or provide network access such as wireless network access and / or perform other functions such as management within the telecommunications network 102.

[0114] In the illustrated example, the core network 106 connects network nodes 110 to one or more hosts, such as host 116. These connections may be direct or indirect via one or more intermediate networks or devices. In other examples, network nodes may be directly connected to hosts. The core network 106 includes one or more core network nodes (e.g., core network node 108) composed of hardware components and software components. The functions of these components may be substantially similar to those described with respect to the UE, network nodes, and / or hosts, and thus, those descriptions generally also apply to the corresponding components of the core network node 108. Exemplary core network nodes include one or more functions of a mobile switching center (MSC), a mobility management entity (MME), a home subscriber server (HSS), an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a subscription identifier concealment release function (SIDF), a unified data management (UDM), a security edge protection proxy (SEPP), a network exposure function (NEF), and / or a user plane function (UPF).

[0115] Host 116 may be under the ownership or control of a service provider other than the operator or provider of the access network 104 and / or the telecommunications network 102, and may be operated by or on behalf of the service provider. Host 116 can host various applications to provide one or more services. Examples of such applications include the provision of live and recorded audio / video content, data collection services, e.g., the acquisition and compilation of data regarding various ambient situations detected by a plurality of UEs, analysis functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or other such functions executed by a server.

[0116] Overall, the communication system 100 of FIG. 13 realizes connectivity between the UE, network nodes, and hosts. In that sense, the communication system can be configured to operate according to predefined rules and procedures such as, but not limited to, specific standards. Global System for Mobile Communications (GSM) for mobile communications, Universal Mobile Telecommunications System (UMTS), Long-Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standards (e.g., 6G), wireless local area network (WLAN) standards such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi), and / or other suitable wireless communication standards such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC), ZigBee, LiFi, and / or low power wide area network (LPWAN) standards such as LoRa and Sigfox.

[0117] In some examples, the telecommunication network 102 is a cellular network implementing functions standardized by 3GPP. Thus, the telecommunication network 102 can support network slicing to provide different logical networks to different devices connected to the telecommunication network 102. For example, the telecommunication network 102 can provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs and / or Massive Machine Type Communication (mMTC) / Massive IoT services to further UEs.

[0118] In some examples, UE 112 may be configured to send and / or receive information without direct human involvement. For example, the UE may be designed to send information to access network 104 at a predetermined schedule, when triggered by an internal or external event, or in response to a request from access network 104. Further, the UE may be configured to operate in single or multi-RAT or multi-standard mode. For example, the UE can operate using any one or combination of Wi-Fi, NR (New Radio), and LTE, i.e., it can be configured for multi-radio dual connectivity (MR-DC) such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).

[0119] In this example, hub 114 communicates with access network 104 to facilitate indirect communication between one or more UEs (e.g., UE112c and / or 112d) and a network node (e.g., network node 110b). In some examples, hub 114 can be any of a controller, a router, a content source and analyzer, or other communication devices described herein with respect to the UE. For example, hub 114 can be a broadband router that enables access by the UE to core network 106. As another example, hub 114 can be a controller that sends commands or instructions to one or more actuators within the UE. The commands or instructions can be received from the UE, network node 110, or can be by executable code, scripts, processes, or other instructions within hub 114. As another example, hub 114 can be a data collector that acts as temporary storage for UE data and, in some embodiments, can perform analysis or other processing of the data. As another example, hub 114 can be a content source. For example, for a UE that is a VR headset, display, loudspeaker, or other media delivery device, hub 114 can retrieve VR assets, video, audio, or other media, or data related to sensory information, via the network node, and hub 114 can provide it to the UE either directly after performing local processing and / or after adding additional local content. In yet another example, hub 114 functions as a proxy server or orchestrator for the UE, particularly when one or more UEs are low-energy IoT devices.

[0120] The hub 114 may have a constant / persistent or intermittent connection to the network node 110b. The hub 114 may also enable different communication methods and / or schedules between the hub 114 and the UEs (e.g., UEs 112c and / or 112d) and between the hub 114 and the core network 106. In other examples, the hub 114 is connected to the core network 106 and / or one or more UEs via a wired connection. Further, the hub 114 may be configured to connect to an M2M service provider via the access network 104 and / or to another UE via a direct connection. In some scenarios, the UE can establish a wireless connection with the network node 110 while being connected via the hub 114 through a wired or wireless connection. In some embodiments, the hub 114 may be a dedicated hub, i.e., a hub whose main function is to route communications from the network node 110b to the UE and vice versa. In other embodiments, the hub 114 may be a non-dedicated hub, i.e., a device that has the ability to operate to route communications between the UE and the network node 110b, but further has the ability to operate as a communication start and / or endpoint for a specific data channel.

[0121] FIG. 14 shows a UE 200 according to some embodiments. In the present disclosure, a UE means a device that is capable of wireless communication with a network node and / or another UE, is configured to wirelessly communicate, is arranged to wirelessly communicate, and / or is operable to wirelessly communicate. Non-limiting examples of a UE include smartphones, mobile phones, cellular phones, Voice over Internet Protocol (VoIP) phones, wireless local loop phones, desktop computers, Personal Digital Assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile machines, tablets, laptops, Laptop Embedded Equipment (LEE), Laptop Mounted Equipment (LME), smart devices, wireless Customer Premises Equipment (CPE), in-vehicle or vehicle-embedded / integrated wireless devices, etc. Other examples include any UE defined by the 3rd Generation Partnership Project (3GPP), including NarrowBand Internet of Things (NB-IoT) UEs, Machine Type Communication (MTC) UEs, and / or Extended MTC (eMTC) UEs.

[0122] The UE can support Device-to-Device (D2D) communication, for example, by implementing 3GPP specifications for sidelink communication, dedicated short-range communication (DSRC), vehicle-to-vehicle communication (V2V), vehicle-infrastructure communication (V2I), or vehicle-to-everything communication (V2X). In other examples, the UE may not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Alternatively, the UE may represent a device (e.g., a smart sprinkler controller) that is intended for sale to or operation by a human user but is not (initially) associated with a specific human user. Alternatively, the UE may represent a device (e.g., a smart power meter) that is not intended for sale to or operation by an end user but can be related to or operate for the benefit of a user.

[0123] UE 200 includes processing circuitry 202 operably connected via bus 204 to input / output interface 206, power supply 208, memory 210, communication interface 212, and / or any other components, or any combination thereof. A particular UE may utilize all or a subset of the components shown in FIG. 14. The level of integration between components may vary from UE to UE. Further, a UE may include multiple instances of components, such as multiple processors, multiple memories, multiple transceivers, multiple transmitters, multiple receivers, etc.

[0124] Processing circuitry 202 is configured to process instructions and data and may be configured to implement any sequential state machine operable to execute instructions stored as a machine-readable computer program within memory 210. Processing circuitry 202 may be implemented as one or more state machines implemented in hardware (e.g., in discrete logic, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), a combination of suitable firmware and programmable logic, one or more stored computer programs, a combination of a general purpose processor such as a microprocessor or digital signal processor (DSP) and suitable software, or any combination thereof. For example, processing circuitry 202 may include multiple central processing units (CPUs).

[0125] In this example, the input / output interface 206 can be configured to interface with an input device, an output device, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, emitters, smart cards, other output devices, or any combination thereof. The input device can enable a user to capture information into the UE 200. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, directional keys, trackpads, scroll wheels, smart cards, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from the user. The sensor can be, for example, an accelerometer, gyroscope, tilt sensor, force sensor, magnetometer, light sensor, proximity sensor, biometric sensor, etc., or any combination thereof. The output device can use the same type of interface port as the input device. For example, a Universal Serial Bus (USB) port can be used to provide an input device and an output device.

[0126] In some embodiments, the power supply 208 is configured as a battery or a battery pack. Other types of power supplies such as an external power supply (e.g., an electrical outlet), a photovoltaic device, or a power cell can be used. The power supply 208 can further include a power circuit for delivering power from the power supply 208 itself and / or from an external power supply to various parts of the UE 200 via an interface such as an input circuit or a power cable. The power delivery can be, for example, for charging the power supply 208. The power circuit can perform any formatting, conversion, or other modification to the power from the power supply 208 to create power suitable for each component of the UE 200 to which power is supplied.

[0127] Memory 210 can be configured to include a memory such as a random access memory (RAM), a read only memory (ROM), a programmable read only memory (PROM), an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM), a magnetic disk, an optical disk, a floppy disk (registered trademark), a hard disk, a removable cartridge, or a flash drive. In one example, memory 210 includes one or more application programs 214, such as an operating system, a web browser application, a widget, a gadget engine, or other applications, and corresponding data 216. Memory 210 can store any one or combination of various operating systems for use by UE200.

[0128] The memory 210 can be configured to include several physical drive units, such as an independent disk redundant array (RAID), flash memory, a USB flash drive, an external hard disk drive, a thumb drive, a pen drive, a key drive, a high density digital versatile disc (HD-DVD) optical disc drive, an internal hard disk drive, a Blu-ray optical disc drive, a holographic digital data storage (HDDS) optical disc drive, an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), an external micro DIMM SDRAM, a universal integrated circuit card (UICC) in the form of a smart card memory including one or more subscriber identity modules (SIMs) such as a USIM and / or an ISIM, or any combination of other memories. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly known as a "SIM card". The memory 210 can enable the UE 200 to access instructions, application programs, etc. stored in a transient or non-transient storage medium, offload data, or upload data. Products such as those utilizing a communication system may be embodied as the memory 210 or within the memory 210, and the memory 210 may be a device-readable storage medium or may include a device-readable storage medium.

[0129] The processing circuit 202 can be configured to communicate with an access network or other network using the communication interface 212. The communication interface 212 can have one or more communication subsystems and can further include or be communicatively coupled to an antenna 222. The communication interface 212 can include one or more transceivers that are used for communication, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or network node within the access network). Each transceiver can include a transmitter 218 and / or a receiver 220 suitable for providing network communication (e.g., optical, electrical, frequency allocation, etc.). Further, the transmitter 218 and the receiver 220 can be connected to one or more antennas (e.g., antenna 222), and can share circuit components, software, or firmware, or can be implemented separately.

[0130] In the illustrated embodiment, the communication functions of the communication interface 212 can include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, proximity communication, location-based communication such as the use of the Global Positioning System (GPS) for positioning, another similar communication function, or any combination thereof. The communication can be carried out in accordance with one or more communication protocols and / or standards such as IEEE802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA (registered trademark)), GSM (registered trademark), LTE, New Radio (NR), UMTS, WiMax, Ethernet (registered trademark), Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

[0131] Regardless of the type of sensor, the UE can provide the output of the data obtained by its own sensors through its communication interface 212 and the wireless connection to the network node. The data obtained by the UE's sensors may be communicated to the network node via the wireless connection and via another UE. The output may be periodic (e.g., once every 15 minutes when reporting the sensed temperature), random (e.g., to equalize the load from reports from multiple sensors), in response to a trigger event (e.g., a warning is sent when moisture is detected), in response to a request (e.g., a request initiated by the user), or continuous streaming (e.g., a live video feed of a patient).

[0132] As another example, the UE has an actuator, a motor, or a switch associated with a communication interface configured to receive wireless input from a network node through a wireless connection. In response to the received wireless input, the state of the actuator, motor, or switch can change. For example, the UE can have a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input, or controls a robotic arm that performs a medical procedure according to the received input.

[0133] When the UE is in the form of an Internet of Things (IoT) device, it may be a device for use in one or more application areas, including but not limited to urban wearable technologies, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices include devices such as the following, or devices incorporated into the following. Refrigerators or freezers connected to the Internet, televisions, lighting devices connected to the Internet, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion sensors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electric door locks, doorbells connected to the Internet, air conditioning systems such as heat pumps, self-driving vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearables for tactile or sensory enhancement, sprinklers, animal or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and all kinds of medical devices such as heart rate monitors and remotely operated surgical robots. The UE having the form of an IoT device has circuits and / or software according to the intended use of the IoT device in addition to other components as described for the UE200 shown in FIG. 14.

[0134] As yet another specific example, in an IoT scenario, the UE may represent a machine or other device that performs monitoring and / or measurement, etc., and transmits the results of such monitoring and / or measurement, etc. to another UE and / or network node. The UE may in this case be an M2M device and may be called an MTC device in the context of 3GPP. As one specific example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, the UE may represent vehicles such as cars, buses, trucks, ships, and aircraft, or other devices having the ability to monitor and / or report on their own operating status or other functions related to their operation.

[0135] In practice, any number of UEs can be used together with respect to a single use case. For example, the first UE may be or integrated with a drone, and may provide the speed information of the drone (obtained via a speed sensor) to a second UE that is a remote controller for operating the drone. When the user makes a change from the remote controller, the first UE can adjust the throttle of the drone (e.g., by controlling an actuator) to increase or decrease the speed of the drone. The first and / or second UE may also include two or more of the functions described above. For example, the UE has sensors and actuators and can process the communication of data for both the speed sensor and the actuator.

[0136] FIG. 15 shows a network node 300 according to some embodiments. In the present disclosure, a network node means a device configured to communicate, arranged to communicate, and / or operable to communicate in a telecommunications network, having the ability to communicate directly or indirectly with a UE and / or with other network nodes or devices. Non-limiting examples of network nodes include access points (APs) (e.g., wireless access points), base stations (BSs) (e.g., radio base stations, Node B, evolved Node B (eNB), and NR Node B (gNB)).

[0137] Base stations can be classified based on the size of the coverage they provide (or, in other words, the transmission power level), and thus can be called femto base stations, pico base stations, micro base stations, or macro base stations according to the size of the coverage they provide. The base station may be a relay node or a relay donor node that controls relaying. The network node may also include one or more (or all) parts of a distributed radio base station such as a centralized digital unit and / or a remote radio unit (RRU), sometimes called a remote radio head (RRH). Such a remote radio unit may or may not be integrated with an antenna as an antenna-integrated radio. A part of a distributed radio base station may sometimes be called a node in a distributed antenna system (DAS).

[0138] Other examples of network nodes include multi-transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) devices such as MSR BS, network control devices such as radio network control devices (RNC) and base station control devices (BSC), base transceiver stations (BTS), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCE), operation and maintenance (O&M) nodes, operation support system (OSS) nodes, self-organizing network (SON) nodes, positioning nodes (such as evolved serving mobile location center (E-SMLC), etc.), and / or minimized drive test (MDT).

[0139] The network node 300 includes a processing circuit 302, a memory 304, a communication interface 306, and a power supply 308. The network node 300 may be composed of a plurality of physically separated components (for example, a NodeB component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have individual components. In a specific scenario where the network node 300 includes a plurality of distinct components (for example, a BTS and a BSC component), one or more distinct components may be shared among a plurality of network nodes. For example, a single RNC may control a plurality of NodeBs. In such a scenario, a unique combination of a NodeB and an RNC may be regarded as an independent network node. In some embodiments, the network node 300 may be configured to support a plurality of radio access technologies (RATs). In such embodiments, some components may overlap (for example, separate memories 304 for different RATs), while some components may be reused (for example, the same antenna 310 may be shared by different RATs). The network node 300 may include a plurality of sets of various illustrated components corresponding to various wireless technologies integrated into the network node 300, such as GSM, WCDMA (registered trademark), LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, RFID (Radio Frequency Identification), or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chips or chip sets and other components within the network node 300.

[0140] The processing circuit 302 may include, alone or in combination with other components of the network 300 such as the memory 304, one or more combinations, resources, or combinations of hardware, software, and / or coded logic of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device operable to provide the functionality of the network node 300.

[0141] In some embodiments, the processing circuit 302 includes a system on chip (SOC). In some embodiments, the processing circuit 302 includes one or more of a radio frequency (RF) transceiver circuit 312 and a baseband processing circuit 314. In some embodiments, the radio frequency (RF) transceiver circuit 312 and the baseband processing circuit 314 may be present in separate chips (or chip sets), substrates, or units such as a radio unit and a digital unit. In alternative embodiments, some or all of the radio frequency transceiver circuit 312 and the baseband processing circuit 314 may be present on the same chip, or on a set of chips, substrates, or units.

[0142] Memory 304 can have any form of volatile or non-volatile computer-readable memory, including but not limited to a persistent storage device, a semiconductor memory, a remotely mounted memory, a magnetic medium, an optical medium, a random access memory (RAM), a read-only memory (ROM), a mass storage medium (e.g., a hard disk), a removable storage medium (e.g., a flash drive, a compact disc (CD) or a digital video disc (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that can store information, data, and / or instructions used by processing circuit 302. Memory 304 can store any appropriate instructions, data, or information, including an application that includes one or more of a computer program, software, logic, rules, code, tables, and / or other instructions that are executed by processing circuit 302 and can be utilized by network node 300. Memory 304 can be used to store any calculations performed by processing circuit 302 and / or any data received via communication interface 306. In some embodiments, processing circuit 302 and memory 304 are integrated.

[0143] The communication interface 306 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, the communication interface 306 has (one or more) ports / terminals 316 for transmitting and receiving data (e.g., between the network through a wired connection). The communication interface 306 also includes a radio front-end circuit 318 that may be connected to the antenna 310 or, in some embodiments, may be part of the antenna 1010. The radio front-end circuit 318 has a filter 320 and an amplifier 322. The radio front-end circuit 318 can be connected to the antenna 310 and the processing circuit 302. The radio front-end circuit can be configured to condition the signals communicated between the antenna 310 and the processing circuit 302. The radio front-end circuit 318 can receive digital data to be transmitted to other network nodes or UEs via a wireless connection. The radio front-end circuit 318 can use a combination of the filter 320 and / or the amplifier 322 to convert the digital data into a wireless signal with appropriate channel and bandwidth parameters. The wireless signal can then be transmitted via the antenna 310. Similarly, when receiving data, the antenna 310 can collect the wireless signal that is converted into digital data by the radio front-end circuit 318. The digital data may be passed to the processing circuit 302. In other embodiments, the communication interface may have different components and / or different combinations of components.

[0144] In certain alternative embodiments, network node 300 does not include a separate radio front-end circuit 318. Instead, processing circuit 302 includes a radio front-end circuit and is connected to antenna 310. Similarly, in some embodiments, all or part of RF transceiver circuit 312 is part of communication interface 306. In still other embodiments, communication interface 306, as part of a wireless unit (not shown), includes one or more ports or terminals 316, radio front-end circuit 318, and RF transceiver circuit 312, and communication interface 306 communicates with baseband processing circuit 314, which is part of a digital unit (not shown).

[0145] Antenna 310 may include one or more antennas, or an antenna array, configured to transmit and / or receive wireless signals. Antenna 310 may be connected to radio front-end circuit 318 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In certain embodiments, antenna 310 is separate from network node 300 and can be connected to network node 300 via an interface or port.

[0146] Antenna 310, communication interface 306, and / or processing circuit 302 may be configured to perform any receiving operations and / or some acquisition operations described as being performed by a network node. Any information, data, and / or signals may be received from a UE, other network nodes, and / or any other network equipment. Similarly, antenna 310, communication interface 306, and / or processing circuit 302 may be configured to perform any transmission operations described as being performed by a network node. Any information, data, and / or signals may be transmitted to a UE, other network nodes, and / or any other network equipment.

[0147] Power supply 308 provides power to the various components of network node 300 in a form suitable for each component (e.g., at the voltage and current levels required for each component). The power supply 308 may further include a power management circuit for supplying power to the components of the network node 300 to execute the functions described herein, or may be connected to the power management circuit. For example, the network node 300 may be connectable to an external power source (e.g., a power grid, an electrical outlet) through an input circuit or interface such as an electrical cable, whereby the external power source supplies power to the power circuit of the power supply 308. As a further example, the power supply 308 may have a power source in the form of a battery or battery pack that is connected to or integrated with the power circuit. In the event of a failure in the external power source, the battery may provide a backup power source.

[0148] Embodiments of the network node 300 may include additional components not shown in FIG. 15 for providing some aspects of the functionality of a network node, including any of the functions described herein and / or any functions necessary to support the subject matter described herein. For example, the network node 300 may include a user interface device that enables the input of information to the network node 300 and also enables the output of information from the network node 300. Thereby, a user can perform diagnostic, maintenance, repair, and other management functions of the network node 300.

[0149] FIG. 16 is a block diagram of a host 400 that may be an embodiment of the host 116 of FIG. 13 according to various aspects described herein. Here, the host 400 may be various combinations of hardware and / or software, including a stand-alone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, a container, or processing resources within a server farm, and may have various combinations. The host 400 can provide one or more services to one or more UEs.

[0150] The host 400 includes a processing circuit 402 that is operably connected to an input / output interface 406, a network interface 408, a power supply 410, and a memory 412 via a bus 404. Other components may be included in other embodiments. The functions of these components may be substantially the same as those described with respect to previous figures such as FIGS. 2 and 3, and thus, those descriptions generally apply to the corresponding components of the host 400 as well.

[0151] Memory 412 may include one or more computer programs that include one or more host application programs 414 and data 416 that may include user data, such as data generated by the UE for the host 400 or data generated by the host 400 for the UE. Embodiments of the host 400 may utilize only a subset or all of the illustrated components. The host application program 414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of the UE (e.g., handsets, desktop computers, wearable display systems, head-up display systems). The host application program 414 may also provide user authentication and license checking and may periodically report health, routing, and content availability to a central node, such as a device within the core network or at the edge of the core network. Thus, the host 400 may select and / or indicate another host for an over-the-top service for the UE. The host application program 414 may support various protocols such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH).

[0152] FIG. 17 is a block diagram showing a virtualization environment 500 in which functions implemented by some embodiments may be virtualized.

[0153] In this context, virtualization means creating a virtual version of a device or apparatus, which may include virtualizing the hardware platform, storage devices, and network resources. Here, virtualization can be applied to any device or its components described herein and relates to an implementation in which at least some of the functions are implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 500 hosted by one or more hardware nodes such as a network node, a UE, a core network node, or a hardware computing device operating as a host. Further, in embodiments where the virtual node does not require wireless connectivity (e.g., a core network node or a host), the node can be fully virtualized.

[0154] An application 502 (alternatively, may be referred to as a software instance, virtual appliance, network function, virtual node, virtual network function, etc.) is executed in a virtualized environment Q400 to implement some of the features, functions, and / or advantages of some of the embodiments disclosed herein.

[0155] Hardware 504 includes a processing circuit, a memory storing software and / or instructions executable by the hardware processing circuit, and / or other hardware devices such as a network interface, an input / output interface, etc. The software can be executed by the processing circuit, thereby instantiating one or more virtualization layers 506 (also referred to as a hypervisor or virtual machine monitor (VMM)), providing VMs 508a and 508b (which may be collectively referred to as VMs 508), and / or performing any of the functions, features, and / or advantages described in connection with some of the embodiments described herein. The virtualization layer 506 can present a virtual operating platform to the VMs 508 that appears as network hardware.

[0156] The VMs 508 have virtual processing, virtual memory, virtual networking or interfaces, and virtual storage and can be executed by the corresponding virtualization layer 506. Various embodiments of instances of the virtual appliance 502 may be implemented on one or more of the VMs 508, and the implementation can be done in various ways. The virtualization of hardware is sometimes referred to as network function virtualization (NFV) in the context. NFV can be used to integrate many network device types into industry-standard high-volume server hardware, physical switches, and physical storage that may exist in a data center, and customer premise equipment.

[0157] In the context of NFV, the VMs 508 can be a software implementation of a physical machine that executes programs as if running on a physical non-virtualized machine. Each of the VMs 508, and a part of the hardware 504 that executes that VM (the hardware dedicated to that VM and / or the hardware shared by that VM with other VMs), form separate virtual network elements. Also in the context of NFV, the virtual network functions run on one or more VMs 508 on the hardware 504 and are responsible for handling specific network functions corresponding to the application 502.

[0158] Hardware 504 can be implemented in a stand-alone network node having general-purpose or specific components. Hardware 504 can implement some functions using virtualization. Alternatively, Hardware 504 can be part of a larger class of hardware (such as within a data center or CPE, etc.) where many hardware nodes cooperate and are managed using management and orchestration 510 that particularly oversees the life cycle management of application 502. In some embodiments, Hardware 504 is connected to one or more wireless units, each including one or more transmitters and one or more receivers that can be connected to one or more antennas. The wireless unit can communicate directly with other hardware nodes via one or more appropriate network interfaces and can be used in combination with virtual components to provide virtual nodes (such as wireless access nodes or base stations, etc.) having wireless capabilities. In some embodiments, some signaling can be provided using a control system 512 that can alternatively be used for communication between the hardware node and the wireless unit.

[0159]

[0160] 3 Examples of implementations of UEs (such as UE112a in FIG. 1 and / or UE200 in FIG. 1), network nodes (such as network node 110a in FIG. 13 and / or network node 300 in FIG. 15), and hosts (such as host 116 in FIG. 13 and / or host 400 in FIG. 16), according to various embodiments, will be described with reference to FIG. 18. 4

[0161] ​​​Similar to host 400, the embodiment of host 602 includes hardware such as a communication interface, a processing circuit, and memory. Host 602 further includes software that is stored in host 602 or accessible to host 602 and executable by the processing circuit. The software includes a host application operable to provide services to remote users such as UE 606 that connect via an over-the-top (OTT) connection 650 that extends between UE 606 and host 602. When providing services to remote users, the host application can provide user data transmitted using OTT connection 650.

[0162] Network node 604 includes hardware that enables network node 604 to communicate with host 602 and UE 606. Connection 660 may be direct or may pass through a core network (such as core network 106 of FIG. 13) and / or one or more other intermediate networks such as one or more public, private, or hosted networks. For example, the intermediate network may be a backbone network or the Internet.

[0163] UE 606 includes software that is stored in UE 606 or is accessible to UE 606 and executable by a processing circuit. The software may include client applications such as a web browser or an operator-specific "app" that is operable, with the support of host 602, to provide services to a human or non-human user via UE 606. In host 602, a running host application can communicate with a running client application via an OTT connection 650 that terminates at UE 606 and host 602. When providing services to a user, a client application of the UE may receive request data from a host application of the host and provide user data in response to the request data. The OTT connection 650 can transfer both request data and user data. A client application of the UE can interact with the user to generate user data to be provided to the host application through the OTT connection 650.

[0164] The OTT connection 650 can extend through a connection 660 between host 602 and network node 604 and a wireless connection 670 between network node 604 and UE 606 to provide a connection between host 602 and UE 606. The connection 660 and the wireless connection 670 through which the OTT connection 650 can be provided are abstractly depicted to illustrate communication between host 602 and UE 606 via network node 604, and the exact routing of messages through intermediate devices and these devices is not explicitly shown.

[0165] As an example of transmitting data via the OTT connection 650, at step 608, the host 602 provides user data. This can be achieved by running a host application. In some embodiments, the user data is associated with a particular human user who interacts with the UE 606. In other embodiments, the user data is associated with the UE 606 that shares data with the host 602 without an explicit interaction with a human. At step 610, the host 602 initiates a transmission to convey the user data to the UE 606. The host 602 may initiate the transmission in response to a request sent by the UE 606. The request may be due to an interaction between the UE 606 and a human, or an operation of a client application running on the UE 606. The transmission may be passed via the network node 604 in accordance with the teachings of the embodiments described throughout this disclosure. Thus, at step 612, the network node 604 transmits the user data conveyed in the transmission initiated by the host 602 to the UE 606 in accordance with the teachings of the embodiments described throughout this disclosure. At step 614, the UE 606 receives the user data conveyed by the transmission. This reception may be performed by a client application running on the UE 606 that is associated with a host application executed by the host 602.

[0166] In some examples, UE 606 executes a client application that provides user data to host 602. The user data may be provided in response to or in reaction to data received from host 602. Thus, at step 616, UE 606 may provide user data, and the provision of the user data may be accomplished by executing the client application. When providing the user data, the client application may further consider user input received from the user through the input / output interface of UE 606. Regardless of the specific manner in which the user data is supplied, at step 618, UE 606 initiates the transmission of the user data towards host 602 via network node 604. At step 620, in accordance with the teachings of the embodiments described throughout this disclosure, network node 604 receives the user data from UE 606 and initiates the transmission of the received user data towards host 602. At step 622, host 602 receives the user data carried in the transmission initiated by UE 606.

[0167] One or more of the various embodiments improve the performance of the OTT services provided to UE 606 using the OTT connection 650 where the wireless connection 670 forms the last segment. More precisely, the teachings of these embodiments may improve one or more of, for example, data rate, latency, and / or power consumption, thereby providing advantages such as, for example, reduced user waiting time, relaxed file size limitations, improved content resolution, better responsiveness, and / or extended battery life.

[0168] In an exemplary scenario, factory status information can be collected and analyzed by host 602. As another example, host 602 can process audio and video data read from a UE for use in creating a map. As another example, host 602 can collect and analyze real-time data to assist in traffic congestion control (e.g., traffic signal control). As another example, host 602 can store surveillance videos uploaded by a UE. As another example, host 602 can store or control access to media content such as video, audio, VR, or AR that can be broadcast, multicast, or unicast to a UE. As other examples, host 602 can be used for energy price setting, remote control of non-urgent power loads to balance power generation needs, location information services, presentation services (such as compiling diagrams from data collected from remote devices), or other functions of data collection, search, storage, analysis, and / or transmission.

[0169] In some examples, measurement procedures may be provided to monitor data rate, latency, and other network operating aspects that are improved by one or more embodiments. Further, there may be optional network functions for reconfiguring the OTT connection 650 between the host 602 and the UE 606 in response to variations in the measurement results. The measurement procedures and / or network functions for reconfiguring the OTT connection may be implemented in the software and hardware of the host 602 and / or the UE 606. In some embodiments, sensors (not shown) may be provided within or associated with other devices through which the OTT connection 650 passes, and the sensors may participate in the measurement procedures by providing values of the monitored quantities exemplified above, or by providing values of other physical quantities from which the software can calculate or estimate the monitored quantities. The reconfiguration of the OTT connection 650 can include message format, retransmission settings, priority routing, etc., and the reconfiguration need not directly change the operation of the network node 604. Such procedures and functions will be known and practiced in the art. In certain embodiments, the measurement may involve unique UE signaling that facilitates measurement of throughput, propagation time, latency, etc. by the host 602. The measurement can be performed by having the software transmit messages, particularly empty or "dummy" messages, using the OTT connection 650 while monitoring propagation time, errors, etc.

[0170] The computing devices (e.g., UEs, network nodes, hosts) described herein may include the illustrated combinations of hardware components, but other embodiments may have computing devices with different combinations of components. It should be understood that these computing devices may have any suitable combination of hardware and / or software necessary to perform the tasks, features, functions, and methods disclosed herein. The determinations, calculations, acquisitions, or similar operations described herein may be performed by a processing circuit, which may, for example, convert acquired information into other information, compare the acquired information or the converted information with information stored in a network node, and / or perform one or more operations based on the acquired information or the converted information to process the information and make a determination as a result of the processing. Further, the components are depicted as a single box located within a larger box or nested within multiple boxes, but in reality, a computing device may have multiple different physical components that make up a single illustrated component, and the functions may be divided among separate components. For example, a communication interface may be configured to include any of the components described herein and / or the functions of a component may be divided between a processing circuit and a communication interface. In another example, functions that are not computationally intensive for any of such components may be implemented in software or firmware, and functions that are computationally intensive may be implemented in hardware.

[0171] In certain embodiments, some or all of the functions described herein may be provided by a processing circuit that executes instructions stored in a memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by the processing circuit in a hardwired manner, such as without executing instructions stored in a separate or discrete device-readable storage medium. In any of these particular embodiments, whether or not executing instructions stored in a non-transitory computer-readable storage medium, the processing circuit may be configured to perform the described functions. The advantages provided by such functions are not limited to the processing circuit alone or other components of a computing device, but are widely enjoyed by the entire computing device and / or end user and wireless network.

[0172] FIG. 19 is a diagram illustrating a method 700 by a CU1 of an IAB network according to a particular embodiment. According to the method, at step 702, the CU1 transmits a first message to the CU2 or receives the first message from the CU2. The first message includes information indicating to return a portion of the offloaded traffic to the CU1. The offloaded traffic was previously offloaded from the CU1 to the CU2.

[0173] In certain embodiments, before transmitting the first message, the CU1 offloads the offloaded traffic from the first CU1 to the CU2.

[0174] In certain embodiments, the offloaded traffic is terminated at a migrating IAB node.

[0175] In certain embodiments, the CU1 receives a portion of the traffic that was previously offloaded from the CU1 to the CU2.

[0176] In certain embodiments, the CU1 has an F1 termination node and the CU2 has an F1 non-termination node.

[0177] In certain embodiments, the first message indicates the amount of traffic related to the portion of the offloaded traffic that is returned to CU1.

[0178] In certain embodiments, CU1 determines that CU1 has the ability to process the portion of the offloaded traffic that is returned to CU1 before sending the first message.

[0179] In certain embodiments, CU1 determines that a condition is met, and in response to determining that the condition is met, the first message is sent to CU2, where the condition includes at least one of determining that a timer has expired, identifying an increase in traffic load at the target donor node, identifying that the traffic at the target donor node has increased by more than a threshold amount, identifying a decrease in traffic load at the source donor node, and identifying that the traffic at the source donor node has decreased by more than a threshold amount.

[0180] In certain embodiments, CU1 receives from CU2 a second message indicating at least one resource to be released by CU2.

[0181] In certain embodiments, the first message from CU2 starts returning a portion of the offloaded traffic to CU1, and the method includes sending to CU2 a second message that determines that a portion of the offloaded traffic is being returned to CU1.

[0182] In certain embodiments, the first message indicates at least one permitted resource associated with the portion of the offloaded traffic that is returned to CU1.

[0183] In certain embodiments, at least one permitted resource includes at least one of a downlink resource and / or an uplink resource.

[0184] In certain embodiments, CU1 sends to at least one IAB node information related to the portion of the offloaded traffic that is returned to CU1.

[0185] In another particular embodiment, the information sent to at least one IAB node includes a routing table.

[0186] FIG. 20 is a diagram illustrating a method 800 by CU2 of an IAB network according to a particular embodiment. According to the method, at 802, CU2 sends a first message to CU1 or receives a first message from CU1. The first message includes information indicating that a portion of the offloaded traffic is returned to CU1, and the offloaded traffic was previously offloaded from CU1 to CU2.

[0187] In certain embodiments, before sending or receiving the first message, CU2 receives the offloaded traffic.

[0188] In another particular embodiment, the offloaded traffic is terminated at a migrating IAB node.

[0189] In certain embodiments, CU1 has an F1 terminating node and CU2 has an F1 non-terminating node.

[0190] In certain embodiments, the first message indicates the traffic volume related to the portion of the offloaded traffic that is returned to CU1.

[0191] In certain embodiments, CU2 determines that CU2 does not have the ability to process the portion of the offloaded traffic that is returned to CU1.

[0192] In certain embodiments, CU2 determines that a condition has been met and, in response to determining that the condition has been met, a first message is sent to CU1. The condition includes at least one of the following: determining that a timer has expired, identifying an increase in traffic load at the target donor node, identifying that traffic at the target donor node has increased by more than a threshold amount, identifying a decrease in traffic load at the source donor node, and identifying that traffic at the source donor node has decreased by more than a threshold amount.

[0193] In certain embodiments, CU2 receives from CU1 a second message indicating at least one resource to be released by CU2.

[0194] In certain embodiments, receiving the first message from CU1 initiates the return of a portion of the offloaded traffic to CU1, and CU2 sends to CU1 a second message for determining that a portion of the offloaded traffic is being returned to CU1.

[0195] In certain embodiments, the first message indicates at least one permitted resource associated with the portion of the offloaded traffic that is returned to CU1.

[0196] In certain embodiments, the at least one permitted resource includes at least one of a downlink resource and / or an uplink resource.

[0197] In certain embodiments, CU2 sends to at least one IAB node information related to the portion of the offloaded traffic that is returned to CU1.

[0198] In another particular embodiment, the information sent to the at least one IAB node includes a routing table.

[0199] Exemplary Embodiments Exemplary Embodiment of Group A

[0200] Exemplary Embodiment A1 A method by a user equipment for temporary and / or adaptive load distribution in an integrated access and backhaul (IAB) network, having any one of the steps, features, or functions of the user equipment described above alone or in combination with other steps, features, or functions described above.

[0201] Exemplary Embodiment A2 A method of the previous embodiment, further comprising one or more of the additional steps, features or functions of the user equipment described above.

[0202] Exemplary Embodiment A3 Any method of the previous embodiments, further comprising providing user data and transferring the user data to a host computer through transmission to a network node.

[0203] Exemplary Embodiment of Group B

[0204] Exemplary Embodiment B1 A method executed by a network node for temporary and / or adaptive load distribution in an integrated access and backhaul (IAB) network, having any one of the steps, features, or functions described above alone or in combination with other steps, features, or functions described above. Network Node of the steps, features, or functions described above alone or in combination with other steps, features, or functions described above.

[0205] Exemplary Embodiment B2 A method of the previous embodiment, further comprising one or more of the additional steps, features or functions of the network node described above.

[0206] Exemplary Embodiment B3 Any method of the previous embodiments, further comprising obtaining user data and transferring the user data to a host or user device.

[0207] Exemplary Embodiment of Group C

[0208] Example Embodiment C1 A method by a source donor node for temporary and / or adaptive load distribution in an integrated access and backhaul (IAB) network, the method comprising: determining traffic to be offloaded from the source donor node and / or traffic to be offloaded from a target donor node; and transmitting information related to the traffic to be offloaded from the source donor node and / or the traffic to be offloaded from the target donor node to the target donor node.

[0209] Example Embodiment C2 The method of Example Embodiment C1, wherein the traffic is related to a migrating IAB node.

[0210] Example Embodiment C3 The method according to any one of Example Embodiments C1 to C2, wherein the traffic is determined for offloading from the source donor node to the target donor node.

[0211] Example Embodiment C4 The method of Example Embodiment C3, further comprising determining that the source donor node cannot process the traffic to be offloaded from the source donor node to the target donor node.

[0212] Example Embodiment C5 The method according to any one of Example Embodiments C3 to C4, further comprising determining an amount of traffic that the source donor node cannot process for offloading from the source donor node to the target node, and wherein the information indicates the amount of traffic for offloading from the source donor node to the target donor node.

[0213] Example Embodiment C6 The method according to any one of Example Embodiments C3 to C5, wherein the information includes at least one required resource for the traffic to be offloaded from the source node to the target node.

[0214] Exemplary Embodiment C7 The method of Exemplary Embodiment C6, wherein the at least one requested resource includes at least one of a downlink resource and / or an uplink resource.

[0215] Exemplary Embodiment C8 The method according to any one of Exemplary Embodiments C5 to C7, further comprising receiving, from the target donor node, a response message indicating at least one permitted resource.

[0216] Exemplary Embodiment C9 The method of Exemplary Embodiment C8, wherein the at least one permitted resource includes at least one requested resource indicated in the information transmitted to the target donor node.

[0217] Exemplary Embodiment C10 The method of Exemplary Embodiment C8, wherein the at least one permitted resource does not include the resource requested in the information transmitted to the target donor node.

[0218] Exemplary Embodiment C11 The method according to any one of Exemplary Embodiments C5 to C7, further comprising receiving, from the target donor node, a response message indicating that there are no available resources at the target donor node.

[0219] Exemplary Embodiment C12 The method according to any one of Exemplary Embodiments C3 to C11, further comprising offloading the traffic to the target donor node.

[0220] Exemplary Embodiment C13 The method according to any one of Exemplary Embodiments C3 to C12, further comprising transmitting, to at least one IAB node, information related to the traffic to be offloaded to the target donor node.

[0221] Exemplary Embodiment C14. The method of Exemplary Embodiment C13, wherein the information transmitted to the at least one IAB node includes a routing table.

[0222] Exemplary Embodiment C15. The method of any one of Exemplary Embodiments C1 to C2, wherein the traffic is determined for offloading from the target donor node to the source donor node.

[0223] Exemplary Embodiment C16. The method of Exemplary Embodiment C15, wherein the traffic to be offloaded from the target donor node to the source donor node includes traffic previously offloaded from the source donor node to the target donor node.

[0224] Exemplary Embodiment C17. The method of any one of Exemplary Embodiments C15 to C16, further comprising determining that the source donor node can process the traffic offloaded from the target donor node to the source donor node.

[0225] Exemplary Embodiment C18. The method of any one of Exemplary Embodiments C15 to C17, further comprising receiving, from the target donor node, a message indicating a traffic volume for offloading from the target donor node to the source donor node.

[0226] Exemplary Embodiment C19. The method of any one of Exemplary Embodiments C15 to C18, wherein the information transmitted from the target donor node indicates at least one permitted resource related to the traffic offloaded from the target donor node to the source donor node.

[0227] Exemplary Embodiment C20. The method of Exemplary Embodiment C119, wherein the at least one permitted resource includes at least one of a downlink resource and / or an uplink resource.

[0228] Exemplary Embodiment C21 The method according to any one of Embodiments C15 to C20, further comprising receiving, from the target donor node, a response message indicating one or more release resources to be released by the target donor node.

[0229] Exemplary Embodiment C22 The method according to Embodiment C21, wherein the at least one release resource includes the at least one permitted resource specified by the information transmitted to the target donor node.

[0230] Exemplary Embodiment C23 The method according to Embodiment C21, wherein the at least one release resource does not include the permitted resource specified by the information transmitted to the target donor node.

[0231] Exemplary Embodiment C24 The method according to any one of Embodiments C15 to C20, further comprising receiving, from the target donor node, a response message indicating that there are no resources to be released by the target donor node.

[0232] Exemplary Embodiment C25 The method according to any one of Embodiments C15 to C23, further comprising receiving at least a part of the traffic offloaded from the target donor node to the source donor node.

[0233] Exemplary Embodiment C26 The method according to any one of Embodiments C15 to C25, further comprising transmitting, to at least one IAB node, information related to the traffic offloaded from the target donor node to the source donor node.

[0234] Exemplary Embodiment C27 The method according to Embodiment C26, wherein the information transmitted to the at least one IAB node includes a routing table.

[0235] Exemplary Embodiment C28 Further including maintaining a timer by the source donor node, the determining step being executed when the timer expires, the method according to any one of Exemplary Embodiments C1 to C27.

[0236] Exemplary Embodiment C29 Further including maintaining a timer by the source donor node, the information being transmitted to the target donor node when the timer expires, the method according to any one of Exemplary Embodiments C1 to C28.

[0237] Exemplary Embodiment C30 The information transmitted to the target donor node includes a traffic congestion status indicating whether the source donor node has the ability to process the traffic offloaded from the target donor node and / or the traffic offloaded from the source donor node to the target donor node, the method according to any one of Exemplary Embodiments C1 to C29.

[0238] Exemplary Embodiment C31 Further including maintaining a timer by the source donor node, the traffic congestion status being transmitted to the target donor node when the timer expires, the method of Exemplary Embodiment C30.

[0239] Exemplary Embodiment C32 Further including determining that a condition is satisfied, and in response to determining that the condition is satisfied, transmitting the traffic congestion status to the target donor node, the method of Exemplary Embodiment C30.

[0240] Exemplary Embodiment C33 The condition includes at least one of identifying an increase in traffic load, identifying that the traffic has increased beyond a threshold, identifying a decrease in traffic load, and identifying that the traffic has decreased beyond a threshold, the method of Exemplary Embodiment C32.

[0241] Exemplary Embodiment C34 Further comprising receiving a traffic congestion status from the target donor node, the traffic congestion status indicating whether the target donor node has the ability to process the traffic to be offloaded from the source donor node and / or the traffic to be offloaded from the target donor node to the source donor node, the method according to any one of Exemplary Embodiments C1 to C33.

[0242] Exemplary Embodiment C35 The method according to Exemplary Embodiment C34, further comprising sending a request for the traffic congestion status of the target donor node to the target donor node.

[0243] Exemplary Embodiment C36 The method according to Exemplary Embodiment C35, further comprising maintaining a timer, wherein the request for the traffic congestion status is sent to the target donor node when the timer expires.

[0244] Exemplary Embodiment C37 The traffic congestion status indicates the amount of traffic that the source donor node and / or the target donor node has the ability to process, the method according to any one of Exemplary Embodiments C30 to C36.

[0245] Exemplary Embodiment C38 A method according to any one of Exemplary Embodiments C1 to C37, further comprising providing user data and transferring the user data to a host via transmission to the network node.

[0246] Exemplary Embodiment C39 A source donor node having a processing circuit configured to execute the method according to any one of Exemplary Embodiments C1 to C38.

[0247] Exemplary Embodiment C40 A source donor node configured to execute any of the methods according to Exemplary Embodiments C1 to C38.

[0248] A computer program which, when executed on a computer, includes instructions for performing any one of the methods of Exemplary Embodiments C1 to C38.

[0249] Exemplary Embodiment C42 A computer program to possesses of the A computer program product, wherein the computer program includes instructions for performing any one of the methods of Exemplary Embodiments C1 to C38 when executed on a computer.

[0250] Exemplary Embodiment C43 A non-transitory computer-readable medium storing instructions for performing any one of the methods of Exemplary Embodiments C1 to C38 when executed on a computer.

[0251] Exemplary Embodiments of Group D

[0252] Exemplary Embodiment D1 A method by a target donor node for temporary and / or adaptive load distribution in an integrated access and backhaul (IAB) network, comprising determining traffic to be offloaded from the target donor node and / or traffic to be offloaded from a source donor node, and transmitting information related to the traffic to be offloaded from the target donor node and / or the traffic to be offloaded from the source donor node to the source donor node.

[0253] Exemplary Embodiment D2 The method of Exemplary Embodiment D1, wherein the traffic is related to a migrating IAB node.

[0254] Exemplary Embodiment D3 The method according to any one of Exemplary Embodiments D1 to D2, wherein the traffic is determined for offloading from the source donor node to the target donor node.

[0255] Exemplary Embodiment D4 Determining the traffic to be offloaded from the source donor node includes receiving a request from the source donor node, the request specifying the amount of traffic to be offloaded from the source donor node, the method of Exemplary Embodiment D3.

[0256] Exemplary Embodiment D5 The method of Exemplary Embodiments D3 to D4 further includes determining that the target donor node can process the traffic to be offloaded from the source donor node.

[0257] Exemplary Embodiment D6 The method of any one of Exemplary Embodiments D3 to D5 further includes determining the amount of traffic that the target donor node can process for offloading from the source donor node to the target node, the information indicating the amount of traffic that the target donor node can process for offloading from the source donor node to the target donor node.

[0258] Exemplary Embodiment D7 The information Donor from the source Donor node to the target node includes at least one permitted resource for the traffic to be offloaded, the method of any one of Exemplary Embodiments D3 to D6.

[0259]

[0260] Exemplary Embodiment D8 The method of Exemplary Embodiment D7, wherein the at least one permitted resource includes at least one of a downlink resource and / or an uplink resource.

[0261] Example Embodiment D10. The method according to any one of Example Embodiments D7 to D8, further comprising receiving, from the source donor node, a response message indicating that the source donor node does not need to offload the traffic to the target donor node.

[0262] Example Embodiment D11. The method according to any one of Example Embodiments D3 to D10, further comprising receiving at least a part of the traffic offloaded to the target donor node.

[0263] Example Embodiment D12. The method according to any one of Example Embodiments D3 to D11, further comprising transmitting, to at least one IAB node, information related to the traffic to be offloaded to the target donor node.

[0264] Example Embodiment D13. The method of Example Embodiment D12, wherein the information transmitted to the at least one IAB node includes a routing table.

[0265] Example Embodiment D14. The method according to any one of Example Embodiments D1 to D2, wherein the traffic is determined for offloading from the target donor node to the source donor node.

[0266] Example Embodiment D15. The method of Example Embodiment D14, wherein determining the traffic to be offloaded from the target donor node includes receiving, from the source donor node, a message indicating that the source donor node is capable of processing the traffic to be offloaded from the target donor node.

[0267] Example Embodiment D16. The method of Example Embodiment D15, wherein the message from the source donor node indicates the amount of traffic that the source donor node is capable of processing.

[0268] Exemplary Embodiment D17 The method according to any one of Exemplary Embodiments D14 to D16, further comprising determining that the target donor node cannot process the traffic to be offloaded from the target donor node.

[0269] Exemplary Embodiment D18 The method according to any one of Exemplary Embodiments D14 to D17, further comprising determining a traffic volume for offloading from the target donor node to the source node, wherein the information indicates the traffic volume for offloading from the target donor node to the source donor node.

[0270] Exemplary Embodiment D19 The method according to any one of Exemplary Embodiments D14 to D18, wherein the traffic to be offloaded from the target donor node to the source donor node includes traffic previously offloaded from the source donor node to the target donor node.

[0271] Exemplary Embodiment D20 The method according to any one of Exemplary Embodiments D14 to D19, wherein the information indicates at least one released resource associated with the traffic to be offloaded from the target donor node to the source Donor node.

[0272] Exemplary Embodiment D21 The method according to Exemplary Embodiment D20, wherein the at least one released resource includes at least one of a downlink resource and / or an uplink resource.

[0273] Exemplary Embodiment D22 The method according to any one of Exemplary Embodiments D20 to D22, further comprising receiving, from the source donor node, a response message indicating at least one permitted resource associated with the traffic to be offloaded from the target donor node to the source Target node.

[0274] Exemplary Embodiment D23 The method of Exemplary Embodiment D22, wherein the at least one permitted resource in the response message includes the at least one released resource identified by the information transmitted to the source donor node.

[0275] Exemplary Embodiment D24 The method of Exemplary Embodiment D22, wherein the at least one permitted resource in the response message does not include the released resource identified by the information transmitted by the target donor node to the source network node.

[0276] Exemplary Embodiment D25 The method according to any one of Exemplary Embodiments D20 to D21, further comprising receiving, from the source donor node, a response message indicating that there is no resource to be accepted by the source donor node.

[0277] Exemplary Embodiment D26 The method according to any one of Exemplary Embodiments D14 to D25, further comprising offloading at least a part of the traffic to the source donor node.

[0278] Exemplary Embodiment D27 The method according to any one of Exemplary Embodiments D14 to D26, further comprising transmitting, to at least one IAB node, information related to the traffic to be offloaded from the target donor node to the source donor node.

[0279] Exemplary Embodiment D28 The method of Exemplary Embodiment D27, wherein the information transmitted to the at least one IAB node includes a routing table.

[0280] Exemplary Embodiment D29 The method according to any one of Exemplary Embodiments D1 to D28, further comprising maintaining a timer by the target donor node, wherein the determining step is executed when the timer expires.

[0281] Exemplary Embodiment D30 Further including maintaining a timer by the target donor node, wherein the information is transmitted to the source donor node when the timer expires, the method of any one of Exemplary Embodiments D1 to D29.

[0282] Exemplary Embodiment D31 The information transmitted to the source donor node includes a traffic congestion status indicating whether the target donor node has the ability to process the traffic to be offloaded from the source donor node and / or the traffic to be offloaded from the target donor node to the source donor node, the method of any one of Exemplary Embodiments D1 to D30.

[0283] Exemplary Embodiment D32 Further including maintaining a timer by the target donor node, wherein the traffic congestion status is transmitted to the source donor node when the timer expires, the method of Exemplary Embodiment D31.

[0284] Exemplary Embodiment D33 Further including determining that a condition is satisfied, and in response to determining that the condition is satisfied, transmitting the traffic congestion status to the source donor node, the method of Exemplary Embodiment D31.

[0285] Exemplary Embodiment D34 The condition includes at least one of identifying an increase in traffic load, identifying that the traffic has increased beyond a threshold, identifying a decrease in traffic load, and identifying that the traffic has decreased beyond a threshold, the method of Exemplary Embodiment D33.

[0286] Exemplary Embodiment D35 Further including receiving a traffic congestion status from the source donor node, the traffic congestion status indicating whether the source donor node has the ability to process the traffic to be offloaded from the source donor node to the target donor node and / or the traffic to be offloaded from the target donor node to the source donor node, a method according to any one of Exemplary Embodiments D1 to D34.

[0287] Exemplary Embodiment D36 The method according to Exemplary Embodiment D35, further including transmitting a request for the traffic congestion status of the source donor node to the source donor node.

[0288] Exemplary Embodiment D37 The method according to Exemplary Embodiment D36, further including maintaining a timer, and the request for the traffic congestion status being transmitted to the source donor node when the timer expires.

[0289] Exemplary Embodiment D38 The traffic congestion status indicates the amount of traffic that the source donor node and / or the target donor node has the ability to process, a method according to any one of Exemplary Embodiments D31 to D37.

[0290] Exemplary Embodiment D39 Further including providing user data and transferring the user data to a host through transmission to a network node, a method according to any one of Exemplary Embodiments D1 to D38.

[0291] Exemplary Embodiment D40 A target donor node having a processing circuit configured to execute the method according to any one of Exemplary Embodiments D1 to D39.

[0292] Exemplary Embodiment D41 A target donor node configured to execute any one of the methods according to Exemplary Embodiments D1 to D39.

[0293] Exemplary Embodiment D42 A computer program including instructions that, when executed on a computer, execute any of the methods of Exemplary Embodiments D1 through D39.

[0294] Exemplary Embodiment D43 A computer program product having a computer program, wherein the computer program includes instructions that, when executed on a computer, execute any of the methods of Exemplary Embodiments D1 through D39.

[0295] Exemplary Embodiment D44 A non-transitory computer-readable medium storing instructions that, when executed on a computer, execute any of the methods of Exemplary Embodiments D1 through D39.

[0296] Exemplary Embodiments of Group E

[0297] Exemplary Embodiment E1 A network node for temporary and / or adaptive load distribution in an integrated access and backhaul (IAB) network, having a processing circuit configured to execute any of the steps of any of the exemplary embodiments of Groups A and B, and a power supply circuit configured to supply power to the processing circuit.

[0298] Exemplary Embodiment E2 A host configured to operate in a communication system to provide an over-the-top (OTT) service, having a processing circuit configured to provide user data, and a network interface configured to initiate transmission of the user data to a network node in a cellular network for transmission to a user equipment (UE), wherein the network node has a communication interface and a processing circuit, and the processing circuit of the network node is configured to execute any operation of any of the exemplary embodiments of Groups A and B to transmit the user data from the host to the UE.

[0299] Exemplary Embodiment E3 A host of the previous exemplary embodiment, wherein the processing circuit of the host is configured to execute a host application that provides the user data, and the UE has a processing circuit configured to execute a client application associated with the host application to receive the transmission of the user data from the host.

[0300] Exemplary Embodiment E4 A method implemented on a host configured to operate in a communication system further including a network node and a user equipment (UE), the method including providing user data to the UE and initiating a transmission to carry the user data to the UE via a cellular network having the network node, wherein the network node performs any operation of either Exemplary Embodiment A or B to transmit the user data from the host to the UE.

[0301] Exemplary Embodiment E5 A method of the previous exemplary embodiment, further comprising, at the network node, transmitting user data provided by the host for the UE.

[0302] Exemplary Embodiment E6 A method of any of the previous two exemplary embodiments, wherein the user data is provided at the host by executing a host application that interacts with a client application running on the UE, and the client application is associated with the host application.

[0303] Exemplary Embodiment E7 A communication system configured to provide an over-the-top service, the communication system having a host, the host having a processing circuit configured to provide user data for a user equipment (UE), where the user data is associated with the over-the-top service, and a network interface configured to initiate transmission of the user data towards a cellular network for transmission to the UE, the network node having a communication interface and a processing circuit, the processing circuit of the network node being configured to perform any operation of any of the embodiments of Group A and B for transmitting the user data from the host to the UE.

[0304] Exemplary Embodiment E8 Further, a communication system of the previous exemplary embodiments having the network node and / or the user equipment.

[0305] Exemplary Embodiment E9 A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host having a processing circuit configured to initiate reception of user data and a network interface configured to receive the user data from a network node within a cellular network, the network node having a communication interface and a processing circuit, the processing circuit of the network node being configured to perform any operation of any of the exemplary embodiments of Group A and B for receiving the user data for the host from a user equipment (UE).

[0306] Exemplary Embodiment E10 The processing circuit of the host is configured to execute a host application, thereby providing the user data, the host application being configured to communicate with a client application operating on the UE, the client application being associated with the host application. The host of the previous two exemplary embodiments.

[0307] Exemplary embodiment E11 The host of the two previous embodiments, wherein starting to receive the user data includes requesting the user data.

[0308] Exemplary embodiment E12 A method implemented by a host configured to operate in a communication system further including a network node and a user equipment (UE), the method including, at the host, starting to receive user data from the UE, wherein the user data originates from a transmission received by the network node from the UE, and the network node performs any operation of any of the exemplary embodiments of groups A and B to receive the user data from the UE for the host.

[0309] Exemplary embodiment E13 The method of the previous exemplary embodiment, further including, at the network node, transmitting the received user data to the host.

Claims

1. A method by a first Central Unit (CU1) in an Integrated Access and Backhaul (IAB) network, comprising: sending a first message to a second CU (CU2), or receiving the first message from the CU2, wherein the first message includes information indicating that a part of the offloaded traffic should be returned to the CU1, and the offloaded traffic was previously offloaded from the CU1 to the CU2.

2. The method according to claim 1, further comprising: offloading the offloaded traffic from the CU1 to the CU2 before sending the first message.

3. The method according to claim 2, wherein the offloaded traffic is terminated at a migrating IAB node.

4. The method according to claim 1, further comprising receiving the part of the offloaded traffic that was previously offloaded from the CU1 to the CU2.

5. The method according to claim 1, wherein the CU1 has an F1 terminating node, and the CU2 has an F1 non-terminating node.

6. The method according to claim 1, wherein the first message indicates a traffic volume related to the part of the offloaded traffic to be returned to the CU1.

7. The method according to claim 1, further comprising determining that the CU1 has the ability to process the part of the offloaded traffic to be returned to the CU1.

8. The method according to claim 1, further comprising determining that a condition is met, and the first message is sent to the CU2 in response to determining that the condition is met, wherein the condition includes determining that a timer has expired, identifying an increase in traffic load at the CU2, identifying that the traffic at the CU2 has increased beyond a threshold, identifying a decrease in traffic load at the CU1, and identifying that the traffic at the CU1 has decreased beyond a threshold, and includes one or more of the above.

9. The method according to claim 7, further comprising receiving from the CU2 a second message indicating one or more resources to be released by the CU2.

10. The method according to claim 1, wherein the first message indicates at least one permitted resource related to the part to be returned to the CU1 of the offloaded traffic.

11. The method according to claim 1, further comprising transmitting information related to the part to be returned to the CU1 of the offloaded traffic to at least one IAB node.

12. The method according to claim 11, wherein the information transmitted to the at least one IAB node includes a routing table.

13. A method by a second central unit (CU2) in an integrated access and backhaul (IAB) network, comprising: transmitting a first message to the CU1 or receiving a first message from the CU1, wherein the first message has information indicating that a part of the offloaded traffic should be returned to the CU1, and the offloaded traffic was previously offloaded from the CU1 to the CU2.

14. The method according to claim 13, wherein the CU1 has an F1 termination node, and the CU2 has an F1 non-termination node.

15. The method according to claim 13, wherein the first message indicates the traffic volume related to the part to be returned to the CU1 of the offloaded traffic.

16. The method according to claim 13, further comprising determining that a condition is satisfied, and the first message is transmitted to the CU1 in response to determining that the condition is satisfied, and the condition includes: determining that a timer has expired, identifying an increase in traffic load at the CU2, identifying that the traffic at the CU2 has increased beyond a threshold, identifying a decrease in traffic load at the CU1, and identifying that the traffic at the CU1 has decreased beyond a threshold, including one or more of the above.

17. The method according to claim 16, further comprising receiving from the CU1 a second message indicating one or more resources to be released by the CU2.

18. The method according to claim 13, wherein the first message indicates at least one permitted resource related to the part to be returned to the CU1 of the offloaded traffic.

19. The method according to claim 18, wherein the at least one permitted resource comprises a downlink resource, and / or an uplink resource, at least one of them.

20. The method according to claim 13, further comprising transmitting information related to the part to be returned to the CU1 of the offloaded traffic to at least one IAB node.

21. A first central unit (CU1) in an integrated access and backhaul (IAB) network, comprising configured to transmit a first message to a second CU (CU2) or receive the first message from the CU2, wherein the first message has information indicating that a part of the offloaded traffic should be returned to the CU1, wherein the offloaded traffic was previously offloaded from the CU1 to the CU2, CU1.

22. The CU1 according to claim 21, further configured to execute the method according to any one of claims 2 to 12.

23. A second central unit (CU2) in an integrated access and backhaul (IAB) network, comprising configured to transmit the first message to the CU1 or receive the first message from the CU1, wherein the first message has information indicating that a part of the offloaded traffic should be returned to the CU1, wherein the offloaded traffic was previously offloaded from the CU1 to the CU2, CU2.

24. The CU2 according to claim 23, further configured to execute the method according to any one of claims 14 to 20.

Images