METHOD FOR PROCESSING COMMUNICATIONS AND NETWORK NODE - Patent application

Abstract

A method performed by a first network node (14) for processing communications in a wireless communication network, the first network node receiving a data packet having a header including an indicated destination, a BAP address, and one or more values ​​that are interpreted by the first network node as reserved or unknown. The first network node checks whether the first network node is an intended destination of the data packet based on the indicated destination in the header. If the first network node is not the intended destination of the data packet and the BAP address is not included in a configured backhaul (BH) routing configuration, the first network node discards the data packet and processes the data packet otherwise.

Description

[Technical field]

[0001] Embodiments herein relate to a first network node, a second network node and a control network node and methods performed thereon for wireless communication. Additionally, computer programs and computer readable storage media are also provided herein. In particular, embodiments herein relate to controlling / managing communications in a wireless communication network and / or handling communications such as packet forwarding to relay network nodes. [Background technology]

[0002] In a typical wireless communication network, User Equipment (UE), also known as wireless communication device, mobile station, station (STA) and / or wireless device, communicates with one or more Core Networks (CN) via a Radio Access Network (RAN). The RAN covers a geographical region that is divided into service areas or cell areas, each service area or cell area being served by a radio network node, such as an access node, e.g., a Wi-Fi access point or, in some networks, a radio base station (RBS), which may also be referred to as a Node B, gNode B or eNode B. A service area or cell area is a geographical area in which radio coverage is provided by a radio network node. The radio network node operates on radio frequencies to communicate over the air interface with UEs within range of the radio network node. The radio network node communicates with the UEs via a downlink (DL) and the UEs communicate with the radio network node via an uplink (UL).

[0003] The Universal Mobile Telecommunications System (UMTS) is a third generation (3G) communications network that evolved from the second generation (2G) Global System for Mobile Communication (GSM). The UMTS Terrestrial Radio Access Network (UTRAN) is essentially a RAN that uses Wideband Code Division Multiple Access (WCDMA) and / or High Speed ​​Packet Access (HSPA) for user equipment. In a forum known as the Third Generation Partnership Project (3GPP), communications suppliers specifically propose and agree standards for current and future generations of networks and UTRANs, investigating improvements in data rates and radio capacity. In some RANs, such as UMTS, several radio network nodes are connected by terrestrial transmission lines or microwaves to a controller node, such as a Radio Network Controller (RNC) or Base Station Controller (BSC), which monitors and coordinates various activities of the multiple radio network nodes connected to it. The RNC is typically connected to one or more core networks.

[0004] The Evolved Packet System (EPS) specification was finalized within 3GPP® for the third generation, and this work will continue in future 3GPP® releases for 6G networks and 5G networks such as New Radio (NR). EPS includes the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as the System Architecture Evolution (SAE) core network. E-UTRAN / LTE is a 3GPP® radio access technology in which radio network nodes are directly connected to the EPC core network. Thus, the RAN in EPS is essentially a "flat" configuration, with radio network nodes directly connected to one or more core networks.

[0005] The new 5G technology, also known as New Radio (NR), is very interested in the use of a large number of transmit and receive antenna elements because it can utilize beamforming, such as transmit beamforming and receive beamforming. Transmit beamforming means that the transmitter can amplify the transmitted signal in a selected direction and suppress the transmitted signal in other directions. Similarly, on the receive side, the receiver can amplify the signal from a selected direction and suppress the unwanted signals from other directions.

[0006] FIG. 1 discloses the overall architecture of Next Generation RAN (NG-RAN).

[0007] The NG-RAN includes a set of gNBs connected to the 5G Core (5GC) via an NG interface.

[0008] Note: As specified in 38.300 v.15.6.0, the NG-RAN may consist of a set of ng-eNBs, which may consist of a ng-eNB central unit (CU) and one or more ng-eNB distributed units (DUs). The ng-eNB-CU and ng-eNB-DU are connected via the W1 interface. The general principles described in this section also apply to the ng-eNB and the W1 interface, unless explicitly specified otherwise.

[0009] The gNBs may support Frequency Division Duplex (FDD) mode, Time Division Duplex (TDD) mode, or dual mode operation. The gNBs may be interconnected via an Xn interface.

[0010] A gNB may consist of a gNB-CU and one or more gNB-DUs. The gNB-CU and gNB-DU are connected via an F1 interface. One gNB-DU is connected to only one gNB-CU.

[0011] Note: In the case of network sharing with multiple cell ID broadcast, each cell identifier (ID) associated with a subset of the public land mobile network (PLMN) corresponds to a gNB-DU and a gNB-CU to which it is connected, i.e., the corresponding gNB-DUs share the same physical layer cell resources.

[0012] Note: For resilience, a gNB-DU may be connected to multiple gNB-CUs with appropriate implementation.

[0013] NG, Xn and F1 are logical interfaces.

[0014] In case of NG-RAN, the NG interface and Xn-C interface of the gNB, consisting of gNB-CU and gNB-DU, are terminated at the gNB-CU. In case of E-UTRAN New Radio - Dual Connectivity (EN-DC), the S1-U interface and X2-C interface of the gNB, consisting of gNB-CU and gNB-DU, are terminated at the gNB-CU. The gNB-CU and the connected gNB-DU are seen only as NBs by other gNBs and g5GCs. Possible deployment scenarios are described in Appendix A.

[0015] For nodes hosting the user plane part of the NR PDCP, e.g., gNB-CU, gNB-CU-UP and EN-DC, depending on the bearer split, the MeNB or SgNB must perform user inactivity monitoring and notify the inactivity, (re)activation to the nodes with C-plane connection to the core network, e.g., via E1, X2. Nodes hosting the NR Radio Link Control (RLC), e.g., gNB-DU, can perform user inactivity monitoring and further notify the inactivity or (re)activation to the nodes hosting the control plane, e.g., gNB-CU or gNB-CU control plane (CP) nodes.

[0016] The UL Packet Data Convergence Protocol (PDCP) configuration (i.e. how the UE uses the UL with the supporting node) is indicated via X2-C (for EN-DC), Xn-C (for NG-RAN) and F1-C. The suspension / resumption of DL and / or UL radio links is indicated via X2-U (for EN-DC), Xn-U (for NG-RAN) and F1-U.

[0017] NG-RAN is layered into a radio network layer (RNL) and a transport network layer (TNL).

[0018] The NG-RAN architecture, i.e. the NG-RAN logical nodes and the interfaces between them, are defined as part of the RNL.

[0019] For each NG-RAN interface (NG, Xn, F1), the relevant TNL protocols and functions are specified. The TNL provides user plane transport and signaling transport services.

[0020] In an NG-Flex configuration, each NG-RAN node is connected to all Access and Mobility Management Functions (AMFs) of an AMF set within an AMF region that supports at least one slice that is also supported by the NG-RAN node. AMF sets and AMF regions are defined in 3GPP TS 23.501 v.15.6.0.

[0021] If there is a need to support security protection of control plane and user plane data over the TNL of the NG-RAN interface, NDS / IP 3GPP® TS 33.501 applies.

[0022] Figure 2 shows the overall architecture for separating the gNB-CU-Control Plane (CP) and the gNB-CU-User Plane (UP). -A gNB may consist of a gNB-CU-CP, multiple gNB-CU-UPs and multiple gNB-DUs. The gNB-CU-CP is connected to the gNB-DU via the F1-C interface. -gNB-CU-UP is connected to gNB-DU via the F1-U interface. -gNB-CU-UP is connected to gNB-CU-CP via an E1 interface. -One gNB-DU is connected to only one gNB-CU-CP. -One gNB-CU-UP is connected to only one gNB-CU-CP. Note 1: For resilience, a gNB-DU and / or a gNB-CU-UP may be connected to multiple gNB-CU-CPs by appropriate implementation. -One gNB-DU may be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP. -One gNB-CU-UP may be connected to multiple DUs under the control of the same gNB-CU-CP. Note 2: The connection between the gNB-CU-UP and the gNB-DU is established by the gNB-CU-CP using the bearer context management function. NOTE 3: The gNB-CU-CP selects for the UE the appropriate gNB-CU-UP for the requested service. In case of multiple CU-UPs, they belong to the same security domain as defined in TS 33.210 v.15.6.0. Note 4: Data transfer between gNB-CU-UP during intra-gNB-CU-CP handover within a gNB may be supported by Xn-U. F1-AP is defined in TS38.473v.15.6.0. E1 is defined in TS38.463v.15.6.0.

[0023] An overview of Integrated Access Backhaul (IAB) network protocols and architecture.

[0024] 3GPP is currently standardizing integrated access and radio access backhaul in NR (IAB) in Rel-17.

[0025] The use of short-distance mmWave spectrum in NR requires dense deployment using multi-hop backhaul. However, optical fiber to every base station is costly and in some cases not possible (e.g. historic sites). The main principle of IAB is to use radio links rather than fiber for the backhaul to allow flexible and dense deployment of cells without densifying the transport network. IAB use case scenarios may include coverage extension, multiple small cell deployments and fixed wireless access (FWA) (to residential / office buildings, etc.). The wider bandwidth available for NR in mmWave spectrum provides the opportunity for self-backhaul without limiting the spectrum used for the access link. Furthermore, NR's inherent support for multi-beam and multiple-input multiple-output (MIMO) reduces cross-link interference between the backhaul and the access link, facilitating densification.

[0026] During the study item phase of the IAB work, outlined in technical report TR38.874v.15.6.0, it was agreed to apply a solution that leverages the Central Unit (CU) / Distributed Unit (DU) split architecture of NR, where an IAB node hosts the DU part controlled by the central unit. The IAB node also has a Mobile Termination (MT) part to communicate with its parent node.

[0027] The IAB specification reuses some existing functions and interfaces defined in NR. In particular, the MT, gNB-DU, gNB-CU, UPF, AMF and SMF and the corresponding interfaces NR Uu (between MT and gNB), F1, NG, X2 and N4 are used as a baseline for the IAB architecture. Modifications or extensions of these functions and interfaces to support IAB are detailed in the context of the architecture description. Additional functionality such as multi-hop forwarding is included in the architecture description because it is necessary to understand the operation of IAB and certain aspects may require standardization.

