Support IAB CP signaling over LTE

Abstract

A method performed by a first network node in an integrated access and wireless access backhaul (IAB) network is provided. The method includes sending one or more stream control transmission protocol / internet protocol (SCTP / IP) packets to a second network node over a long term evolution (LTE) radio in the IAB network in the absence of a new radio (NR) link between the first network node and the second network. The one or more SCTP / IP packets include F1-application protocol (F1-AP) signaling.

Description

Technical Field

[0001] The present disclosure relates generally to wireless communications, and more particularly, to systems and methods for supporting integrated access and radio access backhaul (IAB) control plane (CP) signaling over long term evolution (LTE). Background Art

[0002] The 3rd Generation Partnership Project (3GPP) is currently standardizing Integrated Access and Radio Access Backhaul (IAB) in New Radio (NR) in Release 16 (RP-RP-182882).

[0003] The use of short-range mmWave spectrum in NR creates a need for dense deployments with multi-hop backhaul. However, fiber to each base station is too costly and sometimes even impossible (e.g., at historical sites). The main IAB principle is to use wireless links (rather than fiber) for backhaul to enable flexible and very dense cell deployments without densifying the transport network. Use case scenarios for IAB can include coverage extension, deployment of a large number of small cells, and fixed wireless access (FWA) (e.g., to residential / office buildings). The larger bandwidth available for NR in mmWave spectrum provides opportunities for self-backhauling without limiting the spectrum used for access links. Most importantly, the inherent multi-beam and multiple-input multiple-output (MIMO) support in NR reduces cross-link interference between backhaul and access links, allowing higher densification.

[0004] During the study project phase of the IAB work (a summary of the study project can be found in the technical report 3GPP TR 38.874), it was agreed to adopt a solution that leverages the Central Unit (CU) / Distributed Unit (DU) split architecture of NR, where the IAB node hosts the DU part controlled by the Central Unit. The IAB node also has its own Mobile Termination (MT) part that it uses to communicate with its parent node.

[0005] The specifications for IAB seek to reuse existing functions and interfaces defined in NR. Specifically, the MT, gNodeB distributed unit (gNB-DU), gNodeB central unit (gNB-CU), user plane function (UPF), access and mobility management function (AMF), and session management function (SMF), and the corresponding interfaces NR Uu (between MT and gNB), F1, NG, X2, and N4 are used as the baseline for the IAB architecture. Modifications or enhancements to these functions and interfaces to support IAB will be explained in the context of the architecture discussion. Additional functions, such as multi-hop forwarding, are included in the architecture discussion because it is necessary to understand the operation of IAB and some aspects may require standardization.

[0006] The MT functionality has been defined as an integral part of the IAB Node. In the context of this study, MT is referred to as a function residing on the IAB Node that terminates the radio interface layer of the backhaul Uu interface towards the IAB Donor or other IAB nodes.

[0007] Figure 1 A high-level architectural view of an IAB network is shown. More specifically, Figure 1 A reference diagram for the IAB in standalone mode, taken from 3GPP TR 38.874, is shown, which contains one IAB donor and multiple IAB nodes. The IAB donor is considered to be a single logical node, which includes, for example, the gNodeB distributed unit (gNB-DU), the gNodeB central unit control plane (gNB-CU-CP), the gNodeB central unit user plane (gNB-CU-UP), and possibly a collection of other functions. In a deployment, the IAB donor can be split according to these functions, which can all be collocated or non-collocated, as allowed by the 3GPP Next Generation Radio Access Network (NG-RAN) architecture. When such a split is made, aspects related to the IAB may arise. Similarly, if it is clear that some of the functions currently associated with the IAB donor do not perform IAB-specific tasks, these functions can eventually be moved outside of the donor.

[0008] Figure 2 The baseline user protocol stack for IAB in Rel-16 is shown. FIG. 3A to FIG. 3C The baseline control plane protocol stack for IAB in Rel-16 is shown. As shown, the selected protocol stack reuses the current CU-DU split specification in Release 15, where the complete user plane F1-U (GTP-U / UDP / IP) is terminated at the IAB node (like a conventional DU) and the complete control plane F1-C (F1-AP / SCTP / IP) is also terminated at the IAB node (like a conventional DU). In the above case, Network Domain Security (NDS) has been adopted to protect both UP and CP services (IPsec in the UP case and Datagram Transport Layer Security (DTLS) in the control plane (CP) case). IPsec can also be used for CP protection instead of DTLS (in this case, the DTLS layer will not be used).

[0009] A new protocol layer called Backhaul Adaptation Protocol (BAP) is introduced in IAB nodes and IAB donors, which is used to route packets to suitable downstream / upstream nodes and map User Equipment (UE) bearer data to suitable backhaul Radio Link Control (RLC) channels (and between ingress and egress backhaul RLC channels in intermediate IAB nodes) to meet the end-to-end Quality of Service (QoS) requirements of the bearers.

[0010] At the RAN2#105 meeting, the modeling of the adaptation layer was discussed and the following consensus was reached:

[0011] RAN2 confirms routing and bearer mapping (e.g., mapping of backhaul (BH) RLC channels) as an adaptation layer function

[0012] R2 assumes that the transmit (TX) part of the adaptation layer performs routing and "bearer mapping", and the receive (RX) part of the adaptation layer performs "bearer demapping"

[0013] • R2 assumes that for packets relayed by an IAB node, a Service Data Unit (SDU) is forwarded from the RX part of the Adaptation Layer to the TX part of the Adaptation Layer (for the next hop).

[0014] How to model the protocol entities, e.g. whether DU and MT are separated, and how these are configured, F1-AP or Radio Resource Control (RRC), is left for future study.

[0015] Although there is no final agreement in RAN2, there is consensus to include the BAP entity in both the MT and DU parts of the IAB node protocol stack.Modeling the BAP layer in this way helps to implement the routing and mapping functions of the adaptation layer.

[0016] Before discussing the operation of these two BAP entities, the first thing to consider is whether the radio bearers carrying CP / UP traffic for the MT function of the IAB node should be treated separately from the backhaul radio link control (BH RLC) channel. Note that the BH RLC channel is used to carry traffic to / from the IAB DU function, which can be intended for UEs served by the IAB node or for child IAB nodes. They (e.g., radio bearers and BH RLC channels) should be treated separately by adopting different logical channel IDs.

[0017] The downlink (DL) procedure follows:

[0018] 1. When a packet arrives at IAB donor DU (from donor CU) and is first processed by upper layers (as there is no MT BAP layer at donor DU).

[0019] a) If the packet is destined for a UE directly connected to the IAB Donor DU, or it is F1-AP traffic destined for the IAB Donor DU, it is forwarded to higher layers (IP / UDP / GTP-U for UP and IP / SCTP / F1-AP for CP).

[0020] b) Otherwise (i.e., it is to be forwarded further downstream), it is forwarded to the DU BAP layer.

[0021] 2. When a packet arrives at the IAB node via the backhaul RLC channel (from the parent IAB node or the IAB donor DU), it is first processed by the MT BAP layer.

[0022] a) If the packet is destined for a UE directly connected to the IAB node, or is F1-AP traffic destined for a DU of the IAB node, it is forwarded to higher layers (IP / UDP / GTP-U for UP and IP / SCTP / F1-AP for CP).

[0023] b) Otherwise (i.e., it is to be forwarded further downstream), it is forwarded to the DU BAP layer.

[0024] In both 1b and 2b above, the DU BAP will determine to which route the packet has to be forwarded (ie to which sub-node) and which BH RLC channel within that route will be used to forward the packet downstream (the input information for BH RLC mapping is still under discussion in RAN2).

[0025] The uplink (UL) procedure follows:

[0026] 1. When a packet arrives at the IAB donor DU via the backhaul RLC channel (from the child IAB node), it is first processed by the DU BAP layer and forwarded to the donor CU (since the donor DU can be connected to at most one donor CU, no routing function is required).

[0027] 2. When the packet reaches the IAB node in the UL direction:

[0028] a. If it comes from the child IAB node via the backhaul RLC channel, it is first processed by the DU BAP layer and since the destination of every UL packet is to be forwarded to the donor CU, it is passed to the MT BAP layer.

[0029] b. If the packet comes from a UE directly connected to the IAB node, or it is F1-AP traffic originating from the IAB node, it is first processed by higher layers (IP / UDP / GTP-U for UP and IP / SCTP / F1-AP for CP) and forwarded to the MTBAP layer.

[0030] In both 2a and 2b above, the MT BAP will determine to which route (ie which parent node) the packet has to be forwarded and which BH RLC channel within that route will be used to forward the packet upstream.

[0031] Figure 4 An example IAB node integration process is shown. The setup and configuration (i.e., integration) of an IAB node is the first step in the operation of an IAB node. The integration process includes the following steps:

[0032] 1. MT Settings

[0033] MT selects a parent node (the process is for further study (FFS)).

[0034] MT authenticates AMF (Uu process).

[0035] The AMF authorizes the MT at the gNB (signalling agreed at RAN3#103).

[0036] The gNB establishes SRB with the MT (Uu process).

[0037] The gNB can establish a data radio bearer (DRB) and protocol data unit (PDU) session with the MT (Uu procedure; whether FFS is necessary).

[0038] PDU sessions can be used for operations and maintenance (OAM) connections.

[0039] 2. Backhaul settings

[0040] • Establishment of BH RLC channel between IAB node MT and parent node.

[0041] • RAN2 decides that the configuration is made by the CU-CP (eg using Radio Resource Control (RRC)).

[0042] • To this end, the CU-CP of the MT needs to know that the MT belongs to the IAB node rather than the UE, which can be derived from the MT authorization (agreed at RAN3#103), for example.

[0043] · The BH RLC channel must also be marked with the corresponding priority / QoS level at the IAB node MT and the parent node.

[0044] · Establishment of adapted routing between IAB node MT and IAB donor DU. This includes:

[0045] Configuration of Adaptation Routing Identifiers on IAB Node MT and IAB Donor DU (RAN2; FFS); and

[0046] • Routing entry configuration on all ancestor nodes of the IAB nodes for the new routing identifier (RAN2; FFS).

[0047] • IP address allocation to the IAB node for the adapted interface, which can be routed from the wired fronthaul via the adapted route.

[0048] • The IP address must be specific to the IAB Donor DU so that the CU can send IP packets to the IAB nodes via that specific IAB Donor DU and new adapted routes. The IAB Donor DU must support a pool of IP addresses routable from the wired fronthaul for all descendant IAB nodes.

[0049] • If the IP assignment is made by the CU, the CU must know the available IP address pool of the IAB Donor DU for the IAB nodes.

[0050] • If IP assignment is made via DHCPv4 / 6 with DHCP proxy on the IAB Donor DU (as proposed in the TR), then the ARP / NDP transport mechanism above the adaptation layer needs to be defined.

[0051] There can be other options for IP address allocation.

[0052] 3.DU Settings

[0053] DU establishes F1-C and cell activation using IP over the adaptation layer (procedures defined in TS 38.401 Section 8.5: F1 Startup and Cell Activation).

[0054] • This includes OAM support for IAB node DUs via the backhaul IP layer.

[0055] It is important to note that the proposed architecture option (Option 1a in 3GPP TR 38.874) can manage IP address assignment within the Radio Access Network (RAN) without the involvement of the Core Network (CN). In this regard, the above baseline allows IP address assignment based on Dynamic Host Configuration Protocol (DHCP) and setting up OAM after IP address assignment without the need for MT to establish a PDU session. The three parts of the entire IAB node integration process are discussed below.

[0056] 1. MT function settings

[0057] The IAB node will first connect via its MT function using the RRC setup procedure. After the RRC connection setup, the MT function of the IAB node can perform non-access stratum (NAS) level registration and authentication, but does not need to establish a PDU session, such as Fig.12 shown.

[0058] After NAS registration, a UE context for the IAB node can be created in the Radio Access Network (RAN) (without any PDU session resources). In this way, the IAB node does not need to support any SMF / UPF functions. NAS Rel-15 has separated NAS registration from PDU session establishment, so that only registration can be performed without setting up a PDU session, and UE context can be set up in the RAN without PDU session resources.

[0059] 2. Backhaul settings

[0060] Once the UE context for the IAB node is set up in the RAN, the RAN will establish one or more backhaul bearers that can be used for IP address assignment to the IAB node. For the case where the IAB node does not communicate directly with the IAB donor node, but via other (already attached / connected) IAB nodes, the forwarding information in all intermediate IAB nodes will be updated due to the setup of the new IAB node.

[0061] 3. DU function settings

[0062] After establishing the connection with the operator's internal network, the DU function of the IAB node and its cell / sector needs to be configured through OAM, and then the DU can send an F1 SETUP REQUEST message to its corresponding CU (i.e., IAB-CU). The proposed IAB architecture option supports full IP connectivity with the IAB node, so that the DU function can have a direct IP connection with OAM without relying on the MT function to establish a special PDU session for OAM in the core network (CN).

[0063] Finally, after configuring the DU functionality of the IAB node, the IAB node starts operating as a DU and the UE will not be able to distinguish it from other gNBs. Therefore, it can start serving the UE like any other DU / gNB.

[0064] The process of initial IAB node access can be based on the UE initial access signaling flow, with slight modifications to meet the IAB node requirements. At the same time, for the activation of the IAB node DU cell, the F1 activation and cell activation process defined in 3GPP TS 38.401 can be reused as is. Considering the above situation, the present disclosure proposes a process for integrating the IAB node into the NG-RAN, as described below and as Fig.12 shown.

[0065] IAB initial access and MT function settings

[0066] 1. The IAB node sends an RRCSetupRequest message to the gNB-DU.

[0067] 2. The gNB-DU includes the RRC message and (if the IAB node is admitted) the corresponding lower layer configuration for the NR Uu interface in an INITIAL UL RRC TRANSFER message and transmits it to the gNB-CU. The INITIAL UL RRC TRANSFER message includes the Cell Radio Network Temporary Identifier (C-RNTI) allocated by the gNB-DU.

[0068] 3. The gNB-CU allocates the gNB-CU UE F1AP ID to the IAB node and generates an RRCSetup message towards the IAB node. The RRC message is encapsulated in a DL RRC MESSAGE TRANSFER message.

[0069] 4. The gNB-DU sends an RRCSetup message to the IAB node.

[0070] 5. The IAB node sends an RRC CONNECTION SETUP COMPLETE message to the gNB-DU. The S-NSSAI IE in the RRC CONNECTION SETUP COMPLETE message indicates the IAB node.

[0071] 6. The gNB-DU encapsulates the RRC message in a UL RRC MESSAGE TRANSFER message and sends it to the gNB-CU.

[0072] 7. The gNB-CU sends an INITIAL UE MESSAGE to the AMF. This can be a dedicated AMF serving only IAB nodes.

[0073] At this point, the IAB node will perform registration (including authentication and key generation) without establishing a PDU session.

[0074] 8. AMF sends an INITIAL CONTEXT SETUP REQUEST message to the gNB-CU.

[0075] 9. The gNB-CU sends an IAB CONTEXT SETUP REQUEST message to establish the IAB node context in the gNB-DU. In this message, it can also encapsulate the SecurityModeCommand message.

[0076] 10. The gNB-DU sends a SecurityModeCommand message to the IAB node.

[0077] 11. The gNB-DU sends an IAB CONTEXT SETUP RESPONSE message to the gNB-CU.

[0078] 12. The IAB node responds with a SecurityModeComplete message.

[0079] 13. The gNB-DU encapsulates the RRC message in a UL RRC MESSAGE TRANSFER message and sends it to the gNB-CU.

[0080] 14. The gNB-CU generates an RRCReconfiguration message and encapsulates it in a DL RRCMESSAGE TRANSFER message. The RRCReconfiguration message may include the configuration of one or more IAB backhaul bearers.

[0081] 15. The gNB-DU sends an RRCReconfiguration message to the IAB node.

[0082] 16. The IAB node sends an RRCReconfigurationComplete message to the gNB-DU.

[0083] 17. The gNB-DU encapsulates the RRC message in a UL RRC MESSAGE TRANSFER message and sends it to the gNB-CU.

[0084] 18. The gNB-CU sends an INITIAL CONTEXT SETUP RESPONSE message to the AMF.

[0085] IAB node DU cell activation

[0086] At this point, the IAB node will establish one or more backhaul bearers, which can be used to create a transport network layer (TNL) connection towards the gNB-CU and obtain a TNL address (e.g., IP address and port assignment). Next, the IAB node can utilize the F1 startup and cell activation procedures described in TS38.401 to activate its cell and begin operation.

[0087] IAB node is ready to serve UE

[0088] After activating its cell, the IAB node starts operating and can serve the UE. The UE can connect to the IAB node via the UE initial access procedure described in TS 38.401.

[0089] Bearer Mapping in IAB Network

[0090] The IAB node needs to multiplex the UE DRB to the BH RLC channel. The following two options can be considered for bearer mapping in the IAB node.

[0091] The first option is a one-to-one mapping between UE DRBs and BH RLC channels. Figure 5 An example of a one-to-one mapping between UE DRBs and BH RLC channels is shown. According to this option, each UE DRB is mapped to a separate BH RLC channel. In addition, each BH RLC is mapped to a separate BH RLC channel on the next hop. The number of established BH RLC channels is equal to the number of established UE DRBs.

[0092] Identifiers (eg for UE and / or DRB) may be needed (eg if multiple BH RLC channels are multiplexed into a single BH logical channel). Which exact identifiers are needed, and which of these are placed in the adaptation layer header depends on the architecture / protocol options.

[0093] The second option is a many-to-one mapping between UE DRBs and BH RLC channels. Figure 6 An example of a many-to-one mapping between UE DRBs and BH RLC channels is shown. For many-to-one mapping, several UE DRBs are multiplexed onto a single BH RLC channel based on specific parameters such as the bearer QoS profile. Other information, such as the number of hops, can also be configured. The IAB node can multiplex UE DRBs into a single BH RLC channel even if they belong to different UEs. In addition, packets from one BH RLC channel can be mapped to different BH RLC channels on the next hop. All services mapped to a single BH RLC channel receive the same QoS treatment on the air interface.

[0094] Since the BH RLC channel multiplexes data from / to multiple bearers and possibly even different UEs, each data block sent in the BH RLC channel needs to contain an identifier of the UE, DRB and / or IAB node with which it is associated. Which exact identifiers are needed, and which of these are placed in the adaptation layer header, depends on the architecture / protocol options.

[0095] Support for both N:1 and 1:1 mappings has been agreed in Release 16.

[0096] For 1:1 bearer mapping, it has been agreed to use the IPv6 Flow Label field, where the donor DU is configured to map IP packets marked with a given flow label to a specific LCID on the first backhaul link between the donor DU and the first downstream IAB node. For the case of N:1 mapping, the working assumption is that the DSCP field in the IP header can be used for mapping purposes (in order to also support IPv4 networks). However, there is a discussion whether to have a unified behavior, where IPv6 flow labels can also be used for N:1 mapping. It is also possible to consider using a combination of flow label and DSCP fields for 1:1 mapping

[0097] IAB deployment in Evolved Universal Terrestrial Radio Access Network – New Radio – Dual Connectivity (EN-DC) mode

[0098] IAB is a feature where an NR radio base station (IAB node) is backhauled via an NR radio link to a donor radio base station (gNB). It has been agreed to support IAB using NR standalone operation as well as non-standalone (NSA) operation, in which the IAB node is also connected to the Long Term Evolution (LTE) radio interface and the LTE radio base station for handling control plane signaling.

[0099] Under NSA NR deployment, the IAB network must operate in EN-DC mode (i.e., LTE as the primary node and NR as the secondary node). Fig.11 An example of IAB deployment in EN-DC mode is shown. 3GPP has agreed that NR traffic will be backhauled over the NR leg and LTE traffic must go over the LTE leg (i.e. no NR traffic is sent over the LTE leg and vice versa).

[0100] There are certain challenges currently. For example, it has been proposed that the IAB node operates in non-standalone mode to support NR IAB-related control plane signaling (between the donor gNB and the IAB node) via LTE. The motivation for doing this is that if the NR link is lost for some reason (e.g., radio link failure), critical NR IAB-related signaling can be performed via the LTE link. In addition, if there are several hops in the IAB network, sending CP traffic via the LTE branch can ultimately be faster than sending it via multiple hops. The proposed approach is to tunnel the IAB-related F1-AP signaling messages to the LTE eNB via X2 signaling and embed them in the LTE RRC signaling towards the IAB node over the LTE radio.

[0101] This approach has certain disadvantages. One disadvantage of this proposed approach is that it is not very straight forward to support F1-AP signaling messages via LTE as suggested in the above contributions, since currently the F1-AP signaling protocol relies on functionality provided by its lower layers (e.g. SCTP and IP), which is now proposed to be handled by LTE RRC and X2-AP. For example

[0102] - The IP layer provides addressing information so that multiple F1-AP connections can be set up (for example, in the case where an IAB node supports multiple DU instances).

[0103] - The SCTP layer provides reliable in-order delivery of F1-AP messages that the F1-AP protocol expects from lower layers.

[0104] -SCTP also has additional features that may be required by higher layers, such as keep-alive signaling, multi-homing, etc.

[0105] - Not using SCTP on the LTE leg makes it difficult to guarantee lossless, duplication-free, in-order delivery of F1-AP messages that have been sent down to the SCTP layer used over the NR radio link but have not yet been delivered end-to-end (e.g., when the NR radio link is lost). Summary of the invention

[0106] Certain aspects of the present disclosure and embodiments thereof may provide solutions to these or other challenges. The present disclosure introduces a mechanism for a New Radio (NR) donor gNodeB (gNB) to exchange F1-Application Protocol (F1-AP) signaling with an Integrated Access and Radio Access Backhaul (IAB) node over a Long Term Evolution (LTE) radio using a solution where entire Stream Control Transmission Protocol / Internet Protocol (SCTP / IP) packets are passed between the NR donor gNB and the IAB node.

[0107] According to certain embodiments, a method performed by a first network node in an IAB network is provided. The method includes: sending one or more SCTP / IP packets to a second network node over a Long Term Evolution (LTE) radio in the IAB network in the absence of an NR link between the first network node and the second network. The one or more SCTP / IP packets include F1-Application Protocol (F1-AP) signaling.

[0108] According to certain embodiments, a first network node includes a processing circuit configured to send one or more SCTP / IP packets to a second network node over a Long Term Evolution (LTE) radio in an IAB network in the absence of an NR link between the first network node and the second network. The one or more SCTP / IP packets include F1-Application Protocol (F1-AP) signaling.

[0109] Certain embodiments may provide one or more of the following technical advantages. As an example, a technical advantage may be: Certain embodiments may support reliable delivery of NR IAB-related signaling between a donor gNB and an IAB node via an LTE radio, which may be used, for example, when the NR radio link encounters problems or is lost. In certain embodiments, the methods described herein achieve this by transmitting complete (or entire) SCTP / IP packets (or Internet Protocol Packet Data Units (IP PDUs)) over the LTE radio and between the LTE eNB and the NR donor gNB. By passing the entire SCTP / IP packet, features provided by SCTP / IP may advantageously still be used, such as:

[0110] - End-to-end SCTP guaranteed delivery, which advantageously avoids the need to support / specify LTE mechanisms to handle reliable delivery;

[0111] -SCTP multi-homing ensures seamless / lossless handover to LTE in case of NR link loss;

[0112] - Other SCTP features such as duplicate removal, Quality of Service (QoS) flows, in-order delivery, etc.; and

[0113] - IP addressing mechanism that allows multiple SCTP connections. BRIEF DESCRIPTION OF THE DRAWINGS

[0114] For a more complete understanding of the disclosed embodiments and their features and advantages, reference is now made to the following description in conjunction with the accompanying drawings, in which:

[0115] Figure 1 shows a high-level architectural view of an integrated access and radio access backhaul (IAB) network;

[0116] Figure 2 shows the baseline user protocol stack for IAB in Rel-16;

[0117] FIG. 3A to FIG. 3C shows the baseline control plane protocol stack of IAB in Rel-16;

[0118] Figure 4 An example IAB node integration process is shown;

[0119] Figure 5 An example of a one-to-one mapping between a User Equipment Data Radio Bearer (UE DRB) and a Backhaul Radio Link Control Channel (BHRLC channel) is shown;

[0120] Figure 6 An example of many-to-one mapping between UE DRBs and BH RLC channels is shown;

[0121] Figure 7 An example of IAB deployment in EN-DC mode is shown;

[0122] Figure 8 illustrates an example wireless network in accordance with certain embodiments;

[0123] Fig. 9 illustrates an example network node according to certain embodiments;

[0124] Fig.10 An example wireless device according to certain embodiments is shown;

[0125] Fig.11 illustrates an example user device according to certain embodiments;

[0126] Fig.12 shows a virtualized environment according to some embodiments, in which functions implemented by some embodiments may be virtualized;

[0127] Fig.13 An example method performed by a network node according to certain embodiments is shown;

[0128] Fig.14 Another exemplary virtual computing device according to certain embodiments is shown;

[0129] Fig.15 illustrates an example method performed by a network node according to some embodiments; and

[0130] Fig.16 Another exemplary virtual computing device in accordance with certain embodiments is shown. DETAILED DESCRIPTION

[0131] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as being limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. Additional information may also be found in the files provided in the appendix.

[0132] Generally, unless clearly given and / or different meanings are implied from the context in which the term is used, all terms used in this article will be interpreted according to their common meaning in the relevant technical field. Unless otherwise clearly stated, all references to one / one / described element, equipment, assembly, device, step, etc. should be openly interpreted as referring to at least one example in element, equipment, assembly, device, step, etc. Unless a step must be clearly described as after or before another step and / or a step must be after or before another step implicitly, the steps of any method disclosed herein do not have to be performed in the exact order disclosed. Where applicable, any feature of any embodiment disclosed herein may be applied to any other embodiment. Similarly, any advantage of any embodiment may be applicable to any other embodiment, and vice versa. By the following description, other purposes, features and advantages of the attached embodiments will be apparent.

[0133] According to certain embodiments, methods, systems, and techniques are disclosed for a solution for an NR donor gNB to use the entire SCTP / IP packet to be passed between the NR donor gNB and the IAB node, exchanging F1-AP signaling with the IAB node over LTE radio. This method can be used to pass F1-AP signaling even if the NR link is lost. By passing the entire SCTP / IP packet, features provided by SCTP / IP can still be used, such as:

[0134] - End-to-end SCTP guaranteed delivery, avoiding the need to support / specify LTE mechanisms to handle reliable delivery.

[0135] -SCTP multi-homing, ensuring seamless / lossless handover to LTE in case of NR link loss

[0136] - Other SCTP features such as duplicate removal, QoS flows, in-order delivery, ...

[0137] - IP addressing mechanism that allows multiple SCTP connections.

[0138] Several mechanisms for delivering an entire SCTP / IP packet (or IP PDU) are considered and described in detail below, including:

[0139] - Mechanism for sending IP PDUs over LTE radio via X2-AP and RRC signaling (ie embedding IP PDUs in X2 / RRC signaling messages).

[0140] -Mechanism for the IAB node to set up a separate Packet Data Network (PDN) connection from the IAB node to the 4G EPC core over the LTE radio. This PDN connection can be associated with an IP address belonging to the operator's own internal IP network. The IAB node can then use this PDN connection / IP address to set up an F1-AP / SCTP signaling connection with the donor gNB.

[0141] -Mechanism for the network to set up a special RLC bearer or radio bearer (DRB) in the LTE eNB towards the IAB node over the LTE radio. This special bearer can then be used for IP-based traffic between the IAB node and the donor gNB over the LTE radio. On the hop between the LTE eNB and the donor gNB, a GTP tunnel associated with the bearer will be set up, allowing the LTE eNB to map IP PDUs between the bearer on the radio and the GTP tunnel to / from the donor gNB.

[0142] According to certain embodiments, a mechanism is disclosed that enables signaling to be exchanged between an IAB node and its donor gNB via LTE using full IP packets. Certain embodiments may include one or more of the following:

[0143] - Sending IP PDUs over the LTE radio via X2-AP and RRC signaling (ie, embedding IP PDUs in X2 / RRC signaling messages).

[0144] -Set up a separate PDN connection from the IAB node to the 4G EPC core over the LTE radio. This PDN connection can be associated with an IP address belonging to the operator's own internal IP network. The IAB node can then use this PDN connection / IP address to set up an F1-AP / SCTP signaling connection with the donor gNB.

[0145] -A special RLC bearer or radio bearer (DRB) is set up in the LTE eNB towards the IAB node over the LTE radio. This special bearer can then be used for IP-based traffic between the IAB node and the donor gNB over the LTE radio. On the hop between the LTE eNB and the donor gNB, a GTP tunnel associated with the bearer will be set up, allowing the LTE eNB to map IP PDUs between the bearer on the radio and the GTP tunnel to / from the donor gNB.

[0146] Furthermore, according to certain embodiments, mechanisms are introduced to handle IP assignment, setup of SCTP and / or F1 connections, and handling of nodes with different capabilities.

[0147] According to certain embodiments, a method performed by a network node is disclosed. The method includes sending one or more SCTP / IP packets to another network node over an LTE radio.

[0148] According to a specific embodiment, the one or more SCTP / IP packets may include one or more complete SCTP / IP packets. In a specific embodiment, the one or more SCTP / IP packets may include IAB control plane signaling. In a specific embodiment, the one or more SCTP / IP packets may include F1-AP signaling.

[0149] In particular embodiments, the one or more SCTP / IP packets may be sent in the absence of a NR link.

[0150] In a particular embodiment, the network node may be one of the NR donor gNB and the IAB node. In a particular embodiment, the other network node may be one of the NR donor gNB and the IAB node.

[0151] According to certain embodiments, the method may further comprise obtaining an IP address allocated for use when communicating via LTE. In certain embodiments, NAS signalling may be used to obtain the IP address.

[0152] In a particular embodiment, the IP address may be allocated by the OAM system. In a particular embodiment, obtaining the IP address may include: sending a message to the OAM system; and receiving configuration information indicating the allocated IP address in response to the message. In a particular embodiment, the IP address may be allocated using a method specified by the Internet Engineering Task Force (IETF) including one or more of DHCP and IPv6 host discovery. In a particular embodiment, the IP address may be obtained in an RRC message from an LTE eNB. In a particular embodiment, obtaining the IP address may include: implicitly assigning the IP address using an IP address received in a DL packet. In a particular embodiment, the one or more SCTP / IP packets may include the allocated IP address.

[0153] According to certain embodiments, the method may include setting up an SCTP connection to another network node. In certain embodiments, setting up the SCTP connection to another network node may be performed in response to an indication from another network node that an auxiliary SCTP connection is needed. In certain embodiments, setting up the SCTP connection to another network node may be performed in response to a radio link failure.

[0154] According to certain embodiments, the method may include sending capability information to one or more of the other node and the LTE node.In certain embodiments, the method may include receiving capability information from one or more of the other node and the LTE node.

[0155] According to some embodiments, the method may include encrypting one or more of the one or more SCTP / IP packets. In a particular embodiment, the one or more SCTP / IP packets may be encrypted using IPsec.

[0156] In certain embodiments, one or more SCTP / IP packets may be sent over the LTE radio via X2-AP and RRC signaling. In certain embodiments, one or more SCTP / IP packets may be embedded in an X2 / RRC signaling message. In certain embodiments, the method may include: generating an F1-AP message; placing the F1-AP message in an SCTP packet; placing the SCTP packet in an IP PDU; placing the IP PDU in an RRC message; and sending the RRC message to the LTE node. In certain embodiments, the RRC message may be an UL transmit message.

[0157] In certain embodiments, the one or more SCTP / IP packets may be sent via a separate PDN connection with the core network.In certain embodiments, the method may include establishing a separate PDN connection with the core network using one or more NAS protocols.

[0158] In a particular embodiment, the one or more SCTP / IP packets may be sent via one of an RLC bearer and a radio bearer in the LTE eNB. In a particular embodiment, the one or more SCTP / IP packets may be sent via a GTP tunnel associated with one of the RLC bearer and the radio bearer.

[0159] In certain embodiments, the method may include obtaining user data; and forwarding the user data to a host computer or a wireless device.

[0160] In a particular embodiment, the entire IP packet (including higher layers, such as SCTP) is carried over the LTE radio between the IAB node and the donor gNB. To achieve this, one or more of the following aspects may be supported.

[0161] IP Address Allocation

[0162] The IAB node may be assigned one or more separate IP addresses to use when communicating via LTE. When the donor gNB wants to send an IP packet to the IAB node, it will send the packet using one of the IAB addresses assigned for this purpose. The packet will then be routed via LTE. Similarly, when the IAB node wants to send an IP packet via LTE, it will include the assigned IP address (IAB address).

[0163] IP addresses may be assigned using several mechanisms, including (but not limited to) those described below:

[0164] - It can be allocated using NAS signaling (e.g. when an IAB node registers or attaches to the LTE network). The advantage of this approach is that functionality in the network can be reused.

[0165] - It may be assigned by the OAM system serving the IAB nodes. For example, when the IAB nodes are powered on, they may contact the OAM system and in response may receive configuration information. The advantage of this approach is that the functionality will only affect the OAM system and associated interfaces.

[0166] -It can be assigned using IETF specified methods such as DHCP or IPv6 host discovery. In this case, a "logical channel" or L2 connection can be established in LTE, where the IAB node uses this "logical channel" or L2 connection to perform DHCP or IPv6 signaling. The advantage of this method is that functions in the network can be reused. This method can also advantageously avoid core network impact, thereby reducing network cost / complexity.

[0167] - It can be explicitly assigned by the RRC layer (eg, in an RRC message from the LTE eNB to the IAB node). The advantage of this approach is that it can also avoid core network impact, thereby reducing network cost / complexity.

[0168] - It may be implicitly assigned by the IAB using the same IP address it received in the DL packet. The advantage of this approach is that functionality in the network can be reused.

[0169] As mentioned above, the above different approaches have their own advantages and disadvantages in terms of standards impact, complexity and performance. Other advantages and disadvantages besides the above may also be considered.

[0170] SCTP setup and F1 connection setup / association

[0171] When the IAB node has been allocated one or more IP addresses for sending IP packets via LTE, the IAB node may set up an SCTP connection to the donor gNB (or more precisely the donor gNB-CU-CP functionality). One possible approach is that this may be triggered by the donor gNB sending an indication to the IAB node that a secondary SCTP connection (over LTE) is required. Another possible approach is that it may be triggered by the IAB losing the NR link (e.g. due to radio link failure). In some embodiments, F1-AP signaling may be performed using the SCTP connection over LTE immediately after setup, or alternatively, IAB signaling will start at a later stage (e.g. when the NR link starts experiencing problems).

[0172] Ability-related aspects

[0173] Not all IAB nodes and / or donor gNBs and / or LTE nodes may support the feature of exchanging F1 signaling via LTE as described herein. To support scenarios where not all nodes support the feature, capability information may be exchanged between the nodes involved so that the feature may be used only if it is supported by all nodes or a subset of nodes. Examples of how this may be accomplished include (but are not limited to) those described below. These examples may be used in combination or individually:

[0174] -The IAB node may indicate to the donor gNB (e.g., donor gNB-CU-CP) and / or LTE eNB that it supports the feature or that it supports the feature and wants to use it. This indication may be sent to the donor gNB in ​​an RRC or F1-AP message. It may alternatively be included as a parameter in the UE radio access capabilities.

[0175] - The donor gNB may indicate to the IAB node that it supports the feature or that it supports the feature and wants to use it. This indication may be sent to the IAB node in an RRC or F1-AP message. It may alternatively be included in a broadcast message (e.g. as part of a system information broadcast).

[0176] - The LTE eNB may indicate to the IAB node that it supports the feature or that it supports the feature and wants to use it. This indication may be sent to the IAB node in the RRC. It may alternatively be included in a broadcast message (e.g. as part of a system information broadcast).

[0177] -The LTE eNB may indicate to the donor gNB that it supports the feature or that it supports the feature and wants to use it. This indication may be sent in an Xn or X2 message.

[0178] - The donor gNB may indicate to the LTE eNB that it supports the feature or that it supports the feature and wants to use it. This indication may be sent in an Xn or X2 message.

[0179] Using any one or more of the above methods, a node will be able to know whether the other node supports the feature, and only call the feature-related process if both parties support it.

[0180] Use of IP Security (IP Sec)

[0181] According to some embodiments, IP packets can be protected by IPsec operating in tunnel mode or transport mode, for example. In this case, the sending entity will encrypt packets according to IPsec principles, and the receiving node will decrypt the packets.

[0182] F1-AP signaling is sent in IP PDUs over the LTE radio via X2-AP and RRC signaling (ie, IP PDUs are embedded in X2 / RRC signaling messages).

[0183] According to certain embodiments, F1-AP signaling may be sent in IP PDUs over LTE radio via X2-AP and RRC signaling (i.e., embedding IP PDUs in X2 / RRC signaling messages). This approach is based on sending F1-AP signaling messages within SCTP packets within IP packets within X2 and RRC messages.

[0184] Following are some example procedures for the IAB node to send F1-AP message to the donor gNB and vice versa.

[0185] IAB node => Donor gNB:

[0186] The process starts with the IAB node generating an F1-AP message. This message may be placed inside an SCTP packet. The SCTP packet is placed into an IP addressed towards the donor DU. The IP PDU is then placed inside an RRC message. In principle, any RRC message may be considered (e.g., an RRC UL Transfer message). The actual ASN.1 encoding used to transfer the IP PDU may use an octet string type (as shown below), which is transparent to the RRC protocol machine (e.g., the RRC protocol machine only passes the content to higher layers):

[0187] --ASN1START

[0188] TunneledIAB-Packet ::=OCTET STRING

[0189] --ASN1STOP

[0190] The RRC message is then sent to the LTE eNB on one of the signaling radio bearers. When the LTE eNB receives the message, it will transparently forward the IP PDU to the NR gNB over the X2 interface. Based on knowing which secondary NR node the IAB node is connected to, the LTE eNB will know which node to forward the content to. The IP PDU can be sent within any X2 message such as X2-AP RRC Transfer or X2-AP SgNB Reconfiguration Complete. Again, the encoding of the IP PDU can be using an octet string type.

[0191] When the gNB receives the IP PDU, it can send it to its own IP stack. From this step, the IP / SCTP / F1-AP packet can be decoded as in the regular case when F1-AP is sent over the NR radio link.

[0192] Donor gNB => IAB node:

[0193] The process is similar to the above process, except that the donor gNB generates the F1-AP / SCTP / IP packet, which is then placed inside an X2-AP message and sent to the LTE eNB for delivery to the IAB node. The LTE eNB places the IP PDU into an RRC message. When the IAB node receives the RRC message, it unpacks the PDU and sends it to the IP stack UE.

[0194] F1-AP signaling is sent in IP PDUs via a separate PDN connection.

[0195] According to certain embodiments, F1-AP signaling may be sent in an IP PDU via a separate PDN connection. The method is based on the IAB node setting up a PDU connection to a 4G or EPC core network. The signaling process for setting up the connection used by the IAB node may be based on the signaling of the UE setting up the PDN connection (e.g., reusing the NAS protocol process). The following enhancements to the process for this case may be considered:

[0196] -The IAB node may provide an indication in one of the messages to the core network that it is an IAB node. This may be used by the core network to select a packet gateway (GW) that is responsible for supporting IP services between the RAN (e.g. donor gNB) and the IAB node.

[0197] - The subscription information stored in the Home Subscription Register in the core network may include an indication that the IAB node is an IAB node, again enabling the core network (eg MME) to select the correct packet GW (eg PDN GW).

[0198] - The CN may also provide instructions to a charging system or similar network element to implement a different charging policy for IAB node signaling compared to regular end users.

[0199] Once a separate PDN connection is established, the IAB node can use this connection to communicate with the donor gNB. For example, it can set up an SCTP / F1 connection and exchange F1-AP signaling messages. The IP address for this connection can be allocated as part of the PDN connection setup signaling.

[0200] F1-AP signaling is sent in IP PDU via a special RLC bearer

[0201] In accordance with certain embodiments, F1-AP signaling may be sent in an IP PDU via a special RLC bearer. In this approach, the network sets up a special RLC bearer or data radio bearer in the LTE eNB towards the IAB node over the LTE radio. This special bearer may then be used for IP-based services between the IAB node and the donor gNB over the LTE radio. The trigger to set up the bearer may be made in the LTE eNB (e.g., as a response to an IAB node connecting to the network). The bearer setup signaling may reuse portions of the DRB signaling towards the IAB node. However, the bearer may differ from a regular DRB in that a packet data convergence protocol (PDCP) layer may not need to be set up in the IAB node (e.g., only the RLC bearer portion is required because security protection for the F1-AP signaling may be provided by the IP layer using, for example, IPsec, which is how F1 signaling is protected when using NR links).

[0202] On the hop between the LTE eNB and the donor gNB, a GTP tunnel associated with the bearer may be set up, allowing the LTE eNB to map IP PDUs between the bearer on the radio and the GTP tunnel to / from the donor gNB. In this case, when the donor gNB wants to send an F1-AP / SCTP / IP PDU to the IAB node over the LTE radio, it may send the packet within a GTP / UDP / IP packet to the LTE eNB. The donor gNB may send the packet using a Tunnel Endpoint ID (TEID) associated with the special bearer. In a specific embodiment, this GTP TEID will be allocated by the LTE eNB and then signaled to the donor gNB using X2 signaling. In a specific embodiment, a different GTP tunnel may be used for UL packets from the IAB node to the donor gNB. In this case, the TEID may be allocated by the gNB and then sent in X2 signaling to the LTE eNB.

[0203] Over the radio interface, a bearer may be associated with a logical channel identifier that separates the F1-AP signaling from other data or signaling sent to / from the IAB node.

[0204] Figure 8 A wireless network according to some embodiments is shown. Although the subject matter described herein may be implemented in any suitable type of system using any suitable components, the embodiments disclosed herein are related to wireless networks (e.g. Figure 1 For simplicity, Figure 1The wireless network of FIG. 1 depicts only the network 106, the network nodes 160 and 160b, and the wireless devices 110, 110b, and 110c. In practice, the wireless network may also include any additional elements suitable for supporting communications between wireless devices or between a wireless device and another communication device (e.g., a landline phone, a service provider, or any other network node or terminal device). In the illustrated components, the network node 160 and the wireless device 110 are depicted in additional detail. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless devices to access and / or use services provided by or via the wireless network.

[0205] A wireless network may include and / or interface with any type of communication, telecommunication, data, cellular and / or radio network or other similar type of system. In some embodiments, a wireless network may be configured to operate according to a particular standard or other type of predefined rules or procedures. Thus, a particular embodiment of a wireless communication network may implement communication standards such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, or 5G standards; wireless local area network (WLAN) standards such as IEEE 802.11 standards; and / or any other suitable wireless communication standards such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, and / or ZigBee standards.

[0206] The network 106 may include one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTNs), packet data networks, optical networks, wide area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks to enable communications between devices.

[0207] The network node 160 and the wireless device 110 include various components described in more detail below. These components work together to provide network node and / or wireless device functions, such as providing wireless connectivity in a wireless network. In various embodiments, the wireless network may include any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals, whether via a wired connection or via a wireless connection.

[0208] Fig. 9An example network node according to certain embodiments is shown. As used herein, a network node refers to a device that is capable of, configured, arranged and / or operable to communicate directly or indirectly with a wireless device and / or with other network nodes or devices in a wireless network to implement and / or provide wireless access to a wireless device and / or perform other functions (e.g., management) in a wireless network. Examples of network nodes include, but are not limited to, IAB nodes, donor gNBs, LTE eNBs, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, NodeBs, evolved NodeBs (eNBs), and NR NodeBs (gNBs)). Base stations can be classified based on the amount of coverage they provide (or in other words, based on their transmit power levels), so they can also be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station can be a relay node or a relay host node that controls a relay. A 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 referred to as a remote radio head (RRH)). Such a remote radio unit may or may not be integrated with an antenna as an antenna-integrated radio. Portions of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS). Some further examples of network nodes include multi-standard radio (MSR) equipment (such as an MSR BS), a network controller (such as a radio network controller (RNC) or a base station controller (BSC)), a base transceiver station (BTS), a transmission point, a transmission node, a multi-cell / multicast coordination entity (MCE), a core network node (e.g., MSC, MME), an O&M node, an OSS node, a SON node, a positioning node (e.g., E-SMLC), and / or an MDT. As another example, a network node may be a virtual network node, as described in more detail below. However, more generally, a network node may represent any suitable device (or device group) as follows: the device (or device group) is capable of, configured, arranged, and / or operable to implement and / or provide access to a wireless network to a wireless device, or to provide a certain service to a wireless device that has accessed a wireless network.