[0028] The MT function is defined as a component of an IAB node. In the context of this study, MT refers to the functionality present on an IAB node that terminates the radio interface layer of the backhaul Uu interface to an IAB donor or other IAB node.

[0029] Figure 3 shows a reference diagram of the IAB in standalone mode in a high-level architectural view of an IAB network with one IAB donor and multiple IAB nodes. The IAB donor is treated as a single logical node that includes a set of functions such as gNB-DU, gNB-CU-CP, gNB-CU-UP, and possibly other functions. In deployment, the IAB donor can be split according to these functions, all of which may or may not be co-located as allowed by the 3GPP NG-RAN architecture. When such a split is made, IAB-related aspects may arise. Also, some of the functions currently associated with the IAB donor may eventually be moved outside the donor if it turns out that they are not performing IAB-specific tasks.

[0030] The IAB baseline user plane and control plane protocol stacks are shown in Figures 4 and 5.

[0031] The selected protocol stack reuses the current CU-DU split specification in rel-15, where the full user plane F1-U (GTP-U / UDP / IP) is terminated at the IAB access node, i.e. the IAB node where the UE is connected, just like a normal DU, and the full control plane F1-C (F1-AP / SCTP / IP) is also terminated at each IAB node, just like a normal DU. In the above case, Network Domain Security (NDS) is employed to protect both UP and CP traffic, with IP Security (IPsec) for UP and Datagram Transport Layer Security (DTLS) for CP. IPsec can also be used for CP protection instead of DTLS, in which case the DTLS layer is not used.

[0032] A new protocol layer called Backhaul Adaptation Protocol (BAP) is introduced in the IAB nodes and IAB donors, which is also used between the incoming and outgoing backhaul (BH) RLC channels of intermediate IAB nodes to route packets to the appropriate downstream or upstream node, map UE bearer data to the appropriate backhaul RLC channel, and satisfy the end-to-end Quality of Service (QoS) requirements of the bearer. Thus, the BAP layer is responsible for processing the BH RLC channels, e.g., mapping the incoming BH RLC channel from a parent or child IAB node to an outgoing BH RLC channel in the link towards the child or parent IAB node.

[0033] In particular, one BH RLC channel may carry several Data Radio Bearers (DRBs) and end user traffic of different UEs that may be connected to different IAB nodes in the network. 3GPP provides two possible configurations of BH RLC channels: a 1:1 mapping between the BH RLC channel and the DRB of a particular user, and an N:1 bearer mapping, where N DRBs that may be associated with different UEs are mapped to one BH RLC channel. The first case can be easily handled by the scheduler of the IAB node, since there is a 1:1 mapping between the QoS requirements of the BH RLC channel and the QoS requirements of the associated DRBs. However, this type of 1:1 configuration does not scale easily when an IAB node is serving a large number of UEs / DRBs. On the other hand, the N:1 configuration is more flexible and scalable, but it is difficult to ensure fairness between the various serving BH RLC channels, since the amount of DRBs and / or UEs served by a particular BH RLC channel may differ from the amount of DRBs and / or UEs served by another BH RLC channel.

[0034] As shown in Figures 2 and 3, in an IAB node, also called a relay node, the BAP sublayer contains one BAP entity in the MT function and another BAP entity co-located in the DU function. In an IAB donor DU, the BAP sublayer contains only one BAP entity. Each BAP entity has a transmit part and a receive part. The transmit part of the BAP entity is communicated via a backhaul link to the corresponding receive part of the BAP entity in the IAB node or the IAB donor DU.

[0035] The BAP layer performs several functions: -Transfer of data. - Routing the packet to the next hop. -Determining the BAP destination and BAP path of packets from higher layers such as layers 5 to 7. - Determining the egress BH RLC channel for the packet to be routed to the next hop. -Distinguishing between traffic delivered to higher layers and traffic delivered to output links. -Flow control feedback signal transmission. -BH Radio Link Failure (RLF) indication.

[0036] The BAP layer is therefore the basis for deciding how to route a received packet. For downstream user plane data, this means determining if the packet has arrived at its final destination, in which case it is either sent to a UE connected to this IAB node or forwarded to another IAB node on the correct path. In the first case, the BAP layer passes the packet to the upper layers in the IAB node, which are responsible for mapping the packet to the various QoS flows, i.e. DRBs, contained in the packet. In the second case, the BAP layer instead determines the appropriate outgoing BH RLC channel based on the BAP destination, the path ID and the incoming BH RLC channel. The same as above applies for the upstream, the only difference being that the final destination is always one specific donor DU / CU.

[0037] To accomplish the above task, the BAP layer of the IAB node needs to be configured with a routing table that maps incoming RLC channels to outgoing RLC channels, which may vary depending on the particular BAP destination and path of the packet. Thus, the BAP destination and path ID are included in the header of the BAP packet, so that the BAP layer can determine where to forward the packet.

[0038] Additionally, the BAP layer plays an important role in hop-by-hop flow control: in particular, a child node can inform a parent node about possible congestion locally at the child node, so that the parent node can throttle traffic to the child node. A parent node can use the BAP layer to inform a child node of RLF problems experienced by the parent, so that the child node may re-establish a connection to a different parent node.

[0039] Packet Routing at the BAP Layer As explained in the above sections, an IAB node uses information contained in the BAP header, such as the BAP destination and the BAP path ID, to determine whether a received packet has reached its final destination or needs to be routed to another node. In particular, if a packet is not received at its final BAP destination, the IAB node needs to match the information contained in the BAP header with a BAP mapping configuration that contains BH routing information, allowing the IAB node to obtain the next hop and BH RLC channel to which the associated BAP packet should be sent.

[0040] The Rel.16 BAP data PDU format is shown in Figure 6. Currently, a BAP PDU consists of a BAP header, which contains a D / C field, three "R" reserved fields, one destination field, one path field, and data.

[0041] The destination field carries the BAP address of the destination IAB node or IAB donor DU.

[0042] The pass field carries the BAP pass ID.

[0043] The R field is reserved. In this version of the specification, the reserved bits are set to 0. The reserved bits are ignored by receivers.

[0044] The D / C field indicates whether the corresponding BAP PDU is a BAP data PDU or a BAP control PDU.

[0045] From a functional point of view, the receiving part of the BAP entity in the IAB node needs to inspect the BAP packet and decide how to forward the packet. If the packet reaches the final destination, i.e., if the IAB node is the destination node of this packet, the BAP entity removes the BAP header and passes it to the upper layers in the IAB node. The received packet is either an F1-U packet or an F1-C packet. In the case of an F1-U packet, it contains user plane data of the access UE connected to the IAB node. The UE DRB is encapsulated in a GPRS Tunneling Protocol (GTP) / User Datagram Protocol (UDP) / IP packet, and the upper layers decompose the GTP packet and decide to which UE and / or DRB to send such packet. See Figure 4. In the case of an F1-C packet, the message is carried in the F1AP encapsulated in Stream Control Transmission Protocol (SCTP) and / or IP. The F1AP message can carry the BAP configuration or the IAB node DU configuration. It can also carry Radio Resource Control (RRC) messages for the access UE or child MT. If the F1AP carries RRC messages, they are sent to the IAB node DU and assigned to a signaling radio bearer (SRB) of either the access UE or the child MT (see Figure 5). Otherwise, if the packet has not reached its final destination, the receiving BAP entity passes the packet to the transmitting part of the BAP sublayer, which decides where to route the packet based on the configured routing table. TS38.340 specifies two ways for the receiving part of the BAP sublayer to interact with the transmitting part when passing BAP packets:

[0046] 1. The receiving part of the BAP entity delivers the BAP PDU to the transmitting part of the co-located BAP entity without stripping off the BAP header, i.e., the receiving part transmits the BAP PDU to the transmitting part as it was received without modification.

[0047] 2. Alternatively, the receiving part may deliver the BAP SDU to the co-located transmitting part. When passing the BAP SDU, the receiving part removes the BAP header and the transmitting part adds a BAP header with the same BAP Routing ID that was included in the BAP PDU header before the removal. This method means that the BAP header is stripped by the receiving part and the receiving part passes the BAP SDU to the transmitting part.

[0048] On the other hand, the sending part of the BAP entity can receive data from upper layers, i.e. when the BAP entity is an IAB donor node or is hosted by the receiving part of the BAP entity. If a BAP packet does not have a BAP header, e.g. when a BAP Service Data Unit (SDU) is received from upper layers or when the BAP header is removed and received from the receiving part of this BAP entity, the sending part builds a BAP Protocol Data Unit (PDU) as described in bullet 2, i.e. a destination field corresponding to the BAP address and a path field corresponding to the BAP Path ID are added. When the BAP entity has a BAP data PDU to send, the sending part of the BAP entity must do the following: -Performs routing that determines output links based on the BH routing configuration provided by the CU - Determine the output BH RLC channel based on the BH RLC channel mapping configuration provided by the CU - Transmit this BAP Data PDU to the selected output BH RLC channel of the selected output link

[0049] The interaction between the transmitting and receiving parts is shown in FIG.

[0050] IAB nodes also process BAP control PDUs. Unlike the processing of BAP data PDUs described above, in Rel.16 BAP control PDUs are not forwarded across multiple hops and can only be sent from child to parent or vice versa. BAP control PDUs are only used in the current specification for flow control purposes between child and parent nodes and for BH RLF indications sent by parent nodes to child nodes to indicate the RLF experienced by the parent on one outgoing link in the uplink direction.

[0051] Two examples of BAP control PDUs are shown in Figure 8 and Figure 9. Other possible BAP control PDUs are specified in TS 38.340 v.16.0.0. Summary of the Invention [Problem to be solved by the invention]