[0209] exist Fig. 9 In FIG. 1 , the network node 160 includes a processing circuit 170, a device readable medium 180, an interface 190, an auxiliary device 184, a power supply 186, a power supply circuit 187, and an antenna 162. Fig. 9The network node 160 shown in the example wireless network of can represent a device including a combination of the hardware components shown, but other embodiments can include network nodes having different combinations of components. It should be understood that the network node includes any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. In addition, although the components of the network node 160 are depicted as a single box located within a larger box or nested within multiple boxes, in reality, the network node may include multiple different physical components that constitute a single illustrated component (for example, the device readable medium 180 may include multiple separate hard drives and multiple RAM modules).

[0210] Similarly, the network node 160 may be composed of multiple physically separated components (e.g., NodeB components and RNC components, or BTS components and BSC components, etc.), each of which may have its own corresponding components. In certain scenarios where the network node 160 includes multiple separated components (e.g., BTS and BSC components), one or more of these separated components may be shared between several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair may be considered a single separate network node in some instances. In some embodiments, the network node 160 may be configured to support multiple radio access technologies (RATs). In such an embodiment, some components may be replicated (e.g., separate device-readable media 180 for different RATs), and some components may be reused (e.g., the same antenna 162 may be shared by the RATs). The network node 160 may also include multiple groups of various components shown for different wireless technologies (e.g., GSM, WCDMA, LTE, NR, WiFi, or Bluetooth wireless technologies) integrated into the network node 160. These wireless technologies may be integrated into the same or different chips or chipsets and other components within the network node 160 .

[0211] The processing circuitry 170 is configured to perform any determination, calculation, or similar operation (e.g., certain obtaining operations) described herein as being provided by the network node. Such operations performed by the processing circuitry 170 may include processing information obtained by the processing circuitry 170 by, for example, converting the obtained information into other information, comparing the obtained information or the converted information with information stored in the network node, and / or performing one or more operations based on the obtained information or the converted information and making a determination based on the results of the processing.

[0212] The processing circuit 170 may include a combination of one or more of the following: a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic, which is operable to provide network node 160 functions alone or in combination with other network node 160 components (e.g., device readable medium 180). For example, the processing circuit 170 may execute instructions stored in the device readable medium 180 or stored in a memory within the processing circuit 170. Such functions may include providing any of the various wireless features, functions, or benefits discussed herein. In some embodiments, the processing circuit 170 may include a system on a chip (SOC).

[0213] In some embodiments, processing circuitry 170 may include one or more of radio frequency (RF) transceiver circuitry 172 and baseband processing circuitry 174. In some embodiments, radio frequency (RF) transceiver circuitry 172 and baseband processing circuitry 174 may be located on separate chips (or chipsets), boards, or units (e.g., a radio unit and a digital unit). In alternative embodiments, part or all of RF transceiver circuitry 172 and baseband processing circuitry 174 may be on the same chip or chipset, board, or unit.

[0214] In some embodiments, some or all of the functions described herein as being provided by a network node, base station, eNB, or other such network device may be performed by a processing circuit 170 that executes instructions stored on a device-readable medium 180 or a memory within the processing circuit 170. In alternative embodiments, some or all of the functions may be provided by the processing circuit 170, for example, in a hardwired manner, without executing instructions stored on a separate or discrete device-readable medium. In any of these embodiments, the processing circuit 170 may be configured to perform the described functions, whether or not executing instructions stored on a device-readable storage medium. The benefits provided by such functions are not limited to the processing circuit 170 or to other components of the network node 160, but are enjoyed by the network node 160 as a whole and / or by end users and the wireless network as a whole.

[0215] Device readable medium 180 may include any form of volatile or non-volatile computer readable memory, including but not limited to permanent storage devices, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disk (CD) or digital video disk (DVD)), and / or any other volatile or non-volatile, non-transitory device readable and / or computer executable memory device that stores information, data and / or instructions that can be used by processing circuit 170. Device readable medium 180 may store any suitable instructions, data or information, including computer programs, software, applications including one or more of logic, rules, codes, tables, etc., and / or other instructions that can be executed by processing circuit 170 and used by network node 160. Device readable medium 180 may be used to store any calculations made by processing circuit 170 and / or any data received via interface 190. In some embodiments, processing circuit 170 and device readable medium 180 may be considered to be integrated.

[0216] The interface 190 is used for wired or wireless communication of signaling and / or data between the network node 160, the network 106 and / or the wireless device 110. As shown, the interface 190 includes a port / terminal 194 for sending data to the network 106 and receiving data from the network 106, for example, via a wired connection. The interface 190 also includes a radio front-end circuit 192, which can be coupled to the antenna 162, or in some embodiments is a part of the antenna 162. The radio front-end circuit 192 includes a filter 198 and an amplifier 196. The radio front-end circuit 192 can be connected to the antenna 162 and the processing circuit 170. The radio front-end circuit can be configured to adjust the signal communicated between the antenna 162 and the processing circuit 170. The radio front-end circuit 192 can receive digital data, which will be sent out to other network nodes or wireless devices via a wireless connection. The radio front-end circuit 192 can use a combination of filters 198 and / or amplifiers 196 to convert the digital data into a radio signal with suitable channel and bandwidth parameters. The radio signal can then be sent through the antenna 162. Similarly, when receiving data, antenna 162 may collect radio signals, which may then be converted to digital data by radio front end circuitry 192. The digital data may be passed to processing circuitry 170. In other embodiments, the interface may include different components and / or different combinations of components.

[0217] In certain alternative embodiments, the network node 160 may not include a separate radio front end circuit 192, and instead, the processing circuit 170 may include the radio front end circuit and may be connected to the antenna 162 without a separate radio front end circuit 192. Similarly, in some embodiments, all or some of the RF transceiver circuit 172 may be considered part of the interface 190. In other embodiments, the interface 190 may include one or more ports or terminals 194, the radio front end circuit 192, and the RF transceiver circuit 172 as part of a radio unit (not shown), and the interface 190 may communicate with the baseband processing circuit 174 as part of a digital unit (not shown).

[0218] Antenna 162 may include one or more antennas or antenna arrays configured to send and / or receive wireless signals. Antenna 162 may be coupled to radio front-end circuit 190 and may be any type of antenna capable of wirelessly sending and receiving data and / or signals. In some embodiments, antenna 162 may include one or more omnidirectional, sectored or flat panel antennas operable to send / receive radio signals between, for example, 2 GHz and 66 GHz. Omnidirectional antennas may be used to send / receive radio signals in any direction, sectored antennas may be used to send / receive radio signals to / from devices within a specific area, and flat panel antennas may be line-of-sight antennas for sending / receiving radio signals in a relatively straight line. In some cases, the use of more than one antenna may be referred to as MIMO. In some embodiments, antenna 162 may be separated from network node 160 and may be connected to network node 160 via an interface or port.

[0219] Antenna 162, interface 190 and / or processing circuit 170 can be configured to perform any receiving operation and / or certain obtaining operation described herein as being performed by a network node. Any information, data and / or signal can be received from a wireless device, another network node and / or any other network device. Similarly, antenna 162, interface 190 and / or processing circuit 170 can be configured to perform any sending operation described herein as being performed by a network node. Any information, data and / or signal can be sent to a wireless device, another network node and / or any other network device.

[0220] The power circuit 187 may include a power management circuit or be coupled to a power management circuit and is configured to provide power to the components of the network node 160 to perform the functions described herein. The power circuit 187 may receive power from the power supply 186. The power supply 186 and / or the power circuit 187 may be configured to provide power to the various components of the network node 160 in a form suitable for the various components (e.g., at the voltage and current levels required by each respective component). The power supply 186 may be included in the power circuit 187 and / or the network node 160 or outside the power circuit 187 and / or the network node 160. For example, the network node 160 may be connected to an external power source (e.g., a power outlet) via an input circuit or an interface such as a cable, whereby the external power source supplies power to the power circuit 187. As another example, the power supply 186 may include a power source in the form of a battery or a battery pack, which is connected to or integrated in the power circuit 187. If the external power source fails, the battery can provide backup power. Other types of power sources, such as photovoltaic devices, may also be used.

[0221] Alternative embodiments of network node 160 may include beyond Fig. 9 , which may be responsible for providing certain aspects of the functionality of the network node, including any of the functionality described herein and / or any functionality required to support the subject matter described herein. For example, the network node 160 may include a user interface device to allow information to be input into the network node 160 and to allow information to be output from the network node 160. This may allow a user to perform diagnostic, maintenance, repair, and other management functions for the network node 160.

[0222] Fig.10An example wireless device 110 is shown according to certain embodiments. As used herein, a wireless device refers to a device capable of, configured to, arranged to, and / or operable to communicate wirelessly with a network node and / or other wireless devices. Unless otherwise noted, the term wireless device may be used interchangeably with user equipment (UE) herein. Wireless transmission may include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information through the air. In some embodiments, a wireless device may be configured to send and / or receive information without direct human interaction. For example, a wireless device may be designed to send information to a network on a predetermined schedule when triggered by an internal or external event, or in response to a request from the network. Examples of wireless devices include, but are not limited to, smart phones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, portable computers, portable embedded devices (LEEs), portable installation equipment (LMEs), smart devices, wireless customer premises equipment (CPEs), vehicle-mounted wireless terminal devices, etc. The wireless device may support device-to-device (D2D) communication, vehicle-to-vehicle (V2V) communication, vehicle-to-infrastructure (V2I) communication, vehicle-to-anything (V2X) communication, for example, by implementing the 3GPP standard for sidelink communication, and in this case may be referred to as a D2D communication device. As another specific example, in an Internet of Things (IoT) scenario, a wireless device may represent a machine or other device that performs monitoring and / or measurement and sends the results of such monitoring and / or measurement to another wireless device and / or network node. In this case, the wireless device may be a machine-to-machine (M2M) device, which may be referred to as an MTC device in the 3GPP context. As a specific example, the wireless device may be a UE that implements the 3GPP Narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices are sensors, metering devices (e.g., electricity meters), industrial machines, or household or personal devices (e.g., refrigerators, televisions, etc.), personal wearable devices (e.g., watches, fitness trackers, etc.). In other scenarios, the wireless device may represent a vehicle or other device that is capable of monitoring and / or reporting its operating status or other functions associated with its operation. The wireless device as described above may represent an endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. In addition, the wireless device as described above may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