[0052] According to the existing TS38.340 v.16.0.0, if a BAP PDU is received by an IAB node and this BAP PDU contains a reserved or unknown value or contains a BAP address that is not included in the configured BH routing configuration and is not the BAP address of this node, the BAP entity shall discard the received BAP PDU. Therefore, the scenario where an IAB node receives a BAP PDU containing a reserved or unknown value is considered an error case since the IAB nodes present in the network cannot decode the BAP header, and the receiving IAB node must discard such packets to avoid unnecessarily forwarding such packets to other IAB nodes.

[0053] However, if 3GPP agrees to extend the BAP header in a future release, some of the "new" IAB nodes that are compliant with this new 3GPP release may adopt this new BAP header, while "old" IAB nodes that are not compliant with this new 3GPP release may not understand this new BAP header. In particular, "old" IAB nodes will interpret a BAP PDU as "containing a reserved value" if any of the "R" fields in the header are set. On the other hand, if the BAP header contains any new fields not specified in the BAP header format of Figure 6, the IAB nodes will interpret the BAP PDU as "containing an unknown value".

[0054] If an IAB network consists of a mix of IAB nodes conforming to different 3GPP releases, there is a possibility that some of the "new" IAB nodes set certain new fields in the BAP header or use fields that were reserved in previous releases of the BAP header format. If a BAP PDU with such a header is received by an "old" IAB node, it will be discarded according to the current specification, since it cannot decode such a BAP PDU. Therefore, in this case, the scenario where an IAB node receives a BAP PDU with reserved or unknown values ​​should not be seen as an error case, but as a possible scenario that may occur in this type of network deployment, where IAB nodes of different releases may forward packets to each other.

[0055] For example, as shown in Figure 10, the "new" IAB node 1 can set some new fields in the new BAP header of a specific BAP PDU packet destined for the "new" IAB node 3, which is the destination node of this BAP PDU. Such new fields can be decoded by the "new" IAB node 3, but not by the "old" IAB node 2. Therefore, when the "old" IAB node 2 receives such a BAP PDU, according to the current legacy specification, the "old" IAB node 2 will unnecessarily discard the BAP PDU, even though the packet is destined for the "new" IAB node 3.

[0056] Such an action will result in loss of data since the entire BAP PDU will be discarded and may also result in loss of control information, in fact the BAP header of the BAP data PDU may contain control information that may be used by other IAB nodes in the network or by the donor IAB node DU / CU, such information is also lost.

[0057] The above problems affect both upstream and downstream.

[0058] An object herein is to provide a mechanism for enabling communication, eg, processing or managing communication of PDUs, in an efficient manner in a wireless communication network. [Means for solving the problem]

[0059] According to one aspect, this object is achieved by providing a method according to an embodiment herein, performed by a first network node, such as an IAB node of a prior release, for processing or managing communications in a wireless communication network, the first network node comprising: By BAP address The destination indicated , No.and one or more values ​​that are interpreted by one network node as reserved or unknown. The first network node checks whether the first network node is an intended destination of the data packet based on the destination indicated in the header. On a condition that the first network node is not an intended destination of the data packet and the BAP address is not included in the configured BH routing configuration, the first network node discards the data packet. Otherwise, the first network node processes the data packet. For example, if the BAP address is included in the configured BH routing configuration, the first network node processes the data packet.

[0060] According to another aspect, the object is achieved by providing a method performed by a second network node, such as a later release IAB node, for processing or managing communications in a wireless communication network according to an embodiment herein. The second network node determines whether another network node complies with the release of the specification to which the second network node complies. The second network node then processes data packets destined for the other network node based on the determination of whether the other network node complies with the release of the specification to which the second network node complies.

[0061] According to yet another aspect, the object is achieved by a method, according to an embodiment herein, performed by a controlling network node, such as a donor or OAM node, for processing or managing communications in a wireless communication network, the controlling network node configuring all hosted IAB nodes such that they understand the space of known fields.

[0062] According to one aspect, this object is achieved by providing a first network node, a second network node and a control network node, each configured to perform the method herein according to an embodiment herein.

[0063] Thus, there is provided herein a first network node, such as an IAB node of a prior release, for processing or managing communications in a wireless communication network, the first network node comprising: By BAP address The destination indicated , No. and a header including one or more values ​​that are interpreted by one network node as reserved or unknown. The first network node checks whether the first network node is an intended destination of the data packet based on the destination indicated in the header. On a condition that the first network node is not the intended destination of the data packet and the BAP address is not included in the configured BH routing configuration, the first network node discards the data packet. Otherwise, the first network node is configured to process the data packet. For example, the first network node is configured to process the data packet if the BAP address is included in the configured BH routing configuration.

[0064] According to another aspect, the object is achieved by providing a second network node, such as a later release IAB node, for processing or managing communications in a wireless communication network according to embodiments herein. The second network node is configured to determine whether another network node complies with a release of the specification to which the second network node complies. The second network node is then configured to process data packets destined for the other network node based on a determination of whether the other network node complies with the release of the specification to which the second network node complies.

[0065] According to yet another aspect, the object is achieved by a control network node, such as a donor or OAM node, for processing or managing communications in a wireless communication network according to embodiments herein, the control network node being configured to configure the IAB nodes such that all hosted IAB nodes understand the space of known fields.

[0066] Further provided herein is a computer program product comprising instructions which, when executed on at least one processor, cause the at least one processor to perform the above-mentioned methods performed by the first network node, the second network node and the control network node, respectively. Further provided herein is a computer readable storage medium storing a computer program product comprising instructions which, when executed on at least one processor, cause the at least one processor to perform the above-mentioned methods performed by the first network node, the second network node and the control network node, respectively.

[0067] The embodiments herein provide one or more network nodes, such as an IAB node, to avoid unnecessarily discarding a PDU when the header of the PDU contains a value that is reserved or unknown to the network node concerned. Thus, an advantage of the embodiments herein is that discarding packets can be avoided when discarding is not necessary. This means that loss of data and control information contained in the BAP header and passing through the IAB network is reduced. Thus, the embodiments herein enable reliable communication, e.g., signaling handling or management, in an efficient manner in a wireless communication network.

[0068] Details of the embodiments will now be described in detail with reference to the accompanying drawings. [Brief description of the drawings]

[0069] [Figure 1] FIG. 1 shows a network architecture according to the background art. [Diagram 2] FIG. 1 shows an architecture according to the background art. [Diagram 3] Reference diagram for IAB architecture (TR38.874). [Figure 4] Background Art Protocol Stack. [Diagram 5] Background Art Protocol Stack. [Figure 6] FIG. 1 shows a Rel. 16 BAP data PDU format with BAP header and data according to the prior art. [Figure 7] A diagram showing how the sending and receiving parts of the BAP sublayer of one IAB node can interact with each other. [Figure 8] 1 illustrates a BAP control PDU format for flow control feedback per BH RLC channel. [Figure 9] A diagram showing a BAP control PDU format for BH RLF indication. [Figure 10] Diagram showing an IAB network with IAB nodes of different releases communicating with each other. [Figure 11a] 1 is a diagram showing an overview of a wireless communication network according to an embodiment of the present invention; [Figure 11b] 4 is a flowchart of a method performed by a first network node according to the embodiment. [Figure 12a] 4 is another flowchart of the method performed by the first network node according to the embodiment. [Figure 12b] 4 is a flowchart of a method performed by a second network node according to the embodiment. [Figure 12c] 4 is a flowchart of a method performed by a control network node according to the present embodiment. [Figure 13] 4 is a flowchart of a method performed by a first network node according to the embodiment. [Figure 14] FIG. 2 is a diagram illustrating an overview of a method for processing a received BAP PDU according to the present embodiment. [Figure 15]FIG. 2 is a diagram illustrating an overview of a method for processing a received BAP PDU according to the present embodiment. [Figure 16] 4 is a flowchart of a method performed by a first network node according to the embodiment. [Figure 17] FIG. 2 is a diagram illustrating an overview of a method for processing a received BAP PUD according to the present embodiment. [Figure 18] 4 is a flowchart of a method performed by a second network node according to the embodiment. [Figure 19] Diagram showing an IAB network with IAB nodes of different releases communicating with each other. [Figure 20] FIG. 2 is a block diagram of an embodiment of a first network node according to the present embodiment. [Figure 21] FIG. 4 is a block diagram of an embodiment of a second network node according to the present embodiment. [Figure 22] FIG. 2 is a block diagram of an embodiment of a control network node according to the present embodiment. [Figure 23] FIG. 1 illustrates an exemplary communications network connected to a host computer through an intermediate network. [Figure 24] 1 is a generalized block diagram of a host computer communicating with user devices over a partially wireless connection via a base station. [Diagram 25] 4 is a flow chart illustrating a method performed in a communications system including a host computer, a base station, and user equipment. [Figure 26] 4 is a flow chart illustrating a method performed in a communications system including a host computer, a base station, and user equipment. [Figure 27] 4 is a flow chart illustrating a method performed in a communications system including a host computer, a base station, and user equipment. [Figure 28] 4 is a flow chart illustrating a method performed in a communications system including a host computer, a base station, and user equipment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0070] The present embodiments generally relate to wireless communication networks. Figure 11a shows a schematic of a wireless communication network 1. The wireless communication network 1 comprises one or more RANs and one or more CNs. The wireless communication network 1 may use one or more different technologies. The embodiments herein relate to recent technology trends of particular interest in the context of New Radio (NR), but the embodiments are also applicable to further developments of existing wireless communication systems, such as, for example, LTE or Wideband Code Division Multiple Access (WCDMA).

[0071] In a wireless communication network 1, user equipment (UE) 10, such as a mobile station, wireless device, non-access point (non-AP) station (STA), STA and / or wireless terminal, communicates with one or more core networks (CN) via one or more access networks (AN), e.g., RAN. Those skilled in the art will appreciate that "UE" is a non-limiting term meaning any terminal, such as a wireless communication terminal, user equipment, narrowband Internet of Things (NB-IoT) device / machine-based communication (MTC) device, device-to-device (D2D) terminal or node, smartphone, laptop, mobile phone, sensor, repeater, mobile tablet, or small base station capable of wirelessly communicating with a wireless network node within an area served by the wireless network node.