[0223] As shown, the wireless device 110 includes an antenna 111, an interface 114, a processing circuit 120, a device-readable medium 130, a user interface device 132, an auxiliary device 134, a power supply 136, and a power supply circuit 137. The wireless device 110 may include multiple groups of one or more of the components shown for different wireless technologies supported by the wireless device 110 (e.g., GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, to mention just a few). These wireless technologies may be integrated into the same or different chips or chipsets as other components within the wireless device 110.

[0224] Antenna 111 may include one or more antennas or antenna arrays configured to send and / or receive wireless signals, and is connected to interface 114. In some alternative embodiments, antenna 111 may be separated from wireless device 110 and may be connected to wireless device 110 via an interface or port. Antenna 111, interface 114 and / or processing circuit 120 may be configured to perform any receiving or transmitting operation described herein as being performed by a wireless device. Any information, data and / or signal may be received from a network node and / or another wireless device. In some embodiments, radio front end circuitry and / or antenna 111 may be considered an interface.

[0225] As shown, the interface 114 includes a radio front-end circuit 112 and an antenna 111. The radio front-end circuit 112 includes one or more filters 118 and an amplifier 116. The radio front-end circuit 114 is connected to the antenna 111 and the processing circuit 120, and is configured to condition the signal transmitted between the antenna 111 and the processing circuit 120. The radio front-end circuit 112 may be coupled to the antenna 111 or may be part of the antenna 111. In some alternative embodiments, the wireless device 110 may not include a separate radio front-end circuit 112; instead, the processing circuit 120 may include a radio front-end circuit and may be connected to the antenna 111. Similarly, in some embodiments, some or all of the RF transceiver circuit 122 may be considered to be part of the interface 114. The radio front-end circuit 112 may receive digital data, which will be sent out to other network nodes or wireless devices via a wireless connection. The radio front-end circuit 112 may convert the digital data into a radio signal having suitable channel and bandwidth parameters using a combination of filters 118 and / or amplifiers 116. The radio signal may then be sent via the antenna 111. Similarly, when receiving data, antenna 111 may collect radio signals, which may then be converted to digital data by radio front end circuit 112. The digital data may be passed to processing circuit 120. In other embodiments, the interface may include different components and / or different combinations of components.

[0226] The processing circuit 120 may include a combination of one or more of the following: a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic, which is operable to provide wireless device 110 functionality alone or in combination with other wireless device 110 components (e.g., device readable medium 130). Such functionality may include providing any of the various wireless features or benefits discussed herein. For example, the processing circuit 120 may execute instructions stored in the device readable medium 130 or in a memory within the processing circuit 120 to provide the functionality disclosed herein.

[0227] As shown, the processing circuit 120 includes one or more of the RF transceiver circuit 122, the baseband processing circuit 124, and the application processing circuit 126. In other embodiments, the processing circuit may include different components and / or different combinations of components. In some embodiments, the processing circuit 120 of the wireless device 110 may include a SOC. In some embodiments, the RF transceiver circuit 122, the baseband processing circuit 124, and the application processing circuit 126 may be on a separate chip or chipset. In an alternative embodiment, part or all of the baseband processing circuit 124 and the application processing circuit 126 may be combined into one chip or chipset, and the RF transceiver circuit 122 may be on a separate chip or chipset. In another alternative embodiment, part or all of the RF transceiver circuit 122 and the baseband processing circuit 124 may be on the same chip or chipset, and the application processing circuit 126 may be on a separate chip or chipset. In other alternative embodiments, part or all of the RF transceiver circuit 122, the baseband processing circuit 124, and the application processing circuit 126 may be combined in the same chip or chipset. In some embodiments, RF transceiver circuitry 122 may be part of interface 114. RF transceiver circuitry 122 may condition RF signals for processing circuitry 120.

[0228] In some embodiments, some or all of the functions described herein as being performed by the wireless device may be provided by a processing circuit 120 that executes instructions stored on a device-readable medium 130, which in some embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by the processing circuit 120, for example, in a hardwired manner, without executing instructions stored on a separate or discrete device-readable storage medium. In any of these particular embodiments, the processing circuit 120 may be configured to perform the described functions regardless of whether instructions stored on a device-readable storage medium are executed. The benefits provided by such functionality are not limited to the processing circuit 120 or to other components of the wireless device 110, but are enjoyed by the wireless device 110 as a whole and / or by the end user and the wireless network as a whole.

[0229] The processing circuit 120 may be configured to perform any determination, calculation, or similar operation (e.g., certain obtaining operations) described herein as being performed by the wireless device. Such operations performed by the processing circuit 120 may include processing information obtained by the processing circuit 120 by, for example, converting the obtained information to other information, comparing the obtained information or the converted information to information stored by the wireless device 110, and / or performing one or more operations based on the obtained information or the converted information and making a determination based on the results of the processing.

[0230] Device-readable medium 130 is operable to store computer programs, software, applications including one or more of logic, rules, codes, tables, etc., and / or other instructions executable by processing circuit 120. Device-readable medium 130 may include computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), mass storage media (e.g., hard disk), removable storage media (e.g., compact disk (CD) or digital video disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that may be used by processing circuit 120. In some embodiments, processing circuit 120 and device-readable medium 130 may be considered integrated.

[0231] The user interface device 132 may provide a component that allows a human user to interact with the wireless device 110. This interaction may be in a variety of forms, such as visual, auditory, tactile, etc. The user interface device 132 is operable to generate output to the user and allow the user to provide input to the wireless device 110. The type of interaction may vary depending on the type of user interface device 132 installed in the wireless device 110. For example, if the wireless device 110 is a smart phone, the interaction may be performed via a touch screen; if the wireless device 110 is a smart meter, the interaction may be performed through a screen that provides usage (e.g., the number of gallons used) or a speaker that provides an audible alarm (e.g., if smoke is detected). The user interface device 132 may include input interfaces, devices and circuits, and output interfaces, devices and circuits. The user interface device 132 is configured to allow information to be input into the wireless device 110, and is connected to the processing circuit 120 to allow the processing circuit 120 to process the input information. The user interface device 132 may include, for example, a microphone, proximity or other sensor, key / button, touch display, one or more cameras, USB port or other input circuit. The user interface device 132 is also configured to allow information to be output from the wireless device 110 and to allow the processing circuit 120 to output information from the wireless device 110. The user interface device 132 may include, for example, a speaker, a display, a vibration circuit, a USB port, a headphone jack, or other output circuitry. By using one or more input and output interfaces, devices, and circuits of the user interface device 132, the wireless device 110 may communicate with an end user and / or a wireless network and allow them to benefit from the functionality described herein.

[0232] The auxiliary device 134 is operable to provide more specific functions that may not be typically performed by a wireless device. This may include specialized sensors for taking measurements for various purposes, interfaces for other types of communications such as wired communications, etc. The inclusion and types of components of the auxiliary device 134 may vary depending on the embodiment and / or scenario.

[0233] In some embodiments, the power source 136 may be in the form of a battery or battery pack. Other types of power sources may also be used, such as an external power source (e.g., a power outlet), a photovoltaic device, or a battery cell. The wireless device 110 may also include a power circuit 137 for delivering power from the power source 136 to various parts of the wireless device 110, which require power from the power source 136 to perform any functions described or indicated herein. In some embodiments, the power circuit 137 may include a power management circuit. The power circuit 137 may additionally or alternatively be operable to receive power from an external power source; in this case, the wireless device 110 may be connected to the external power source (e.g., a power outlet) through an input circuit or an interface such as a power cable. In some embodiments, the power circuit 137 may also be operable to deliver power from the external power source to the power source 136. For example, this may be used for charging the power source 136. The power circuit 137 may perform any formatting, conversion, or other modification of the power from the power source 136 to make the power suitable for the various components of the wireless device 110 being powered.

[0234] Fig.11 One embodiment of a UE in accordance with various aspects described herein is shown. As used herein, a "user equipment" or "UE" may not necessarily have a "user" in the sense of a human user who owns and / or operates the associated device. Alternatively, a UE may represent a device that is intended to be sold to or operated by a human user but may not or may not initially be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended to be sold to or operated by an end user but may be associated with or operated for the benefit of a user (e.g., a smart meter). UE 200 may be any UE identified by the Third Generation Partnership Project (3GPP), including a NB-IoT UE, a Machine Type Communication (MTC) UE, and / or an enhanced MTC (eMTC) UE. As Fig.11 As shown, UE 200 is an example of a wireless device configured for communication according to one or more communication standards promulgated by the Third Generation Partnership Project (3GPP), such as 3GPP's GSM, UMTS, LTE and / or 5G standards. As previously mentioned, the terms wireless device and UE may be used interchangeably. Therefore, although Fig.11 It is a UE, but the components discussed in this article are also applicable to wireless devices and vice versa.

[0235] exist Fig.11In the embodiment, UE 200 includes a processing circuit 201, which is operably coupled to an input / output interface 205, a radio frequency (RF) interface 209, a network connection interface 211, a memory 215 including a random access memory (RAM) 217, a read-only memory (ROM) 219, and a storage medium 221, a communication subsystem 231, a power supply 233, and / or any other components, or any combination thereof. The storage medium 221 includes an operating system 223, an application 225, and data 227. In other embodiments, the storage medium 221 may include other similar types of information. Some UEs may use Fig.11 All components shown in the UE may be used, or only a subset of these components may be used. The level of integration between components may vary from one UE to another. In addition, some UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0236] exist Fig.11 In the embodiment of the present invention, the processing circuit 201 can be configured to process computer instructions and data. The processing circuit 201 can be configured to implement any sequential state machine that is operable to execute machine instructions stored as a machine-readable computer program in a memory, such as: one or more hardware-implemented state machines (e.g., implemented in discrete logic, FPGA, ASIC, etc.); programmable logic together with appropriate firmware; one or more stored programs, general-purpose processors (e.g., microprocessors or digital signal processors (DSPs)) together with suitable software; or any combination of the above. For example, the processing circuit 201 may include two central processing units (CPUs). The data may be information in a form suitable for use by a computer.

[0237] In the depicted embodiment, the input / output interface 205 may be configured to provide a communication interface to an input device, an output device, or an input and output device. The UE 200 may be configured to use an output device via the input / output interface 205. The output device may use the same type of interface port as the input device. For example, a USB port may be used to provide input to and output from the UE 200. The output device may be a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, a transmitter, a smart card, another output device, or any combination thereof. The UE 200 may be configured to use an input device via the input / output interface 205 to allow a user to capture information into the UE 200. The input device may include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a touchpad, a scroll wheel, a smart card, etc. 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, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, another similar sensor, or any combination thereof. For example, the input device can be an accelerometer, a magnetometer, a digital camera, a microphone, and an optical sensor.

[0238] exist Fig.11 In the embodiment of the present invention, the RF interface 209 can be configured to provide a communication interface to RF components such as transmitters, receivers, and antennas. The network connection interface 211 can be configured to provide a communication interface to the network 243a. The network 243a can include a wired and / or wireless network, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, the network 243a can include a Wi-Fi network. The network connection interface 211 can be configured to include a receiver and a transmitter interface, which is used to communicate with one or more other devices through a communication network according to one or more communication protocols (e.g., Ethernet, TCP / IP, SONET, ATM, etc.). The network connection interface 211 can implement receiver and transmitter functions suitable for communication network links (e.g., optical, electrical, etc.). The transmitter and receiver functions can share circuit components, software, or firmware, or alternatively can be implemented separately.

[0239] RAM 217 may be configured to interface with processing circuit 201 via bus 202 to provide storage or caching of data or computer instructions during execution of software programs such as operating systems, applications, and device drivers. ROM 219 may be configured to provide computer instructions or data to processing circuit 201. For example, ROM 219 may be configured to store unchanged low-level system code or data for basic system functions stored in non-volatile memory, such as basic input and output (I / O), booting, or receiving keystrokes from a keyboard. Storage medium 221 may be configured to include memory such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, floppy disk, hard disk, removable tape cartridge, or flash drive. In one example, storage medium 221 may be configured to include operating system 223, application 225 such as a web browser application, widget or gadget engine or another application, and data file 227. Storage medium 221 may store any one of a variety of operating systems or a combination of operating systems for use by UE 200 .

[0240] The storage medium 221 may be configured to include multiple physical drive units, such as a redundant array of independent disks (RAID), a floppy disk drive, a flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disk (HD-DVD) optical drive, a built-in hard drive, a Blu-ray optical drive, a holographic digital data storage (HDDS) optical drive, an external mini dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external micro DIMM SDRAM, a smart card memory such as a user identity module or a removable user identity (SIM / RUIM) module, other memories or any combination thereof. The storage medium 221 may allow the UE 200 to access computer executable instructions, applications, etc. stored on a temporary or non-temporary storage medium to unload data or upload data. Articles such as articles utilizing a communication system may be tangibly embodied in the storage medium 221, which may include a device-readable medium.