[0072] The wireless communication network 1 includes a first radio network node 12, which may be an IAB node such as an IAB donor node or IAB-CU, a baseband unit (BBU), an access node, an access controller, a gNodeB (gNB), an evolved NodeB (eNB, eNodeB), a NodeB, a radio base station, a radio remote unit, a base station such as an access point base station, a base station router, a wireless local area network (WLAN) access point or access point station (AP STA), an MME, an AMF, a standalone access point, or any other network unit or node capable of communicating with wireless devices within a service area served by the radio network node, depending on the first radio access technology and terminology used. The first radio network node 12 may also be referred to as a serving or source node or a RAN node. It is noted that a service area may be viewed as a cell, beam, beam group, or the like that defines an area of ​​radio coverage. The first radio network node may also be referred to as a first network node herein.

[0073] The wireless communication network 1 further comprises a first intermediate radio network node 13 connected between the first network node 12 and the UE 10. Depending on the first radio access technology and terminology used, the first intermediate radio network node 13 may be an IAB node such as an IAB-DU, a Remote Radio Unit (RRU), an access node, an antenna unit, e.g. a gNodeB (gNB), an evolved NodeB (eNB, eNodeB), a NodeB, a base transceiver station, a radio remote unit, a radio unit of a radio base station such as an access point base station, a base station router, a Wireless Local Area Network (WLAN) access point or access point station (AP STA), a transmission arrangement of a radio base station, a standalone access point, or any other network unit or node capable of communicating with wireless devices in a service area served by the radio network node.

[0074] The wireless communication network further comprises a second intermediate wireless network node, which is an example of a first network node 14 according to an embodiment of the present specification, connected between the first wireless network node 12 and the UE 10. The first network node 14 may be directly connected to the UE 10 and may be an egress / entrance point. The first network node 14 may be an IAB node, such as a gNodeB (gNB), evolved NodeB (eNB, eNodeB), NodeB, base transceiver station, wireless remote unit, access point base station, base station router, wireless local area network (WLAN) access point or access point station (AP STA), a transmission configuration of a wireless base station, a standalone access point, or a remote radio unit (RRU) of a wireless base station, such as a wireless network node, an access node, an antenna unit, a radio unit, or any other network unit or node capable of communicating with wireless devices within a service area served by the wireless network node, depending on the first wireless access technology and terminology used. It is noted that a service area may be viewed as a cell, a beam, a beam group, or the like that defines an area of ​​wireless coverage. The first network node 14 complies with the first release version of the specification and is, for example, an "old" IAB node.

[0075] The wireless communication network 1 may further comprise a third intermediate wireless network node, which is an example of a second network node 15, connected to the first network node 14, other network nodes and / or served UEs. The second network node 15 is an IAB node, which may be, for example, a gNodeB (gNB), evolved NodeB (eNB, eNodeB), NodeB, base transceiver station, radio remote unit, access node, antenna unit, radio unit, or other radio remote unit (RRU) of a radio base station, for example, a gNodeB (gNB), evolved NodeB (eNB, eNodeB), NodeB, base transceiver station, radio remote unit, access point base station, base station router, wireless local area network (WLAN) access point or access point station (AP STA), transmission configuration of a radio base station, standalone access point, or other network unit or node capable of communicating with wireless devices in a service area served by the radio network node. It is noted that a service area may be denoted as a cell, beam, beam group, or the like that defines an area of ​​radio coverage. The second network node 15 complies with the second release version of the specification, and is, for example, a "new" IAB node. In this manner, the first released version may differ from the second released version.

[0076] SUMMARY OF THE DISCLOSURE Embodiments herein aim to provide one or more solutions for handling data packets of different release versions in wireless communication networks.

[0077] Please note the following: · The term "BAP PDU" may refer to either a "BAP data PDU" or a "BAP control PDU". The term "old" IAB node refers to an IAB node that complies with a specific Release X of the 3GPP® specifications and that interprets received BAP PDUs as "contains a reserved value" or "contains an unknown value". · An IAB node shall interpret a received BAP PDU as "containing reserved values" if the BAP header contains one or more of the fields that are reserved in the BAP header format of release X. · An IAB node shall interpret a received BAP PDU as "containing unknown values" if the BAP header contains one or more new fields that are not specified in the BAP header format of Release X. The term "new" IAB node refers to an IAB node that complies with release X and a later release Y, i.e., the "new" IAB node can decode one or more fields that are interpreted as "reserved" or "unknown" by an "old" IAB node. The terms “gNB-CU”, “donor-CU”, “CU-CP” and “CU” are used interchangeably. The term “gNB” applies to all its variations, including “gNB”, “en-gNB”, etc. The term “IAB donor” refers to a gNB that provides network access to a UE via a backhaul and access link network. · The term "intermediate IAB node" refers to an IAB node that has one or more input BH RLC channels and one or more output BH RLC channels. The term "IAB Access Node" refers to the IAB Node that provides the access link to the UE for a particular BAP PDU. The term "IAB node" refers to either an "IAB donor", an "intermediate IAB node", or an "IAB access node".

[0078] Method operations performed by a first network node 14, such as a first IAB node, for processing communications in a wireless communication network 1 according to the present embodiment will now be described with reference to the flow chart shown in Fig. 11b. The actions do not have to be performed in the following order but may be performed in any suitable order. Dashed boxes indicate optional features.

[0079] Action 1101. A first network node 14: By BAP address The destination indicated , No. 1 receives a data packet having a header including one or more values ​​that are interpreted by the network node 14 as reserved or unknown.

[0080] Action 1102. The first network node 14 checks whether the first network node 14 is the intended destination of the data packet based on the destination indicated in the header.

[0081] Action 1103. Provided that the first network node 14 is not the intended destination of the data packet and the BAP address is not included in the configured BH routing configuration, the first network node 14 discards the data packet.

[0082] Action 1104. Otherwise, the first network node 14 processes the data packet. For example, the first network node may process the data packet provided that the first network node is the intended destination of the data packet or the BAP address is included in the configured BH routing configuration. Processing the data packet may include sending the data packet to the next hop second network node, regardless of whether the header includes one or more values ​​that are interpreted as reserved or unknown by the first network node, or removing one or more octets of the header that include one or more reserved or invalid values ​​and sending the service data unit to an upper layer.

[0083] Action 1105. The first network node 14 may store and report to an IAB donor, an OAM node, or a higher layer of the first network node 14 information regarding the fact that the first network node 14 received packet data containing a reserved or unknown value.

[0084] Method operations performed by a first network node 14, such as a first IAB node, for processing communications in a wireless communication network 1 according to the present embodiment will now be described with reference to the flow chart shown in Fig. 12a. The actions do not have to be performed in the following order but may be performed in any suitable order. Dashed boxes indicate optional features.

[0085] Action 1201. A first network node 14 may receive a data packet having a header (BAP header), for example, from a parent network node or a child network node.

[0086] Action 1202. The first network node 14 determines or checks whether the first network node is the intended destination of the data packet, for example, whether the BAP PDU contains in its BAP header a BAP destination that matches the BAP address of this IAB node.

[0087] Action 1203. Provided that the first network node 14 is the intended destination of the data packet, the first network node 14 discards the data packet if the data packet contains a value in its BAP header that is "reserved" or "unknown" to the first network node 14, or removes one or more octets of the data packet that are part of the header from the data packet in accordance with the specification to which the first network node conforms, and delivers the resulting SDU to the upper layer.

[0088] Action 1204. Provided that the first network node 14 is not the intended destination of the data packet, the first network node 14 may transmit the data packet to the second network node 15, such as the third IAB of the next hop, regardless of whether the header contains one or more values ​​that are "reserved" or "unknown" to the first network node 14. For example, the first network node 14 may remove from the data packet the octets of the data packet that are part of the header according to a specification to which the first network node 14 adheres. The first network node 14 may then store the removed header and deliver the resulting SDU and the removed header to the transmitting part of the BAP entity. The first network node 14 may then add the removed header (or a new header that is identical (i.e., has the same value) as the removed header) to the SDU in the transmitting part of the BAP entity. The transmitting part may thus generate a BAP PDU.

[0089] Action 1205. The first network node 14 may store information relating to the fact that it has received a data packet containing a reserved or unknown value.

[0090] Action 1206. The first network node 14 may then report the information to an IAB donor, an operations, administration and maintenance (OAM) node, or a higher level layer of the first network node 14.

[0091] Method operations performed by a second network node 15, e.g. an IAB node, such as an IAB node of a later release than the first network node 14, for processing communications in a wireless communication network 1 according to the present embodiment will now be described with reference to the flow chart shown in Fig. 12b. The actions do not have to be performed in the following order but may be performed in any suitable order. Dashed boxes indicate optional features.

[0092] Action 1211. The second network node 15 may receive an indication from another network node or a controlling network node, such as the first radio network node 12 or an OAM node, of the release of the specification to which the other next hop network node complies.

[0093] Action 1212. The second network node 15 determines whether another network node complies with the release of the specification to which the second network node complies.

[0094] Action 1213. The second network node 15 then processes the data packet destined for the other network node based on a determination of whether the other network node complies with the release of the specification to which the second network node complies, e.g., the second network node applies a header to the SDU to which the next-hop network node complies.

[0095] Method operations performed by a control network node, such as an IAB node or an OAM node, for handling communications in a wireless communication network 1 according to the present embodiment will now be described with reference to the flow chart shown in Fig. 12c. The actions do not have to be performed in the following order but may be performed in any suitable order. Dashed boxes indicate optional features.

[0096] Action 1221. The control network node 12 may receive one or more indications of the capabilities, such as release compliance, of a hosted network node.

[0097] Action 1222. The control network node 12 may configure the IAB nodes so that all hosted IAB nodes understand the space of known fields, for example, assigning BAP addresses and path identifiers according to one and the same format.

[0098] Embodiments herein include one or more of the following steps.

[0099] The first method, shown in FIG. 13, is defined for a BAP entity in a first network node 14, exemplified as the first IAB node 14, which is the “old” IAB node, and is designed to process received BAP PDUs without stripping, and includes the following:

[0100] Action 1301. The first IAB node 14 receives a BAP PDU from another IAB node, such as the first intermediate node 13, at the receiving portion of the BAP entity.

[0101] Action 1302. The first IAB node 14, for example in the receiving part of the BAP entity, determines whether the BAP PDU contains a BAP destination in its BAP header that matches the BAP address of this IAB node, i.e., whether the IAB node is an “IAB access” node for the BAP PDU.

[0102] The first IAB node 14 performs one of the following actions depending on the outcome of action 1302:

[0103] The result of action 1302 is that the IAB node is the IAB destination node of the BAP PDU.

[0104] Action 1303. The first IAB node 14 discards the BAP PDU if the BAP PDU contains a value in its BAP header that is "reserved" or "unknown" to the IAB node, otherwise Action 1304. The first IAB node 14 removes from the BAP PDU the octets of the BAP PDU that are part of the BAP header according to the specification to which this IAB node complies. It delivers the resulting BAP SDU to the upper layer. This method is illustrated in FIG. 14 below, where the "old" IAB node removes the parts of the BAP header that it detects as part of the BAP header, i.e. the green parts of the BAP header, and passes the remaining parts of the BAP PDU, i.e. the blue parts (i.e. the parts that will become the BAP SDU), to the upper layer. Such remaining parts may include one or more "new fields" that the "old" IAB node does not detect as part of the BAP header. The upper layer then processes the received BAP SDU and discards any content from it that is not associated with data.

[0105] If the result of action 1302 is that the IAB node is not the IAB destination node of the BAP PDU.

[0106] Action 1305. The first IAB node 14 delivers the BAP PDU to the sending part of the BAP entity, regardless of whether the BAP PDU contains a value in its BAP header that is "reserved" or "unknown" to the IAB node. In some cases, action 1305 may imply that the receiving BAP entity forwards the BAP-PDU as is (without modifying any fields in the header) to the BAP transmitting entity. If the first IAB node 14 determines in action 1302 that it is not the IAB destination node of the BAP PDU, it ignores ("ignore" means do not modify) the BAP header of the BAP PDU. Alternatively, action 1305 implies that the IAB node considers that the BAP header contains a "reserved" or "unknown field". For example, it can store information related to the fact that it received a BAP PDU containing a reserved or unknown value. This information can then be reported by the IAB node to the IAB donor CU, the OAM or to upper layers of the IAB node. The same method can be applied when discarding the BAP PDU in action 1303, i.e. when the IAB node is the access IAB node for the BAP PDU. When reporting to the CU, a new F1AP message must be specified with the content of the BAP header abnormal message. Action 1306. The first IAB node 14 transmits the BAP PDU to the next hop third IAB node 15, which may be a new IAB node. Before transmitting the BAP PDU, the transmitting part of the BAP entity may modify only known fields of the BAP PDU, e.g., may modify the destination or path identifier associated with the BAP PDU if required by special circumstances configured by the network. · The third IAB node 15 is able to understand the contents of the BAP PDU because the BAP header has not been removed and the unknown and reserved fields of the BAP PDU have not been modified by the transmitting part of the first IAB node 14.

[0107] Thus, Figure 14 outlines how to process a received BAP PDU if the concerned "old" IAB node is the IAB destination node of this BAP PDU, is implemented according to the first method and performs action 1304. The IAB node strips off the part of the BAP header that it detects as a BAP header, i.e. the first part of the BAP header, and passes the remaining part of the BAP PDU, i.e. the second part, to the upper layer. Such remaining part may contain one or more "new fields" that the "old" IAB node does not detect as part of the BAP header. In this case, the action according to the specification is to discard the packet.

[0108] Figure 15 gives an overview of how to process a received BAP PDU if the concerned "old" IAB node is not the IAB Access Node for this BAP PDU, but is implemented according to the first method and performs action 1305. The received BAP PDU, i.e. the main part, is passed by the receiving part to the sending part of the BAP entity, ignoring (i.e. unchanged) the contents of the BAP header.

[0109] The second method, shown in FIG. 16, is defined for a BAP entity in an IAB node, such as the first IAB node 14, that is an "old" IAB node, designed to process received BAP PDUs, strip off the BAP headers, and deliver the BAP SDUs to the transmitting portion of the BAP entity, and includes the following:

[0110] Action 1601. The first IAB node 14 receives a BAP PDU from another IAB node, such as the first intermediate node 13, at the receiving portion of the BAP entity.

[0111] Action 1602. The first IAB node 14, for example in the receiving part of the BAP entity, determines whether the BAP PDU contains in its BAP header a BAP destination that matches the BAP address of this IAB node, i.e., whether the IAB node is an “IAB access” node for the BAP PDU.

[0112] The first IAB node 14 performs one of the following actions depending on the outcome of action 1602:

[0113] The result of action 1602 is that the IAB node is the IAB destination node of the BAP PDU.

[0114] Action 1603. The first IAB node 14 discards the BAP PDU if the BAP PDU contains a value in its BAP header that is "reserved" or "unknown" to the IAB node, otherwise

[0115] Action 1604. The first IAB node 14 removes from the BAP PDU the octets of the BAP PDU that are part of the BAP header according to the specification to which this IAB node complies. It delivers the resulting BAP SDU to the upper layer. This method is illustrated in FIG. 14 below, where the "old" IAB node removes the parts of the BAP header that it detects as part of the BAP header, i.e. the green parts of the BAP header, and passes the remaining parts of the BAP PDU, i.e. the blue parts (i.e. the parts that will become the BAPSDU), to the upper layer. Such remaining parts may include one or more "new fields" that the "old" IAB node does not detect as part of the BAP header. The upper layer then processes the received BAP SDU and discards any content therefrom that is not associated with data.

[0116] If the result of action 1602 is that the IAB node is not the IAB destination node of the BAP PDU.

[0117] Action 1605. The first IAB node 14 removes from the BAP PDU those octets of the BAP PDU that are part of the BAP header according to the specification to which this IAB node complies. Action 1606. The first IAB node 14 then stores the removed header and delivers the resulting BAP SDU and the removed header to the transmitting part of the BAP entity. This method is illustrated in FIG. Action 1607. The first IAB node 14, in the transmitting portion of the BAP entity, adds the removed BAP header (or a new header identical (i.e., with the same value) as the removed BAP header) to the BAP SDU, thus generating a BAP PDU. Action 1608. The first IAB node 14 transmits the BAP PDU to the next hop third IAB node 15, which may be a new IAB node. Before transmitting the BAP PDU, the transmitting part of the BAP entity may modify only known fields of the BAP PDU, e.g., may modify the destination or path identifier associated with the BAP PDU if required by special circumstances configured by the network. · The third IAB node 15 is able to understand the contents of the BAP PDU because the BAP header is stripped off by the transmitting part of the first IAB node 14 and added back without modification with reserved or unknown values.

[0118] Figure 17 shows an overview of how to process a received BAP PDU if the "old" IAB node involved is not the IAB Access Node of this BAP PDU and is designed according to the second method and actions 1605 and 1606. The IAB node removes the part of the BAP header that it detects as the BAP header, i.e. the first part of the BAP header, and passes both the BAP header and the remaining part of the BAP PDU, i.e. the second part, to the sending part of the BAP entity. Such remaining part may contain one or more "new fields" that the "old" IAB node does not detect as part of the BAP header.

[0119] If the first or second method is used, the second network node 15 does not need to be enhanced since it is capable of receiving and understanding the incoming BAP PDUs sent by the "old" IAB node in the previous hop.

[0120] However, if the "old" IAB node does not employ the disclosed first and second methods, then the third IAB node 15, which transmits the BAP packet to the "old" IAB node, needs to ensure that it transmits the BAP PDU in a way that can be correctly decoded by the old IAB node at the next hop. A third method for handling this scenario is now defined.

[0121] The third method (see FIG. 18) defined for the BAP entity of the second network node 15, which is the third IAB node, ie the “new” IAB node, includes the following:

[0122] The second network node 15 determines in action 1801 whether the next hop IAB node 14 can understand the BAP PDU sent by the second network node 15, i.e. whether the IAB node 14 can set fields in the BAP header that are reserved or unknown to the IAB node 14. In particular, the second network node 15 determines whether the next hop IAB node 14 complies with an earlier release of the specification than the second network node 15. In one way, to perform this action, the IAB donor CU 12 or an Operations, Administration and Maintenance (OAM) node may inform the second network node 15 of the release of the specification that the next-hop IAB node complies with. Alternatively, the IAB donor CU 12 may indicate, for example, using a flag, whether the next-hop IAB node can decode the BAP PDU format defined in the release that the second network node 15 complies with, or whether the next-hop IAB node complies with an earlier or later release. This information is provided by the CU to the second network node 15, e.g. via F1 signaling, e.g. as part of the BH routing table configuration, or as an IAB-MT context setup for the next hop node, or via OAM, so that the second network node 15 can determine whether the IAB node associated with the next hop of the path identifier indicated in the BAP PDU can understand the BAP PDU as defined in the release of the specification to which the third IAB node complies. This therefore essentially implies that the CU provides this information to the second network node 15 in a per-path-ID and per-destination, i.e. per-BAP-Routing-ID, signaling structure, since the next hop that the second network node 15 selects for a given BAP PDU may differ depending on the path and destination of such BAP PDU. Alternatively, one or more reserved fields in the BAP header may be used to indicate the release of the specification to which a particular IAB node complies. For example, if the second network node 15 needs to send an associated BAP PDU downstream to the first IAB node, i.e. if the IAB node 14 is the next-hop node of the second network node 15 in the downstream direction and the IAB node 14 considers the second network node 15 as the next-hop or parent node of some upstream traffic, the second network node 15 will always receive a BAP PDU with no reserved fields set. Thus, the second network node 15 presumes that the IAB node 14 complies with an earlier or later release of the specification. In yet another method, a dedicated BAP control PDU can be exchanged between the parent or second network node 15 and the child or downstream node 14 to indicate a compliant release of the specification. This control PDU can be exchanged after the downstream node has been integrated into the network. The second network node 15 sends a control PDU, and in response the downstream node also sends a control PDU to indicate the release of the specification that it supports, or vice versa.