[0241] exist Fig.11In the embodiment of the present invention, the processing circuit 201 can be configured to communicate with the network 243b using the communication subsystem 231. The network 243a and the network 243b can be one or more identical networks or one or more different networks. The communication subsystem 231 can be configured to include one or more transceivers for communicating with the network 243b. For example, the communication subsystem 231 can be configured to include one or more transceivers for communicating with another device (e.g., another wireless device, UE) capable of wireless communication or one or more remote transceivers of a base station of a radio access network (RAN) according to one or more communication protocols (e.g., IEEE 802.2, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax, etc.). Each transceiver can include a transmitter 233 and / or a receiver 235 to respectively implement a transmitter or receiver function (e.g., frequency allocation, etc.) suitable for a RAN link. In addition, the transmitter 233 and the receiver 235 of each transceiver can share circuit components, software or firmware, or can be implemented separately instead.

[0242] In the illustrated embodiment, the communication functions of the communication subsystem 231 may include data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication (such as use of a global positioning system (GPS) for determining location), another similar communication function, or any combination thereof. For example, the communication subsystem 231 may include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. The network 243b may include a wired and / or wireless network, such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a telecommunications network, another similar network, or any combination thereof. For example, the network 243b may be a cellular network, a Wi-Fi network, and / or a near-field network. The power supply 213 may be configured to provide alternating current (AC) or direct current (DC) power to the components of the UE 200.

[0243] The features, benefits and / or functions described herein may be implemented in one of the components of UE 200, or divided between multiple components of UE 200. In addition, the features, benefits and / or functions described herein may be implemented in any combination of hardware, software or firmware. In one example, the communication subsystem 231 may be configured to include any component described herein. In addition, the processing circuit 201 may be configured to communicate with any such component via bus 202. In another example, any such component may be represented by a program instruction stored in a memory, and when executed by the processing circuit 201, the program instruction performs the corresponding function described herein. In another example, the function of any such component may be divided between the processing circuit 201 and the communication subsystem 231. In another example, the non-computationally intensive functions of any such component may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.

[0244] Fig.12 is a schematic block diagram illustrating a virtualized environment 300 in which functionality implemented by some embodiments may be virtualized. In this context, virtualization means creating a virtual version of an apparatus or device, which may include virtualized hardware platforms, storage devices, and network resources. As used herein, virtualization may be applied to a node (e.g., a virtualized base station or a virtualized radio access node) or a device (e.g., a UE, a wireless device, or any other type of communication device) or a component thereof, and relates to an implementation in which at least a portion of functionality is implemented as one or more virtual components (e.g., by one or more applications, components, functions, virtual machines, or containers executed on one or more physical processing nodes in one or more networks).

[0245] In some embodiments, some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments 300 hosted by one or more hardware nodes 330. Furthermore, in embodiments where the virtual nodes are not radio access nodes or do not require radio connectivity (e.g., core network nodes), the network nodes may be fully virtualized at this point.

[0246] These functions may be implemented by one or more applications 320 (which may alternatively be referred to as software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.), which are operable to implement some features, functions, and / or benefits of some embodiments disclosed herein. The applications 320 run in a virtualized environment 300, which provides hardware 330 including processing circuitry 360 and memory 390. The memory 390 contains instructions 395 executable by the processing circuitry 360, whereby the applications 320 are operable to provide one or more features, benefits, and / or functions disclosed herein.

[0247] The virtualization environment 300 includes a general or special purpose network hardware device 330, which includes a set of one or more processors or processing circuits 360, which may be commercial off-the-shelf (COTS) processors, application-specific integrated circuits (ASICs), or any other type of processing circuit including digital or analog hardware components or special purpose processors. Each hardware device may include a memory 390-1, which may be a non-persistent memory for temporarily storing instructions 395 or software executed by the processing circuit 360. Each hardware device may include one or more network interface controllers (NICs) 370, also known as network interface cards, which include physical network interfaces 380. Each hardware device may also include a non-transitory, permanent machine-readable storage medium 390-2 in which software 395 and / or instructions executable by the processing circuit 360 are stored. The software 395 may include any type of software, including software for instantiating one or more virtualization layers 350 (also known as hypervisors), software for executing virtual machines 340, and software that allows them to perform the functions, features, and / or benefits described in connection with some embodiments described herein.

[0248] The virtual machines 340 include virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be run by a corresponding virtualization layer 350 or hypervisor. Different embodiments of instances of the virtual devices 320 may be implemented on one or more of the virtual machines 340, and the implementation may be done in different ways.

[0249] During operation, processing circuitry 360 executes software 395 to instantiate a hypervisor or virtualization layer 350, which may sometimes be referred to as a virtual machine monitor (VMM). Virtualization layer 350 may present a virtual operating platform that appears to virtual machine 340 as networked hardware.

[0250] like Fig.12 As shown, hardware 330 can be an independent network node with common or specific components. Hardware 330 can include antenna 3225 and some functions can be implemented through virtualization. Alternatively, hardware 330 can be part of a larger hardware cluster (e.g., in a data center or customer premises equipment (CPE)), where many hardware nodes work together and are managed by management and coordination (MANO) 3100, which oversees the life cycle management of application 320, etc.

[0251] In some contexts, virtualization of hardware is referred to as network function virtualization (NFV). NFV can be used to unify numerous network equipment types onto industry-standard high-capacity server hardware, physical switches, and physical storage that can be located in data centers and customer premises equipment.

[0252] In the context of NFV, a virtual machine 340 may be a software implementation of a physical machine that runs programs as if they were executed on a physical, non-virtualized machine. Each virtual machine 340 and the portion of hardware 330 that executes the virtual machine (which may be hardware dedicated to the virtual machine and / or hardware shared by the virtual machine and other virtual machines in virtual machines 340) form a separate virtual network element (VNE).

[0253] Still in the context of NFV, a virtual network function (VNF) is responsible for handling specific network functions running in one or more virtual machines 340 on top of the hardware network infrastructure 330 and corresponds to Fig.16 Application 320.

[0254] In some embodiments, one or more radio units 3200, each including one or more transmitters 3220 and one or more receivers 3210, may be coupled to one or more antennas 3225. The radio units 3200 may communicate directly with the hardware nodes 330 via one or more suitable network interfaces, and may be used in conjunction with virtual components to provide a virtual node with radio capabilities, such as a radio access node or base station.

[0255] In some embodiments, some signaling may be implemented using a control system 3230 , which may alternatively be used for communications between the hardware node 330 and the radio unit 3200 .

[0256] Fig.13 A method 400 performed by a network node in accordance with certain embodiment embodiments is depicted. The method begins at step 402 where one or more SCTP / IP packets are sent to another network node over an LTE radio.

[0257] In some embodiments, the one or more SCTP / IP packets may include one or more complete SCTP / IP packets. In some embodiments, the one or more SCTP / IP packets may include IAB control plane signaling. In some embodiments, the one or more SCTP / IP packets may include F1-AP signaling.

[0258] In some embodiments, sending the one or more SCTP / IP packets may be performed in the absence of an NR link.

[0259] In some embodiments, the network node may be one of the NR donor gNB and the IAB node. In some embodiments, the other network node may be one of the NR donor gNB and the IAB node.

[0260] In some embodiments, the method may further include obtaining an IP address allocated for use when communicating via LTE. In some embodiments, the IP address may be obtained using NAS signaling.

[0261] In some embodiments, the IP address may be allocated by an OAM system. In some embodiments, obtaining the IP address may include: sending a message to the OAM system; and receiving configuration information indicating the allocated IP address in response to the message. In some embodiments, the IP address may be allocated using an IETF specified method including one or more of DHCP and IPv6 host discovery. In some embodiments, the IP address may be obtained in an RRC message from an LTE eNB. In some embodiments, obtaining the IP address may include: implicitly assigning the IP address using an IP address received in a DL packet. In some embodiments, the one or more SCTP / IP packets may include the allocated IP address.

[0262] In some embodiments, the method may include setting up an SCTP connection to another network node. In some embodiments, setting up the SCTP connection to another network node may be performed in response to an indication from another network node that an auxiliary SCTP connection is needed. In some embodiments, setting up the SCTP connection to another network node may be performed in response to a radio link failure.

[0263] In some embodiments, the method may include sending capability information to one or more of the other node and the LTE node.In some embodiments, the method may include receiving capability information from one or more of the other node and the LTE node.

[0264] In some embodiments, the method may include encrypting one or more SCTP / IP packets. In some embodiments, the one or more SCTP / IP packets may be encrypted using IPsec.

[0265] In some embodiments, the one or more SCTP / IP packets may be sent via X2-AP and RRC signaling. In some embodiments, the one or more SCTP / IP packets may be embedded in an X2 / RRC signaling message. In some embodiments, the method may include: generating an F1-AP message; placing the F1-AP message in an SCTP packet; placing the SCTP packet in an IP PDU; placing the IP PDU in an RRC message; and sending the RRC message to the LTE node. In some embodiments, the RRC message may be an UL transfer message.

[0266] In some embodiments, the one or more SCTP / IP packets may be sent via a separate PDN connection with the core network.In some embodiments, the method may include establishing a separate PDN connection with the core network using one or more NAS protocols.

[0267] In some embodiments, the one or more SCTP / IP packets may be sent via one of an RLC bearer and a radio bearer in the LTE eNB. In some embodiments, the one or more SCTP / IP packets may be sent via a GTP tunnel associated with one of the RLC bearer and the radio bearer.

[0268] In certain embodiments, the method may include: obtaining user data; and forwarding the user data to a host computer or a wireless device.