[0123] Note: In the above, it was used as an example that the second network node 15 knows the "release of the specification" that the next hop IAB node complies with. However, another potential way to address this issue is to have the second network node 15 know if the next hop node supports a certain set of features. This set of features could be the complete set of features that the next IAB node supports, or only a subset of it, e.g. a subset related to a potential field in the BAP header, an indication of the supported release of the specification.

[0124] If it is determined in action 1801 that the next hop IAB node 14 is of an earlier release, the second network node 15 may add a BAP header to the BAP SDU that the IAB node 14 can understand in action 1802 .

[0125] This action may imply removing the BAP header from the BAP PDU received by the second network node 15 if it is determined that the BAP header is not understood by the next-hop IAB node 14. Then adding to the resulting BAP SDU a new BAP header that complies with the release of the next-hop IAB node.

[0126] If a BAP SDU is received from a higher layer, this action simply implies adding a BAP header that the IAB node 14 understands to the BAP SDU.

[0127] A fourth method is defined for an IAB donor CU, such as a radio network node 12, hosting IAB nodes of different releases. If the BAP header has fields that are recognized by all hosted IAB nodes but have been extended, e.g., the number of bits / octets associated with one known field is increased or decreased, the IAB donor CU must configure the IAB nodes such that the space of such known fields is understood by all hosted IAB nodes.

[0128] Consider, for example, the destination and path fields of the BAP header. The destination and path fields are recognized by Rel.16 IAB nodes. The destination and / or path fields may be extended in future releases to accommodate more BAP addresses and traffic paths. Such extensions may not be understood by Rel.16 IAB nodes obviously. If a gNB-CU hosts a mix of Rel.16 and later release IAB nodes, the gNB-CU needs to ensure that the adopted destination / path fields are understood by at least all Rel.16 IAB nodes that handle traffic associated with a particular path to a particular destination. This implies, for example, that the gNB-CU can assign BAP addresses and path identifiers according to the Rel.16 format.

[0129] A fifth method may be defined for an IAB donor CU, such as radio network node 12, to configure an IAB donor DU, such as the first intermediate network node 13. It should be noted that the IAB donor DU 13 adds a BAP header to the packet received from upper layers, and the IAB donor CU 12 adds the appropriate BAP header, i.e., Rel-16 or Rel-17, supported by the destination node, i.e., IAB node 14, to the packet based on the release and / or capabilities supported by the BAP entities of the intermediate IAB nodes through which the packet needs to pass, the QoS requirements / profile of the traffic, etc. For example, for some UE bearer traffic served by IAB access node IAB7, in the scenario shown in Fig. 19, where advanced capabilities supported by the IAB extended BAP header of Rel-17 are required, the IAB donor DU is configured by the IAB donor CU according to the mapping rules, so that the BAP header of Rel-17 is used before routing the packet towards the outgoing link of IAB3. Meanwhile, for other types of UE traffic, e.g., best effort traffic served by IAB access nodes that do not require advanced features and only require routing, the IAB donor DU uses Rel-16 headers for such traffic and forwards the traffic to the outgoing link towards IAB2. Similarly, IAB donor CU12 can route traffic served by access IAB node IAB7 that does not require Rel-17 advanced features but uses Rel-16 BAP headers via the path IAB1-IAB3-IAB-7.

[0130] Below is an example showing how some aspects of the embodiments may be implemented in the BAP specification, 3GPP TS38.340 v16.2.0. Changes compared to the current specification are indicated in bold and underlined text.

[0131] In this modification, an IAB node, such as the first network node 14, that is an intermediate IAB node with respect to a BAP PDU, i.e., that is not an IAB access node, refrains from discarding a packet if the BAP header contains a reserved value or based on receiving a BAP PDU that contains a BAP address that is not included in the configured BH routing configuration and is not the BAP address of this node.

[0132] NOTE: In both implementations below, the else clause may be considered unnecessary since it may be implied that the node processes the BAP PDU if the IAB does not discard it according to the following.

[0133] [Table 1]

[0134] Alternatively, implementations are possible which still result in the IAB node discarding the BAP PDU if the BAP header / routing address is defective.

[0135] [Table 2]

[0136] FIG. 20 is a block diagram illustrating a first network node 14 for handling communications in a wireless communication network 1 according to the present embodiment.

[0137] The first network node 14 may include processing circuitry 2001, such as one or more processors, configured to perform the methods of the present disclosure.

[0138] The first network node 14 may include a receiving unit 2002, for example a receiver or transceiver. The first network node 14, the processing circuit 2001 and / or the receiving unit 2002 may include: BAP address The destination indicated , No.and one or more values ​​that are interpreted as reserved or unknown by the first network node 14. For example, the first network node 14, the processing circuit 2001 and / or the receiving unit 2002 may be configured to receive a data packet having a header (BAP header) from a parent network node or a child network node.

[0139] The first network node 14 may include a determining unit 2003. The first network node 14, the processing circuit 2001 and / or the determining unit 2003 may be configured to check whether the first network node is the intended destination of the data packet based on the destination indicated in the header. The first network node 14, the processing circuit 2001 and / or the determining unit 2003 may be configured to determine or check whether the first network node is the intended destination of the data packet, for example, to determine whether the BAP PDU contains in its BAP header a BAP destination that matches the BAP address of this IAB node.

[0140] The first network node 14 may include a processing unit 2004. The first network node 14, the processing circuit 2001 and / or the processing unit 2004 are configured to discard the data packet on condition that the first network node is not the intended destination of the data packet and the BAP address is not included in the configured BH routing configuration. Otherwise, the first network node 14, the processing circuit 2001 and / or the processing unit 2004 are configured to process the data packet. For example, the first network node 14, the processing circuit 2001 and / or the processing unit 2004 may be configured to process the data packet if the first network node is the intended destination of the data packet or on condition that the BAP address is included in the configured BH routing configuration. Processing the data packet may include sending the data packet to a next hop, second network node, regardless of whether the header contains one or more values ​​that are interpreted as reserved or unknown by the first network node, or removing one or more octets of the header that contain the one or more reserved or invalid values ​​and sending the service data unit to a higher layer.

[0141] The first network node 14, the processing circuit 2001 and / or the processing unit 2004 may be configured to: "If a data packet contains a value in its BAP header that is 'reserved' or 'unknown' to the first network node 14, provided that the first network node 14 is the intended destination of the data packet, then either discard the data packet or, in accordance with a specification to which the first network node complies, remove one or more octets of the data packet that are part of the header from the data packet and deliver the resulting SDU to a higher layer."

[0142] The first network node 14, processing circuit 2001 and / or processing unit 2004 may be configured to transmit the data packet to a second network node 15, such as a next hop third IAB, regardless of whether the header contains one or more values ​​that are "reserved" or "unknown" to the first network node 14, provided that the first network node 14 is not the intended destination of the data packet.

[0143] The first network node 14, the processing circuit 2001 and / or the processing unit 2004 may be configured to store information relating to the fact that the first network node has received packet data including a reserved or unknown value and to report the information to an IAB donor, an OAM node or a higher layer of the first network node 14. The first network node 14 further comprises a memory 2005. The memory 2005 comprises one or more units used to store data such as indications, headers, destination addresses, measurements, thresholds, data related to the node, applications that when executed perform the methods disclosed herein, etc. Furthermore, the first network node 14 may comprise a communication interface 2006 comprising a transmitter, a receiver and / or a transceiver and / or one or more antennas, etc.

[0144] The methods according to the embodiments described herein for the first network node 14 are realized by means of a computer program product 2007 or computer program including instructions, i.e. software code portions, which when executed on at least one processor cause the at least one processor to perform the actions described herein to be performed by the first network node 14, respectively. The computer program product 2007 may be stored on a computer readable storage medium 2008, e.g., a disk, a Universal Serial Bus (USB) stick, etc. The computer readable storage medium 2008 having the computer program product stored thereon may include instructions which when executed on at least one processor cause the at least one processor to perform the actions described herein to be performed by the first network node. In some embodiments, the computer readable storage medium may be a non-transitory or a transitory computer readable storage medium. Thus, embodiments herein disclose a first network node for processing communications in a wireless communication network, the first network node comprising a processing circuit and a memory, the memory comprising instructions executable by the processing circuit, whereby the first network node is operative to perform any of the methods described herein.

[0145] FIG. 21 is a block diagram illustrating a second network node 15, such as an IAB node, supporting a later release than the first network node 14, for processing communications in a wireless communication network 1 according to the present embodiment.

[0146] The second network node 15 may include processing circuitry 2101, such as one or more processors, configured to perform the methods of the present disclosure.

[0147] The second network node 15 may include a receiving unit 2102, e.g. a receiver or transceiver. The second network node 15, the processing circuitry 2101 and / or the receiving unit 2102 may be configured to receive an indication from another network node or a control network node, such as the first network node 12 or an OAM node, of a release of a specification to which the other next hop network node complies.

[0148] The second network node 15 may include a determining unit 2103. The second network node 15, the processing circuit 2101 and / or the determining unit 2103 are configured to determine whether another network node complies with a release of the specification to which the second network node complies.

[0149] The second network node 15 may include a processing unit 2104. The second network node 15, processing circuitry 2101 and / or processing unit 2104 may be configured to process data packets destined for the other network node based on a determination of whether the other network node complies with the release of the specification to which the second network node complies, e.g., apply a header to the SDU to which the next-hop network node complies.

[0150] The second network node 15 may further include a memory 2105. The memory 2105 includes one or more units used to store data such as indications, contexts, release compliance, measurements, thresholds, data related to the node, applications that when executed perform the methods disclosed herein, etc. Furthermore, the second network node 15 may include a communication interface 2108 comprising a transmitter, a receiver, and / or a transceiver, and / or one or more antennas, etc.

[0151] The methods according to the embodiments described herein for the second network node 15 are realized by means of a computer program product 2106 or computer program comprising instructions, i.e. software code portions, which, when executed on at least one processor, cause the at least one processor to perform the actions described herein to be performed by the second network node 15, respectively. The computer program product 2106 may be stored on a computer readable storage medium 2107, e.g. a disk, a Universal Serial Bus (USB) stick, etc. The computer readable storage medium 2107 having the computer program product stored thereon may include instructions, which, when executed on at least one processor, cause the at least one processor to perform the actions described herein to be performed by the second network node 15. In some embodiments, the computer readable storage medium may be a non-transitory or a transitory computer readable storage medium. Thus, the embodiments herein may disclose a second network node 15 for processing communications in a wireless communication network. The second network node comprises a processing circuit and a memory, the memory comprising instructions executable by the processing circuit and thereby operative to perform any of the methods described herein.

[0152] FIG. 22 is a block diagram illustrating a control network node, such as an IAB donor 12 or an OAM node, for handling communications within a wireless communication network 1 according to the present embodiment.

[0153] The control network node may include processing circuitry 2201, such as one or more processors, configured to perform the methods of the present disclosure.

[0154] The control network node may include a receiving unit 2202, e.g., a receiver or transceiver. The control network node, the processing circuitry 2201 and / or the receiving unit 2202 may be configured to receive an indication of release compliance of one or more network nodes hosted by the control network node from another network node or a control network node, such as the first network node 12 or an OAM node.

[0155] The control network node may include a configuration unit 2203. The control network node, processing circuitry 2201 and / or configuration unit 2203 are configured to configure the IAB nodes such that all hosted IAB nodes understand the space of known fields, e.g., assign BAP addresses and path identifiers according to one and the same format.

[0156] The control network node may further include a memory 2204. The memory 2204 includes one or more units used to store data such as indications, context, release compliance, measurements, thresholds, data related to the node, applications that when executed perform the methods disclosed herein, etc. Furthermore, the control network node may include a communication interface 2205 comprising a transmitter, a receiver, and / or a transceiver, and / or one or more antennas, etc.

[0157] The methods according to the embodiments described herein for a control network node are realized by means of a computer program product 2206 or computer program, respectively, including e.g. instructions, i.e. software code portions, which when executed on at least one processor cause the at least one processor to perform the actions described herein performed by the control network node. The computer program product 2206 may be stored on a computer readable storage medium 2207, e.g. a disk, a Universal Serial Bus (USB) stick, etc. The computer readable storage medium 2207 having the computer program product stored thereon may include instructions that when executed on at least one processor cause the at least one processor to perform the actions described herein performed by the control network node. In some embodiments, the computer readable storage medium may be a non-transitory or a transitory computer readable storage medium. Thus, embodiments herein may disclose a control network node for processing communications in a wireless communication network. The control network node comprises a processing circuit and a memory, the memory comprising instructions executable by the processing circuit and thereby operating to perform any of the methods described herein.

[0158] In some embodiments, the more general term "network node" is used, which corresponds to any type of wireless network node or any type of network node that communicates with wireless devices and / or other network nodes. Examples of network nodes include a NodeB, a MeNB, a SeNB, a network node belonging to a Master Cell Group (MCG) or a Secondary Cell Group (SCG), a base station (BS), a multi-standard radio (MSR) radio node such as an MSR BS, an eNodeB, a gNodeB, a network controller, a radio network controller (RNC), a base station controller (BSC), a relay, a donor node controlling relay, a base transceiver station (BTS), an access point (AP), a transmission point, a transmitting node, a remote radio unit (RRU), a remote radio head (RRH), a node of a distributed antenna system (DAS), etc.

[0159] In some embodiments, the non-limiting terms wireless device or user equipment (UE) are used to refer to any type of wireless device that communicates with network nodes and / or other wireless devices in a cellular or mobile communication system. Examples of UEs are a device capable device, a target device, a device-to-device (D2D) UE, a proximity capable UE (ProSe UE), a machine type UE or a UE capable of machine-to-machine (M2M) communications, a PDA, a PAD, a tablet, a mobile terminal, a smartphone, a laptop embedded equipped (LEE), a laptop implemented equipment (LME), a USB dongle, etc.

[0160] The embodiments are applicable to any RAT or multi-RAT system in which wireless devices receive and / or transmit signals (e.g., data), such as New Radio (NR), Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile Communications / Enhanced Data Rates for GSM Evolution (GSM / EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), to mention a few possible implementations.

[0161] As will be readily appreciated by those familiar with communications design, the functional means or circuits may be implemented using digital logic and / or one or more microcontrollers, microprocessors, or other digital hardware. In some embodiments, some, all, or various functions may be implemented in a single Application Specific Integrated Circuit (ASIC), or in two or more separate devices with appropriate hardware and / or software interfaces therebetween. Some of the functions may be implemented, for example, in a processor shared with other functional components of a wireless device or network node.

[0162] Alternatively, some of the functional elements of the processing means may be provided via discrete hardware, while other functional elements may be provided in hardware that executes software in association with appropriate software or firmware. As such, the terms "processor" or "controller" as used herein do not refer solely to hardware capable of executing software, but may implicitly include digital signal processor (DSP) hardware and / or programs or application data. Other hardware, conventional and / or custom hardware may also be included. Designers of communications devices understand the cost, performance, and maintenance tradeoffs inherent in these design choices.

[0163] Figure 23 illustrates a communication network connected to a host computer via an intermediate network, according to some embodiments. Referring to Figure 23 according to one embodiment, the communication system includes a communication network 3210, such as a 3GPP type cellular network, which includes an access network 3211, such as a radio access network, and a core network 3214. The access network 3211 includes a number of base stations 3212a, 3212b, 3212c, such as NBs, eNBs, gNBs, or other types of wireless access points, which are examples of the radio network nodes 12 described above, each of which defines a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c can be connected to the core network 3214 via a wired or wireless connection 3215. A first UE 2691 located in the coverage area 3213c is configured to wirelessly connect to or be paged by the corresponding base station 3212c. A second UE 3292 in the coverage area 3213a can wirelessly connect to a corresponding base station 3212a. Although multiple UEs 3291, 3292 are shown in this example as examples of the wireless device 10, the disclosed embodiments are equally applicable to situations where a single UE is in the coverage area or connected to a corresponding base station 3212.

[0164] The communication network 3210 is itself connected to a host computer 3230, which may be embodied by hardware and / or software of a standalone server, a cloud-implemented server, a distributed server, or as a processing resource of a server farm. The host computer 3230 may be under the ownership or control of a service provider, or may be operated by or on behalf of the service provider. The connection 3221, 3222 between the communication network 3210 and the host computer 3230 may extend directly from the core network 3214 to the host computer 3230, or may go through an optional intermediate network 3220. The intermediate network 3220 may be one or a combination of two or more of a public, private, or hosted network, and the intermediate network 3220 (if present) may be a backbone network or the Internet, and in particular the intermediate network 3220 may comprise two or more sub-networks (not shown).

[0165] The communication system of FIG. 23 as a whole enables connectivity between connected UEs 3291, 3292 and a host computer 3230. The connectivity may be described as an over-the-top (OTT) connection 3250. The host computer 3230 and connected UEs 3291, 3292 are configured to communicate data and / or signaling via the OTT connection 3250 using the access network 3211, the core network 3214, any intermediate networks 3220, and possible further infrastructure (not shown) as intermediaries. The OTT connection 3250 may be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of the routing of the uplink and downlink communications. For example, the base station 3212 is not, or does not need to be, informed of the past routing of incoming downlink communications with data originating from the host computer 3230 being forwarded (e.g., handed over) to the connected UE 3291. Similarly, the base station 3212 does not need to be aware of the future routing of outgoing uplink communications from the UE 3291 towards the host computer 3230.

[0166] FIG. 24 illustrates an example of a host computer communicating with a user device via a base station over a partially wireless connection, according to some embodiments.

[0167] An exemplary implementation of the UE, base station, and host computer described in the preceding paragraphs according to one embodiment is described with reference to FIG. 24. In the communication system 3300, the host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to set up and maintain wired or wireless connections with interfaces of different communication devices of the communication system 3300. The host computer 3310 further comprises a processing circuit 3318 that may have memory and / or processing capabilities. In particular, the processing circuit 3318 may comprise one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The host computer 3310 further comprises software 3311 executable by the processing circuit 3318, the software 3311 being stored in or accessible by the host computer 3310. The software 3311 includes a host application 3312. The host application 3312 may be operable to provide services to a remote user, such as the UE 3330, that connects with the UE 3330 via an OTT connection 3350 terminated at the host computer 3310. In providing services to the remote user, the host application 3312 may provide user data that is transmitted using the OTT connection 3350.

[0168] The communication system 3300 further includes a base station 3320 provided in the communication system and equipped with hardware 3325 enabling communication with the host computer 3310 and the UE 3330. The hardware 3325 may include a communication interface 3326 for setting up and maintaining wired or wireless connections with interfaces of different communication devices of the communication system 3300, and a wireless interface 3327 for setting up and maintaining at least a wireless connection 3370 with the UE 3330 in a coverage area (not shown in FIG. 24) served by the base station 3320. The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct or may pass through a core network (not shown in FIG. 24) of the communication system and / or one or more intermediate networks external to the communication system. In the illustrated embodiment, the hardware 3325 of the base station 3320 further comprises processing circuitry 3328, which may comprise one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The base station 3320 further comprises software 3321 stored therein or accessible via an external connection.

[0169] The communication system 3300 further includes the UE 3330 already mentioned. Its hardware 3333 may include a wireless interface 3337 configured to set up and maintain a wireless connection 3370 with a base station serving the coverage area in which the UE 3330 is currently located. The hardware 3333 of the UE 3330 further includes a processing circuit 3338, which may comprise one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The UE 3330 further includes software 3331 executable by the processing circuit 3338, the software 3331 being stored in or accessible by the UE 3330. The software 3331 includes a client application 3332. The client application 3332 may be operable to provide services to a human or non-human user via the UE 3330 with the support of the host computer 3310. In the host computer 3310, a running host application 3312 can communicate with a running client application 3332 via an OTT connection 3350 that terminates at the UE 3330 and the host computer 3310. In providing a service to a user, the client application 3332 can receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 can transfer both the request data and the user data. The client application 3332 can interact with the user and generate user data to provide.