[0269] Fig.14 A wireless network (e.g., Figure 8 Schematic block diagram of a device 500 in a wireless network (shown in FIG. 1 ). The device may be in a network node (e.g., Fig. 9 The apparatus 500 is operable to perform the reference Fig.13 The example methods described herein and possibly any other processes or methods disclosed herein. It should also be understood that Fig.13 The method is not necessarily performed by the apparatus 500 alone. At least some operations of the method may be performed by one or more other entities.

[0270] The virtual device 500 may include a processing circuit, which may include one or more microprocessors or microcontrollers and other digital hardware (which may include a digital signal processor (DSP), dedicated digital logic, etc.). The processing circuit may be configured to execute program code stored in a memory, which may include one or more types of memory, such as a read-only memory (ROM), a random access memory, a cache memory, a flash memory device, an optical storage device, etc. In several embodiments, the program code stored in the memory includes program instructions for executing one or more telecommunications and / or data communication protocols, and instructions for executing one or more techniques described herein. In some implementations, the processing circuit may be used to cause the receiving unit 502, the determining unit 504, and the communication unit 506, as well as any other suitable units of the device 500, to perform corresponding functions according to one or more embodiments of the present disclosure.

[0271] In some embodiments, the apparatus 500 may be an IAB node or a donor gNB. Fig.14As shown, the apparatus 500 includes a receiving unit 502, a determining unit 504, and a communicating unit 506. The receiving unit 502 may be configured to perform a receiving function of the apparatus 500. For example, the receiving unit 502 may be configured to obtain an IP address allocated for use when communicating via LTE. In some embodiments, the receiving unit 502 may be configured to receive configuration information indicating the allocated IP address in response to the message.

[0272] As another example, the receiving unit 502 may be configured to receive capability information from one or more of another network node and the LTE node.As yet another example, the receiving unit 502 may be configured to obtain user data.

[0273] The receiving unit 502 may receive any suitable information (eg, from a wireless device or another network node). The receiving unit 502 may include a receiver and / or a transceiver, such as described above with respect to Fig. 9 The receiving unit 502 may include a circuit configured to receive messages and / or signals (wirelessly or wired). In certain embodiments, the receiving unit 502 may transmit the received messages and / or signals to the determining unit 504 or any other suitable unit of the device 500. In some embodiments, the functions of the receiving unit 502 may be performed in one or more different units.

[0274] The determining unit 504 may perform the processing functions of the apparatus 500. For example, the determining unit 504 may be configured to obtain an IP address allocated for use when communicating via LTE. In some embodiments, the determining unit 504 may be configured to implicitly assign an IP address using an IP address received in a DL packet.

[0275] As another example, the determining unit 504 may be configured to set up an SCTP connection to another network node. In some embodiments, the determining unit 504 may be configured to set up an SCTP connection to another network node in response to an indication from another network node that an auxiliary SCTP connection is needed. In some embodiments, the determining unit 504 may be configured to set up an SCTP connection to another network node in response to a radio link failure.

[0276] As another example, the determining unit 504 may be configured to encrypt one or more of the one or more SCTP / IP packets. In some embodiments, the determining unit 504 may be configured to encrypt one or more of the SCTP / IP packets using IPsec.

[0277] As another example, the determining unit 504 may be configured to: generate an F1-AP message; place the F1-AP message into an SCTP packet; place the SCTP packet into an IP PDU; and place the IP PDU into an RRC message.

[0278] As yet another example, the determining unit 504 may be configured to establish a separate PDN connection with the core network using one or more NAS protocols.

[0279] As yet another example, the determining unit 504 may be configured to obtain user data.

[0280] The determination unit 504 may include one or more processors (eg, Fig. 9 The processing circuit 170 described above) may be included in one or more processors (such as the processing circuit 170 described above). Fig. 9 The determining unit 504 may include analog and / or digital circuits configured to perform any of the functions of the determining unit 504 and / or the processing circuit 170 described above. In some embodiments, the functions of the determining unit 504 may be performed in one or more different modules.

[0281] The communication unit 506 may be configured to perform the transmission functions of the device 500. For example, the communication unit 506 may be configured to send one or more SCTP / IP packets to another network node via an LTE radio. In some embodiments, the one or more SCTP / IP packets may include one or more complete SCTP / IP packets. In some embodiments, the one or more SCTP / IP packets may include IAB control plane signaling. In some embodiments, the one or more SCTP / IP packets may include F1-AP signaling. In some embodiments, the communication unit 506 may be configured to send the one or more SCTP / IP packets in the absence of an NR link.

[0282] As another example, the communication unit 506 may be configured to send a message to an OAM system (eg, requesting an IP address for use when communicating via LTE).As yet another example, the communication unit 506 may be configured to send capability information to one or more of another network node and an LTE node.

[0283] As another example, the communication unit 506 may be configured to send the one or more SCTP / IP packets via X2-AP and RRC signaling. In some embodiments, the one or more SCTP / IP packets may be embedded in an X2 / RRC signaling message. In some embodiments, the communication unit 506 may be configured to send an RRC message (e.g., an UL transmit message) to the LTE node.

[0284] As another example, the communication unit 506 may be configured to send the one or more SCTP / IP packets via a separate PDN connection with the core network.

[0285] As another example, the communication unit 506 may be configured to send the one or more SCTP / IP packets via one of an RLC bearer and a radio bearer in the LTE eNB. In some embodiments, the communication unit 506 may be configured to send the one or more SCTP / IP packets via a GTP tunnel associated with one of the RLC bearer and the radio bearer.

[0286] As another example, communication unit 506 may be configured to forward user data to a host computer or wireless device.

[0287] The communication unit 506 can send messages (eg, to a wireless device and / or another network node). The communication unit 506 can include a transmitter and / or a transceiver, such as described above with respect to Fig. 9 RF transceiver circuit 172 described above. Communication unit 506 may include circuits configured to send messages and / or signals (e.g., wirelessly or by wire). In certain embodiments, communication unit 506 may receive messages and / or signals for transmission from determination unit 504 or any other unit of device 500. In some embodiments, the functions of communication unit 504 may be performed in one or more different units.

[0288] The term unit may have a conventional meaning in the field of electronic products, electrical devices and / or electronic devices, and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logical solid-state and / or discrete devices, computer programs or instructions for performing various tasks, processes, calculations, output and / or display functions, etc. (such as those described herein).

[0289] Fig.15 Another method 600 performed by a network node 160 in an IAB network according to some embodiments is depicted. The method begins at step 602, where the first network node 160 in the IAB network sends one or more SCTP / IP packets to a second network node over an LTE radio in the absence of an NR link between the first network node 160 and the second network. The one or more SCTP / IP packets include F1-AP signaling.

[0290] In particular embodiments, the one or more SCTP / IP packets include one or more complete SCTP / IP packets.

[0291] In a particular embodiment, the one or more SCTP / IP packets include IAB control plane signaling.

[0292] In a particular embodiment, the network node 160 is one of a NR donor gNodeB (gNB) and an IAB node.

[0293] In a particular embodiment, the second network node is one of a NR donor gNB and an IAB node.

[0294] In a particular embodiment, the first network node 160 obtains an IP address allocated for use when communicating via LTE. In another particular embodiment, the IP address is obtained using NAS signaling. In a particular embodiment, the IP address is allocated by an OAM system.

[0295] In another particular embodiment, the IP address may be obtained by: sending a message to the OAM system; and receiving configuration information indicating the allocated IP address in response to the message.

[0296] In another particular embodiment, the IP address is assigned using DHCP and / or IPv6 host discovery.

[0297] In another specific embodiment, the IP address is obtained in an RRC message from the LTE eNB.

[0298] In particular embodiments, obtaining the IP address may include implicitly assigning the IP address using an IP address received in a downlink (DL) packet.

[0299] In particular embodiments, the one or more SCTP / IP packets include the assigned IP address.

[0300] In a specific embodiment, the first network node 160 sets up an SCTP connection to the second network node. In another specific embodiment, setting up the SCTP connection to the second network node is performed in response to an indication from the second network node that an auxiliary SCTP connection is needed. In another specific embodiment, setting up the SCTP connection to the second network node is performed in response to a radio link failure.

[0301] In certain embodiments, the first network node 160 sends capability information to one or more of the second node and the LTE node.

[0302] In certain embodiments, the first network node 160 receives capability information from one or more of the second node and the LTE node.

[0303] In certain embodiments, first network node 160 encrypts the one or more SCTP / IP packets.

[0304] In particular embodiments, the one or more SCTP / IP packets are encrypted using IPsec.

[0305] In a specific embodiment, the one or more SCTP / IP packets are sent via X2-application protocol X2-AP and RRC signaling. In another specific embodiment, the one or more SCTP / IP packets are embedded in an X2 / RRC signaling message. In a specific embodiment, the first network node 160 may: generate an F1-AP message; put the F1-AP message in an SCTP packet; put the SCTP packet in an IP protocol data unit IP PDU; put the IP PDU in an RRC message; and send the RRC message to the LTE node.

[0306] In a particular embodiment, the RRC message is a UL Transmit message.

[0307] In a particular embodiment, the one or more SCTP / IP packets are sent via a separate packet data network, PDN, connection with the core network.In another particular embodiment, the first network node 160 may establish a separate PDN connection with the core network using one or more NAS protocols.

[0308] In a specific embodiment, one or more SCTP / IP packets are sent via one of a radio link control bearer RLC bearer and a radio bearer in an LTE eNB. In another specific embodiment, the one or more SCTP / IP packets are sent via a GTP tunnel associated with one of the RLC bearer and the radio bearer.

[0309] Fig.16 A wireless network (e.g., Figure 8 Schematic block diagram of a device 700 in a wireless network (shown in FIG. 1 ). The device may be in a network node (e.g., Fig. 9 The apparatus 700 is operable to perform the reference Fig.15 The example methods described herein and possibly any other processes or methods disclosed herein. It should also be understood that Fig.15 The method is not necessarily performed by the apparatus 700 alone. At least some operations of the method may be performed by one or more other entities.

[0310] The virtual device 700 may include a processing circuit, which may include one or more microprocessors or microcontrollers and other digital hardware (which may include a digital signal processor (DSP), dedicated digital logic, etc.). The processing circuit may be configured to execute program code stored in a memory, which may include one or more types of memory, such as a read-only memory (ROM), a random access memory, a cache memory, a flash memory device, an optical storage device, etc. In several embodiments, the program code stored in the memory includes program instructions for executing one or more telecommunications and / or data communication protocols, and instructions for executing one or more techniques described herein. In some implementations, the processing circuit may be used to cause the receiving unit 702, the determining unit 704, and the communication unit 706, as well as any other suitable units of the device 700, to perform corresponding functions according to one or more embodiments of the present disclosure.

[0311] In some embodiments, the apparatus 70 may be an IAB node or a donor gNB. Fig.16 As shown, the apparatus 700 includes a receiving unit 702, a determining unit 704, and a communicating unit 706. The receiving unit 702 may be configured to perform the receiving function of the apparatus 700. For example, the receiving unit 702 may be configured to obtain an IP address allocated for use when communicating via LTE. In another specific embodiment, the receiving unit 702 may be configured to obtain the IP address using NAS signaling. In a specific embodiment, the IP address is allocated by an OAM system, and the receiving unit 702 may be configured to obtain the IP address from the OAM system. For example, the receiving unit 702 may be configured to receive configuration information indicating the allocated IP address from the OAM system.

[0312] In another particular embodiment, the IP address may be obtained by: sending a message to the OAM system; and receiving configuration information indicating the allocated IP address in response to the message.

[0313] In another specific embodiment, the IP address is assigned by DHCP and / or IPv6 host discovery.

[0314] In another specific embodiment, the IP address is obtained in an RRC message from the LTE eNB.

[0315] In particular embodiments, obtaining the IP address may include implicitly assigning the IP address using an IP address received in a downlink (DL) packet.

[0316] In particular embodiments, the one or more SCTP / IP packets include the assigned IP address.

[0317] As another example, the receiving unit 702 may be configured to receive capability information from one or more of another network node and the LTE node.As yet another example, the receiving unit 702 may be configured to obtain user data.

[0318] The receiving unit 702 may receive any suitable information (eg, from a wireless device or another network node). The receiving unit 702 may include a receiver and / or a transceiver, such as described above with respect to Fig. 9 The receiving unit 702 may include a circuit configured to receive messages and / or signals (wirelessly or wired). In certain embodiments, the receiving unit 702 may transmit the received messages and / or signals to the determining unit 704 or any other suitable unit of the device 700. In some embodiments, the functions of the receiving unit 702 may be performed in one or more different units.

[0319] The determining unit 704 may perform the processing functions of the apparatus 700. For example, the determining unit 704 may be configured to obtain an IP address allocated for use when communicating via LTE. In some embodiments, the determining unit 504 may be configured to implicitly assign an IP address using an IP address received in a DL packet.

[0320] As another example, the determining unit 704 may be configured to set up an SCTP connection to another network node. In some embodiments, the determining unit 704 may be configured to set up an SCTP connection to another network node in response to an indication from another network node that an auxiliary SCTP connection is needed. In some embodiments, the determining unit 704 may be configured to set up an SCTP connection to another network node in response to a radio link failure.

[0321] As another example, the determining unit 704 may be configured to encrypt one or more of the one or more SCTP / IP packets.In some embodiments, the determining unit 504 may be configured to encrypt one or more SCTP / IP packets using IPsec.

[0322] As another example, the determining unit 704 may be configured to: generate an F1-AP message; place the F1-AP message into an SCTP packet; place the SCTP packet into an IP PDU; and place the IP PDU into an RRC message.

[0323] As yet another example, the determining unit 704 may be configured to establish a separate PDN connection with the core network using one or more NAS protocols.

[0324] As yet another example, the determining unit 704 may be configured to obtain user data.

[0325] The determination unit 704 may include one or more processors (eg, Fig. 9 The processing circuit 170 described above) may be included in one or more processors (such as the processing circuit 170 described above). Fig. 9 The determining unit 704 may include analog and / or digital circuits configured to perform any of the functions of the determining unit 704 and / or the processing circuit 170 described above. In some embodiments, the functions of the determining unit 704 may be performed in one or more different modules.

[0326] The communication unit 706 may be configured to perform the transmission function of the device 700. For example, in the absence of an NR link between the first network node 160 and the second network in the IAB network, the communication unit 706 may be configured to send one or more SCTP / IP packets to the second network node via the LTE radio. The one or more SCTP / IP packets include F1-AP signaling. In a specific embodiment, the one or more SCTP / IP packets include one or more complete SCTP / IP packets. In a specific embodiment, the one or more SCTP / IP packets include IAB control plane signaling. In a specific embodiment, the first network node 160 is one of an NR donor gNodeB (gNB) and an IAB node. In a specific embodiment, the second network node is one of an NR donor gNB and an IAB node.

[0327] As another example, the communication unit 706 may be configured to send a message to an OAM system (eg, requesting an IP address for use when communicating via LTE).As yet another example, the communication unit 706 may be configured to send capability information to one or more of another network node and an LTE node.

[0328] As another example, the communication unit 706 may be configured to send one or more SCTP / IP packets via X2-AP and RRC signaling. In some embodiments, the one or more SCTP / IP packets may be embedded in an X2 / RRC signaling message. In some embodiments, the communication unit 706 may be configured to send an RRC message (e.g., an UL transmit message) to an LTE node.

[0329] As another example, the communication unit 706 may be configured to send the one or more SCTP / IP packets via a separate PDN connection with the core network.

[0330] As another example, the communication unit 706 may be configured to send the one or more SCTP / IP packets via one of an RLC bearer and a radio bearer in the LTE eNB. In some embodiments, the communication unit 706 may be configured to send the one or more SCTP / IP packets via a GTP tunnel associated with one of the RLC bearer and the radio bearer.

[0331] As another example, communication unit 706 may be configured to forward user data to a host computer or wireless device.

[0332] The communication unit 706 can send messages (eg, to a wireless device and / or another network node). The communication unit 706 can include a transmitter and / or a transceiver, such as described above with respect to Fig. 9 RF transceiver circuit 172 described above. Communication unit 706 may include circuits configured to send messages and / or signals (e.g., wirelessly or by wire). In certain embodiments, communication unit 706 may receive messages and / or signals for transmission from determination unit 704 or any other unit of device 700. In some embodiments, the functions of communication unit 504 may be performed in one or more different units.

[0333] The term unit may have a conventional meaning in the field of electronic products, electrical devices and / or electronic devices, and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logical solid-state and / or discrete devices, computer programs or instructions for performing various tasks, processes, calculations, output and / or display functions, etc. (such as those described herein).

[0334] Without departing from the scope of the present disclosure, the systems and devices described herein may be modified, added, or omitted. The components of the systems and devices may be integrated and separated. In addition, the operations of the systems and devices may be performed by more components, fewer components, or other components. In addition, any suitable logic including software, hardware, and / or other logic may be used to perform the operations of the systems and devices.

[0335] Without departing from the scope of the present disclosure, the methods described herein may be modified, added, or omitted. The methods may include more, fewer, or other steps. In addition, the steps may be performed in any suitable order.

[0336] Although the present disclosure has been described with reference to specific embodiments, the changes and arrangements of the embodiments will be apparent to those skilled in the art. Therefore, the above description does not limit the present disclosure. Other changes, substitutions and variations may be made without departing from the spirit and scope of the present disclosure.

[0337] Additional Information

[0338] At the RAN2#106 meeting, several contributions discussed the topic of supporting IAB-related signaling via the LTE MCG leg for NSA deployments [1-4]. In general, the following IAB-related signaling can be considered:

[0339] - IAB-MT's own RRC signalling (e.g. for BH RLC channel management),

[0340] -IAB-MT's own PDN connection (e.g. for OAM signalling),

[0341] -F1-AP connection of IAB-DU.

[0342] In addition to this, the IAB node will also support F1-U data, but it has been agreed that only the NR leg should be used.

[0343] This disclosure analyzes the feasibility / usefulness of supporting different signaling on LTE MCG branches.

[0344] IAB-MT's own RRC signaling

[0345] All IAB related RRC signaling (e.g. BH RLC channel setup / modification / release) can be carried as part of the NR cell group configuration, so supporting MT’s own RRC signaling on LTE is trivial since the NR SCG configuration is already transparently carried over the LTE SRBs for EN-DC.

[0346] Therefore, it is proposed that the existing mechanism used to handle signaling related to other NR RRC cell groups should be reused to support IAB-MT related RRC signaling via the LTE branches (SRB1 / 2).

[0347] IAB-MT's own PDN connection

[0348] Given that EN-DC already supports setting up PDN connections / EPS bearers etc. on both MCG and SCG branches, it should be possible to support OAM signaling via the LTE branch if required.

[0349] Therefore, it is recommended that the MT PDN connection of the IAB node should be configurable as regular user plane data in EN-DC on any branch MCG / SCG, thereby enabling OAM signaling via LTE for NSA IAB node deployment.

[0350] F1-AP connection for IAB-DU

[0351] Supporting F1-AP signaling on the LTE leg is technically more challenging and will likely have an impact on LTE specifications and implementations.

[0352] The F1-AP / SCTP connection between the donor CU and the IAB node is delivered as any other IP traffic via the DU function of the IAB donor node and through the BH RLC channel. Currently, there is no existing LTE mechanism available to deliver IP traffic to the IAB node in this way.

[0353] First observe that the F1-AP / SCTP connection is delivered to the IAB node via the DU function of the IAB donor node and over the BH RLC channel as any other IP traffic. Currently, there is no existing LTE mechanism available to deliver IP traffic to the IAB node over the LTE radio in this way.

[0354] Delivering F1-AP messages only via LTE RRC as proposed in R2-1907377, “Delivery of control plane signaling to IAB nodes in NSAdeployment”, AT&T, is not so straightforward because functions such as addressing, reliability, etc. currently provided by the SCTP and IP layers still need to be handled somehow.

[0355] It is also observed that delivering F1-AP messages via LTE RRC is not straightforward, as F1-C relies on functionality currently provided by the SCTP and IP layers. In theory, F1-AP / SCTP / IP could be delivered by the IAB setting up a PDN connection to the EPC for this purpose, but in our opinion this is also a rather complex solution that complicates IAB node operation / configuration.

[0356] It is also observed that passing F1-AP / SCTP / IP to the EPC via the PDN connection is possible but adds complexity to the system involving the LTE / NR RAN and EPC. Given the complexity mentioned above, it may be sufficient to restrict the IAB node signaling in Rel-16 to only the RRC and PDN connections of the MT, as these are likely to be the most critical types of signaling that need to be supported via LTE, such as setting up / reconfiguring NR legs. Once the NR leg is up and running, it is sufficient to perform F1 signaling only via the SCG leg.

[0357] Therefore, it is suggested that in view of the perceived complexity of supporting F1-AP via the LTE MCG leg in NSA deployments, it is sufficient to restrict the IAB node signaling via LTE in Rel-16 to only the RRC and PDN connections of the MT and support F1-C (similar to F1-U) only via the NR SCG leg.

[0358] In summary, as stated above, the following observations are made:

[0359] Observe the 1F1-AP / SCTP connection as any other IP traffic via the DU function of the IAB donor node and delivered to the IAB node over the BHRLC channel. Currently, there are no existing LTE mechanisms available to deliver IP traffic to the IAB node over the LTE radio in this manner.

[0360] Observation 2 Delivery of F1-AP messages via LTE RRC is not straightforward, since F1-C relies on functionality currently provided by the SCTP and IP layers.

[0361] Observation 3: Delivery of F1-AP / SCTP / IP to EPC via PDN connection is possible but will increase the system complexity involving LTE / NR RAN and EPC.

[0362] Based on the discussion in the previous sections, the following recommendations are made:

[0363] Recommendation 1: Existing mechanisms used to handle other NR RRC cell group related signaling should be reused to support IAB-MT related RRC signaling via LTE branches (SRB1 / 2).

[0364] Recommendation 2 The MT PDN connection of the IAB node should be configurable as regular user plane data in EN-DC on any tributary MCG / SCG, thereby enabling OAM signaling via LTE for NSA IAB node deployment.

[0365] Recommendation 3 Given the perceived complexity of supporting F1-AP via the LTE MCG leg in NSA deployments, it may be sufficient to restrict IAB node signaling via LTE in Rel-16 to only the RRC and PDN connections of the MT and support F1-C (similar to F1-U) only via the NR SCG leg.

Claims

1. A method performed by a first network node in an integrated access and wireless access backhaul (IAB) network, the method comprising: In the absence of a New Radio (NR) link between the first network node and the second network node in the IAB network, sending one or more Stream Control Transmission Protocol / Internet Protocol (SCTP / IP) packets to the second network node over a Long Term Evolution (LTE) radio, wherein the one or more SCTP / IP packets include F1-Application Protocol (F1-AP) signaling, The first network node is the NR donor gNodeB, i.e., one of the NR donor gNB and the IAB node, and the second network node is the other of the NR donor gNB and the IAB node.

2. The method according to claim 1, wherein: The one or more SCTP / IP packets include one or more complete SCTP / IP packets.

3. The method according to any one of claims 1 to 2, wherein: The one or more SCTP / IP packets include IAB control plane signaling.

4. The method according to any one of claims 1 to 2, further comprising: Obtain an Internet Protocol (IP) address assigned for use when communicating via LTE.

5. The method according to claim 4, wherein: The IP address is obtained using non-access stratum NAS signaling.

6. The method according to claim 4, wherein: The IP address is allocated by the operation administration and maintenance OAM system.

7. The method according to claim 6, wherein: Obtaining the IP address includes: sending a message to the OAM system; and In response to the message, configuration information indicative of the assigned IP address is received.

8. The method according to claim 4, wherein: The IP address is assigned using Dynamic Host Configuration Protocol DHCP and / or IPv6 Host Discovery.

9. The method according to claim 4, wherein: The IP address is obtained in a radio resource control RRC message from an LTE eNodeB, ie, LTE eNB.

10. The method according to claim 4, wherein: Obtaining the IP address includes: The IP address is implicitly assigned using the IP address received in the downlink DL packet.

11. The method according to claim 4, wherein: The one or more SCTP / IP packets include the assigned IP address.

12. The method according to any one of claims 1 to 2 and 5 to 11, further comprising: An SCTP connection is set up to the second network node.

13. The method according to claim 12, wherein: Setting up the SCTP connection to the second network node is performed in response to an indication from the second network node that an auxiliary SCTP connection is required.

14. The method according to claim 12, wherein: Setting up the SCTP connection to the second network node is performed in response to a radio link failure.

15. The method according to any one of claims 1 to 2, 5 to 11 and 13 to 14, further comprising: The capability information is sent to one or more of the second network node and the LTE node.

16. The method according to any one of claims 1 to 2, 5 to 11 and 13 to 14, further comprising: Capability information is received from one or more of the second network node and the LTE node.

17. The method according to any one of claims 1 to 2, 5 to 11 and 13 to 14, further comprising: The one or more SCTP / IP packets are encrypted.

18. The method according to any one of claims 1 to 2, 5 to 11 and 13 to 14, wherein The one or more SCTP / IP packets are encrypted using IPsec.

19. The method according to any one of claims 1 to 2, 5 to 11 and 13 to 14, wherein The one or more SCTP / IP packets are sent via X2-Application Protocol X2-AP and RRC signaling.

20. The method according to claim 19, wherein: The one or more SCTP / IP packets are embedded in an X2 / RRC signaling message.

21. The method according to claim 19, comprising: Generate F1-AP message; Put the F1-AP message into an SCTP packet; Put the SCTP packet into an IP protocol data unit IP PDU; Put the IP PDU into an RRC message; as well as The RRC message is sent to the LTE node.

22. The method according to claim 21, wherein: The RRC message is an uplink UL transmission message.

23. The method according to any one of claims 1 to 2, 5 to 11 and 13 to 14, wherein The one or more SCTP / IP packets are sent via a separate packet data network, PDN, connection to the core network.

24. The method according to claim 23, comprising: Individual PDN connections to the core network are established using one or more NAS protocols.

25. The method according to any one of claims 1 to 2, 5 to 11 and 13 to 14, wherein The one or more SCTP / IP packets are sent via one of a radio link control bearer (RLC bearer) and a radio bearer in the LTE eNB.

26. The method according to claim 25, wherein: The one or more SCTP / IP packets are sent via a General Packet Radio Service Tunneling Protocol (GTP) tunnel associated with one of the RLC bearer and the radio bearer.

27. A first network node in an integrated access and wireless access backhaul (IAB) network, the first network node comprising: processing circuitry, and A memory storing instructions, which, when executed by the processing circuit, cause the first network node to: In the absence of a New Radio (NR) link between the first network node and the second network node in the IAB network, sending one or more Stream Control Transmission Protocol / Internet Protocol (SCTP / IP) packets to the second network node over a Long Term Evolution (LTE) radio, wherein the one or more SCTP / IP packets include F1-Application Protocol (F1-AP) signaling, The first network node is the NR donor gNodeB, i.e., one of the NR donor gNB and the IAB node, and the second network node is the other of the NR donor gNB and the IAB node.

28. The first network node according to claim 27, wherein: The one or more SCTP / IP packets include one or more complete SCTP / IP packets.

29. The first network node according to any one of claims 27 to 28, wherein: The one or more SCTP / IP packets include IAB control plane signaling.

30. The first network node according to any one of claims 27 to 28, wherein: The instructions, when executed by the processing circuit, further cause the first network node to: obtain an Internet Protocol (IP) address assigned for use when communicating via LTE.

31. The first network node according to claim 30, wherein: The IP address is obtained using non-access stratum NAS signaling.

32. The first network node according to claim 30, wherein: The IP address is allocated by the operation administration and maintenance OAM system.

33. The first network node according to claim 32, wherein: The instructions, when executed by the processing circuit, further cause the first network node, when obtaining the IP address: sending a message to the OAM system; and In response to the message, configuration information indicative of the assigned IP address is received.

34. The first network node according to claim 30, wherein: The IP address is assigned using Dynamic Host Configuration Protocol DHCP and / or IPv6 Host Discovery.

35. The first network node according to claim 30, wherein: The IP address is obtained in a radio resource control RRC message from an LTE eNodeB, ie, LTE eNB.

36. The first network node according to claim 30, wherein: The instructions, when executed by the processing circuit, further cause the first network node to: when obtaining the IP address, implicitly assign the IP address using an IP address received in a downlink (DL) packet.

37. The first network node according to claim 30, wherein: The one or more SCTP / IP packets include the assigned IP address.

38. The first network node according to any one of claims 27 to 28 and 31 to 37, wherein: The instructions, when executed by the processing circuitry, further cause the first network node to: set up an SCTP connection to the second network node.

39. The first network node according to claim 38, wherein: The instructions, when executed by the processing circuitry, further cause the first network node to: set up an SCTP connection to the second network node in response to an indication from the second network node that an auxiliary SCTP connection is needed.

40. The first network node according to claim 38, wherein: The instructions, when executed by the processing circuit, further cause the first network node to: set up an SCTP connection to the second network node in response to a radio link failure.

41. The first network node according to any one of claims 27 to 28, 31 to 37 and 39 to 40, wherein: The instructions, when executed by the processing circuit, further cause the first network node to: send capability information to one or more of a second network node and an LTE node.

42. The first network node according to any one of claims 27 to 28, 31 to 37 and 39 to 40, wherein: The instructions, when executed by the processing circuit, further cause the first network node to: receive capability information from one or more of the second network node and an LTE node.

43. The first network node according to any one of claims 27 to 28, 31 to 37 and 39 to 40, wherein: The instructions, when executed by the processing circuit, further cause the first network node to: encrypt the one or more SCTP / IP packets.

44. The first network node according to any one of claims 27 to 28, 31 to 37 and 39 to 40, wherein: The one or more SCTP / IP packets are encrypted using IPsec.

45. The first network node according to any one of claims 27 to 28, 31 to 37 and 39 to 40, wherein: The one or more SCTP / IP packets are sent via X2-Application Protocol X2-AP and RRC signaling.

46. ​​The first network node according to claim 45, wherein: The one or more SCTP / IP packets are embedded in an X2 / RRC signaling message.

47. The first network node according to claim 45, wherein: The instructions, when executed by the processing circuit, further cause the first network node to: Generate F1-AP message; Put the F1-AP message into an SCTP packet; Put the SCTP packet into an IP protocol data unit IP PDU; Put the IP PDU into an RRC message; as well as The RRC message is sent to the LTE node.

48. The first network node according to claim 47, wherein: The RRC message is an uplink UL transmission message.

49. The first network node according to any one of claims 27 to 28, 31 to 37, 39 to 40 and 46 to 48, wherein: The one or more SCTP / IP packets are sent via a separate packet data network, PDN, connection to the core network.

50. The first network node according to claim 49, wherein: The instructions, when executed by the processing circuitry, further cause the first network node to: establish a separate PDN connection with a core network using one or more NAS protocols.

51. The first network node according to any one of claims 27 to 28, 31 to 37, 39 to 40, 46 to 48 and 50, wherein: The instructions, when executed by the processing circuit, further cause the first network node to: send the one or more SCTP / IP packets via one of a Radio Link Control (RLC) bearer and a radio bearer in an LTE eNB.

52. The first network node according to claim 51, wherein: The instructions, when executed by the processing circuit, further cause the first network node to: send the one or more SCTP / IP packets via a General Packet Radio Service Tunneling Protocol (GTP) tunnel associated with one of the RLC bearer and the radio bearer.

Images