[0170] It should be noted that the host computer 3310, base station 3320 and UE 3330 shown in Figure 24 may be similar or identical to the host computer 3230, one of the base stations 3212a, 3212b, 3212c and one of the UEs 3291, 3292 in Figure 23, respectively. That is, the internal operation of these entities will be as in Figure 24 and, independently, the surrounding network topology will be as in Figure 23.

[0171] 24, the OTT connection 3350 is depicted abstractly to show communication between the host computer 3310 and the UE 3330 via the base station 3320, without showing intermediate devices or the exact routing of messages through these devices. The network infrastructure may determine the routing, which may be configured to be hidden from the service provider operating the UE 3330 or the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure may further decide to dynamically change the routing (e.g., based on network load balancing considerations or reconfiguration).

[0172] The wireless connection 3370 between the UE 3330 and the base station 3320 follows the teachings of the embodiments described throughout this disclosure. One or more various embodiments improve the performance of the OTT service provided to the UE 3330 using the OTT connection 3350 of which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments enable data packets of different release versions of the specification to be handled or managed in an efficient manner, resulting in reduced latency and faster responsiveness of packet transmission.

[0173] Measurement procedures may be provided for the purpose of monitoring data rates, latencies, and other factors for which one or more embodiments may be improved. Additionally, there may be optional network functionality to reconfigure the OTT connection 3350 between the host computer 3310 and the UE 3330 in response to variations in the measurement results. The measurement procedures and / or network functionality to reconfigure the OTT connection 3350 may be implemented in the software 3311 and hardware 3315 of the host computer 3310, the software 3331 and hardware 3333 of the UE 3330, or both. In an embodiment, sensors (not shown) are located in or associated with the communication devices through which the OTT connection 3350 passes, and the sensors may participate in the measurement procedures by providing values ​​of the monitored quantities exemplified above, or by providing values ​​of other physical quantities from which the software 3311, 3331 may calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 3350 may include message formats, retransmission settings, priority routing, etc., where the reconfiguration does not impact the base station 3320 and may be unknown or imperceptible to the base station 3320. Such procedures and functions may be known and practiced in the art. In certain embodiments, the measurements may include proprietary UE signaling to facilitate host computer 3310 measurements of throughput, propagation time, delay, etc. The measurements may be implemented such that software 3311, 3331 uses the OTT connection 3350 to send messages, particularly null or "dummy" messages, while monitoring propagation times, errors, etc.

[0174] FIG. 25 illustrates an example of a method performed in a communications system including a host computer, a base station, and a user equipment, according to some embodiments.

[0175] FIG. 25 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to FIGS. 23 and 24. To simplify the disclosure, only references to FIG. 25 are included in this section. In step 3410, the host computer provides user data. In sub-step 3411 of step 3410 (which may be optional), the host computer provides the user data by executing a host application. In step 3420, the host computer initiates a transmission carrying the user data to the UE. In step 3430 (which may be optional), the base station transmits the user data carried in the host computer initiated transmission to the UE according to the teachings of the embodiments described throughout this disclosure. In step 3440 (which may be optional), the UE executes a client application associated with the host application executed by the host computer.

[0176] FIG. 26 illustrates an example of a method performed in a communications system including a host computer, a base station, and a user equipment, according to some embodiments.

[0177] FIG. 26 is a flow chart illustrating a method implemented in a communication system, according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to FIGS. 23 and 24. To simplify the disclosure, only the reference drawing to FIG. 26 is included in this section. In step 3510 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides the user data by executing a host application. In step 3520, the host computer initiates a transmission carrying the user data to the UE. In accordance with the teachings of the embodiments described throughout this disclosure, the transmission may pass through the base station. In step 3530 (which may be optional), the UE receives the user data carried in the transmission.

[0178] FIG. 27 illustrates an example of a method performed in a communications system including a host computer, a base station, and a user equipment, according to some embodiments.

[0179] FIG. 27 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to FIGS. 23 and 24. To simplify the disclosure, only references to FIG. 27 are included in this section. In step 3610 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 3620, the UE provides user data. In sub-step 3621 (which may be optional) of step 3620, the UE provides the user data by executing a client application. In sub-step 3611 (which may be optional) of step 3610, the UE executes a client application that provides user data in response to the received input data provided by the host computer. In providing the user data, the executed client application may further take into account user input received from the user. Regardless of the particular manner in which the user data was provided, the UE begins transmitting the user data to the host computer in sub-step 3630 (which may be optional). In method step 3640, the host computer receives user data transmitted from the UE in accordance with the teachings of the embodiments described throughout this disclosure.

[0180] FIG. 28 illustrates an example of a method performed in a communications system including a host computer, a base station, and a user equipment, according to some embodiments.

[0181] FIG. 28 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to FIGS. 23 and 24. To simplify the disclosure, only references to FIG. 28 are included in this section. In step 3710 (which may be optional), the base station receives user data from the UE in accordance with the teachings of the embodiments described throughout this disclosure. In step 3720 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step 3730 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

[0182] Any suitable steps, methods, features, functions, or advantages disclosed herein may be performed through one or more functional units or modules of one or more virtual devices. Each virtual device may include several of these functional units. These functional units may include processing circuitry, which may include one or more microprocessors or microcontrollers, and other digital hardware, which may include digital signal processors (DSPs), dedicated digital logic, and the like. The processing circuitry is configured to execute program code stored in memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, and the like. The program code stored in memory includes program instructions for implementing one or more communication and / or data communication protocols and, in some embodiments, program instructions for implementing one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause each functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0183] Modifications of the disclosed embodiments and other embodiments will come to mind to those skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. It is to be understood, therefore, that the embodiments are not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the present disclosure. Although specific terms have been used, they are of generic and descriptive nature and not of limitation.

[0184] Abbreviation:Description ACK (Acknowledgement) AUL Autonomous Uplink BLER Block Error Rate BWP Bandwidth Part CAPC Channel Access Priority Class CBG Code Block Group CCA Clear Channel Rating CO Channel Occupancy COT Channel Occupancy Time CWS Contention Window Size DL Downlink ED Energy Detection eNB 4G base station gNB 5G base station HARQ Hybrid Automatic Repeat Request IS syncing LAA Licensed Assisted Access LBT Listen Before Talk MAC Media Access Control MCOT Maximum Channel Occupancy Time NACK Negative Acknowledgement NDI New Data Indicator NR 3GPP defined 5G radio access technology NR-U NR Unlicensed OOS Out of Sync PCell Primary Cell PCI Physical Cell Identifier PDCCH Downlink Control Channel PDU Protocol Data Unit PHICH Physical Channel Hybrid ARQ Indicator Channel PLMN Public Land Mobile Network PSCell Primary SCG cell PUCCH Physical Uplink Control Channel PUSCH Physical uplink shared channel QCI QoS Class Identifier QoS Quality of Service RAT Radio Access Technology RLF Radio Link Failure RLM Radio Link Monitoring RLC Radio Link Control RRC Radio Resource Control RS reference signal SCG Secondary Cell Group SDU Service Data Unit SMTC SSB-based measurement timing configuration SpCell Special Cell (PCell or PSCell) SPS Semi-persistent Scheduling TTI Transmission Time Interval UCI Uplink Control Information UE User Equipment UL Uplink

Claims

1. A method performed by a first network node (14) for processing communications in a wireless communication network, comprising: Receiving (1101) a data packet having a header including a destination indicated by a Backhaul Adaptation Protocol (BAP) address and one or more values ​​that are interpreted as reserved or unknown by said first network node (14); checking (1102) whether the first network node (14) is the intended destination of the data packet based on the destination of the header; discarding (1103) the data packet if the first network node (14) is not the intended destination of the data packet and the BAP address is not included in a configured backhaul (BH) routing configuration; otherwise, processing (1104) said data packet; The method includes:

2. 2. The method of claim 1 , The method of claim 1, wherein the first network node (14) is an Integrated Access Backhaul (IAB) node.

3. 3. The method according to claim 1 or 2, Processing 1104 the data packets includes: sending the data packet to a next hop second network node (15) regardless of whether the header contains the one or more values ​​that are interpreted as reserved or unknown by the first network node (14), or removing one or more octets of the header that contain the one or more reserved or unknown values ​​and sending the service data unit to a higher layer.

4. The method according to any one of claims 1 to 3, further comprising: storing (1105) information relating to the fact that said first network node (14) has received packet data containing a reserved or unknown value; reporting said information to one of an IAB donor, an Operations, Administration and Maintenance (OAM) node, and an upper layer of said first network node (14); The method includes:

5. A first network node (14) for handling communications in a wireless communication network, comprising: receiving a data packet having a header including a destination indicated by a Backhaul Adaptation Protocol (BAP) address and one or more values ​​that are interpreted by the first network node (14) as reserved or unknown; checking whether the first network node (14) is the intended destination of the data packet based on the destination of the header; if the first network node (14) is not the intended destination of the data packet and the BAP address is not included in a configured backhaul (BH) routing configuration, discarding the data packet, and otherwise processing the data packet; A first network node configured to:

6. A first network node according to claim 5, comprising: The first network node (14) is an integrated access backhaul (IAB) node.

7. A first network node according to claim 5 or 6, The first network node (14) is configured to process the data packet by sending the data packet to a next-hop second network node, regardless of whether the header contains one or more values ​​that are interpreted as reserved or unknown by the first network node (14), or by removing one or more octets of the header that contain the one or more reserved or unknown values ​​and sending a service data unit to a higher layer.

8. A first network node according to any one of claims 5 to 7, The first network node (14) is configured to store information relating to the fact that the first network node has received packet data containing a reserved or unknown value, and to report the information to an IAB donor, an OAM node, or a higher layer of the first network node (14).

9. A computer program comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method of any one of claims 1 to 4 executed on the first network node.

10. 5. A computer-readable storage medium having stored thereon a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to perform the method of any one of claims 1 to 4 executed on the first network node.

Images