Control used simultaneously in the integrated access backhaul network radio link
By operating the BAP sublayer at the IAB node and using multiple RLC channels to transmit or replicate BAP packets, the problem of processing load and bandwidth waste in the IAB network is solved, achieving more efficient link diversity and robust control.
Patent Information
- Application Number
- CN202180072341.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2020-10-23
- Filing Date
- 2021-10-20
- Publication Date
- 2025-10-31
- Estimated Expiration
- 2041-10-20
AI Technical Summary
The existing PDCP replication mechanism results in high processing loads at transmitters and receivers in IAB networks, especially IAB donors, and may waste backhaul network bandwidth. It also fails to effectively address radio link failures, especially under low-quality link conditions.
At the IAB node, multiple RLC channels are selected for BAP packet transmission or replication through BAP sublayer operations. The IAB node is configured as the initiator or terminator to achieve link diversity, reduce processing load and bandwidth waste.
Effectively distributing the processing load reduces packet duplication on low-quality links in the IAB network, improves network robustness, and avoids unnecessary processing and bandwidth consumption.
Smart Images

Figure CN116569534B_ABST
Abstract
Description
Technical Field
[0001] This invention generally relates to wireless communication, and more particularly to wireless communication in Integrated Access Backhauled (IAB) networks. Background Technology
[0002] Wireless communication systems are widely deployed to address a wide range of applications, from mobile broadband and massive machine-type communications to ultra-reliable low-latency communication (URLLC). Such systems allow multiple user equipment (UEs) or mobile terminals to share a wireless medium to exchange various types of data content (e.g., video, voice, messages) over a radio access network (RAN) via one or more base stations. Traditionally, base stations (e.g., via fiber optic cables) are wired to the core network, forming an intermediate network known as the backhaul (BH).
[0003] Examples of such wireless multiple access communication systems include systems based on the 3rd Generation Partnership Project (3GPP) standards, such as fourth-generation (4G) Long Term Evolution (LTE) or the more recent fifth-generation (5G) New Radio (NR) systems, or systems based on the IEEE 802.11 standard, such as WiFi.
[0004] The need for network densification is increasing due to the growing number of users and higher throughput requirements.
[0005] To address the high deployment costs and time associated with wired backhaul networks, 3GPP has proposed wireless backhaul, also known as Integrated Access Backhaul (IAB), in its latest release 16 for 5G NR. In this approach, instead of fiber optics, a portion of the radio spectrum is used for backhaul connections at base stations. Consequently, wireless backhaul communication (between base stations) utilizes the same radio resources as access communication (between base stations and UEs).
[0006] IAB has proven to be a competing alternative to fiber-based backhaul in densely populated or hard-to-cover areas because it allows for scalable and rapid installation without the burden of cabling to base stations.
[0007] The IAB is most likely to operate in the millimeter-wave (mmWave) band to achieve the required Gbps (gigabits per second) data rate.
[0008] However, millimeter waves are known to experience strong signal attenuation under certain weather conditions (rain, fog) and to be blocked when obstacles are located in the path between the transmitter and receiver.
[0009] To address these potential radio link failures, topology redundancy can be provided within the IAB framework, establishing multiple data paths between IAB base stations directly connected to the core network (also known as "IAB donors") and IAB base stations serving the UE (also known as "access IAB nodes"). Several intermediate IAB base stations (also known as IAB nodes) can be involved in each of the paths between the IAB donor and the access IAB node, thus forming alternative data paths within a multi-hop IAB network.
[0010] A default path is defined through the set of IAB nodes, along which data is preferably transmitted. Additionally, one or more backup paths are defined along different sets of IAB nodes, which can be used in case of a radio link failure (RLF) on any link of the default path. Links are defined between two consecutive IAB nodes in the backhaul network.
[0011] Another mechanism that provides robustness to data transmission in the event of radio link failures includes the PDCP (Packet Data Convergence Protocol) replication mechanism (as described in 3GPP specification document TS 38.323 (V16.1.0)). Compared to alternative robustness mechanisms such as on-demand retransmission (where each hop adds a delay for requesting a retransmission), the system replication mechanism advantageously reduces latency.
[0012] PDCP replication involves transmitting replicated PDCP packets on two or more different carrier frequencies via a single base station (called carrier aggregation replication) or via different base stations (called dual-connection / multi-connection replication) to increase diversity.
[0013] The IAB is transparent to the PDCP protocol: IAB nodes do not have a PDCP sublayer in the user plane. Therefore, PDCP replication is end-to-end, i.e., between the UE and the IAB provider connected to the network core. Various intermediate IAB nodes (if present) therefore do not interact with the PDCP replication mechanism.
[0014] The robustness mechanism based on PDCP is not satisfactory.
[0015] First, the mechanism is concentrated at the transmitter and receiver (i.e., at the IAB donor and the UE) and results in a high processing load at the transmitter and receiver.
[0016] Specifically, regarding the IAB provider, because it is the only IAB node connected to the core network, it handles all data streams from all UEs attached to the IAB network. As a result, if PDCP replication is enabled, the IAB provider faces an excessive load of processing a large number of packets, particularly in downlink replication and uplink copy removal.
[0017] For UEs experiencing a good-quality link with an IAB node, enabling PDCP replication (due to a low-quality link in the IAB network) requires the UE to perform unnecessary processing. This additional processing load can be detrimental to UEs with low resources.
[0018] Secondly, this mechanism can significantly waste backhaul network bandwidth. In fact, PDCP replication (enabled due to low-quality links) involves transmitting replicated packets on multiple links between the IAB donor and the UE (including those between IAB nodes with good transmission quality).
[0019] More generally, we need more efficient and fairer robust mechanisms. Summary of the Invention
[0020] This invention proposes a communication method in a wireless network, the wireless network including an Integrated Access and Backhaul (IAB) network, the method comprising: at an IAB node,
[0021] Receive BAP packets with the same Backhaul Adaptation Protocol (BAP) routing identifier. In this invention, a BAP packet refers to a BAP data packet that can carry user plane or control plane data;
[0022] BAP routing configuration is used to perform BAP sublayer operations, which, for the same BAP routing identifier, determine multiple Radio Link Control (RLC) channels belonging to one or more egress links for the received BAP packets, and
[0023] BAP packets are transmitted through the multiple RLC channels.
[0024] This type of IAB node is called an initiator.
[0025] Depending on the operation initiated by the IAB node, an IAB node that relays Backhaul Adaptation Protocol (BAP) packets in an Integrated Access and Backhaul (IAB) network can be configured as the initiator of BAP packet replication at the BAP sublayer, or the initiator of BAP packet network encoding at the BAP sublayer, or the initiator of splitting BAP packet streams on multiple egress links at the BAP sublayer.
[0026] Therefore, the present invention also proposes a communication method in a wireless network, the wireless network including an Integrated Access and Backhaul (IAB) network, the method comprising: at an IAB node,
[0027] Receive Backhaul Adaptation Protocol (BAP) packets that are redundant with the original BAP packets through one or more ingress links.
[0028] BAP sublayer operations are performed using BAP routing configuration, wherein the BAP sublayer operations determine whether to terminate BAP packet redundancy at the IAB node, and
[0029] In cases where certainty is certain, redundant BAP packets are processed to obtain the original BAP packet, and a single original BAP packet is transmitted via the egress link, or its contents (of the original BAP packet) are transmitted to the upper layer of the IAB node.
[0030] This type of IAB node is called a terminator.
[0031] Depending on the termination operation of the IAB node, an IAB node in the Integrated Access and Backhaul (IAB) network that relays Backhaul Adaptation Protocol (BAP) packets can be configured as the terminator of BAP packet replication at the BAP sublayer or the terminator of BAP packet network encoding at the BAP sublayer.
[0032] The above method defines link-based robust control, which uses the diversity of links or channels in the IAB network at the IAB node level.
[0033] The first IAB node (the initiator of BAP sublayer operations) uses such diversity transmission of BAP packets, for example, by replicating BAP packets due to low-quality egress links. This first part of the operation in the IAB network advantageously distributes the processing load across multiple IAB nodes with low-quality links rather than across a single UE and IAB provider.
[0034] A second IAB node in the IAB network (the terminator of BAP sublayer operations) can terminate the use of link diversity, for example, after a low-quality link, by discarding a copy of the same original BAP packet. This second part of the operation advantageously limits packet duplication within the sub-section of the IAB network (preferably, where the BH link between IAB nodes has low quality). Thus, no bandwidth is wasted for the portion of the IAB network that transmits the original BAP packet without a copy of the original BAP packet.
[0035] In other words, the additional processing and bandwidth consumption are now concentrated on the portion of the IAB network that truly requires additional mechanisms to withstand radio link failures. The appropriate selection of the first and second IAB nodes allows for the limitation of this portion.
[0036] Of course, the same mechanism can be implemented simultaneously in various parts of the IAB network (e.g., for different packet flows and different low-quality BH links).
[0037] These IAB nodes can be configured by the IAB provider CU of the IAB network. In this regard, the Integrated Access and Backhaul Provider Central Unit (IAB CU) of the IAB network can be designed to send configuration messages to configure the IAB nodes of the IAB network with corresponding Backhaul Adaptation Protocol (BAP) routing configurations. One BAP routing configuration sets an IAB node as the initiator of a BAP sublayer operation, which transmits received BAP packets with the same BAP routing identifier through multiple Radio Link Control (RLC) channels belonging to one or more egress links. Another BAP routing configuration sets another IAB node as the terminator of the same BAP sublayer operation, processing received redundant BAP packets into original BAP packets and transmitting a single original BAP packet through the egress link or transmitting its contents to the upper layer of the IAB node.
[0038] Relatedly, the present invention also provides a wireless communication device comprising at least one microprocessor configured to perform the steps of any of the methods described above.
[0039] Optional features of embodiments of the present invention are defined in the appended claims. Some of these features are described herein with reference to methods, and these features can be converted into apparatus features.
[0040] In some embodiments, transmitting BAP packets includes: obtaining BAP packets redundant to the received BAP packets, and transmitting the redundant BAP packets through multiple RLC channels. This defines a useful redundancy-based processing approach, given that it provides more network robustness only at a sub-segment of the network.
[0041] In some embodiments, redundant BAP packets include the received BAP packet and one or more copies thereof. This means that the IAB node acts as the initiator of the replication mechanism associated with the terminating IAB node.
[0042] In a particular embodiment, the method further includes adding the same sequence number to the received BAP packet and its copies. This addition annotates or marks each replicated BAP packet and allows the terminating IAB node to easily identify these packets where the BAP sublayer replication mechanism should end.
[0043] In a particular embodiment, when the received BAP packet already includes a sequence number, the received BAP packet and its copy retain the sequence number without adding any additional sequence numbers. This can occur, for example, when a copy operation is nested within another redundancy-based operation on the BAP packet.
[0044] In some embodiments, obtaining redundant BAP packets includes network coding of the received BAP packets. Network coding may be performed using only the received BAP packet (i.e., for the segments from which the BAP packet is segmented), or using one or more other received BAP packets (which are thus combined). The IAB node then acts as the initiator of the network coding mechanism, again associating with the terminating IAB node.
[0045] In a particular embodiment, redundant BAP packets resulting from network encoding of the same received BAP packet are marked with consecutive sequence numbers. This again annotates or marks the generated BAP packets to allow the terminating IAB node to easily identify these packets where the BAP sublayer network encoding mechanism should end.
[0046] In some embodiments, serial numbers are added to redundant BAP packets, and each serial number has the following format:
[0047] K units digit; and
[0048] An additional counter bit incremented when processing (copying or network encoding) a newly received BAP packet to obtain a redundant BAP packet.
[0049] Specifically, when the processing of the received BAP packet to obtain a redundant BAP packet is redundant processing, the k bits are set to the same value; and when the processing is network coding, the k bits are set to uniquely identify each redundant BAP packet.
[0050] Therefore, the same SN format can be used for the proposed redundant BAP sublayer operations (if these operations are implemented simultaneously in the same IAB network).
[0051] In some embodiments, the method further includes determining, based on the BAP routing configuration, whether a sequence number must be added to a redundant BAP packet compared to a received BAP packet. Therefore, SNs can be added unsystematically through IAB node configuration.
[0052] From the perspective of the terminator, embodiments related to the replication operation provide that handling redundant BAP packets includes identifying a copy of the original BAP packet and discarding the copy to maintain a single copy as a single original BAP packet.
[0053] In this case, determining the copy may include: identifying received BAP packets marked with the same sequence number.
[0054] Embodiments related to network encoding operations are provided, in which processing redundant BAP packets includes network decoding of the redundant BAP packets to obtain the original BAP packets.
[0055] In this case, receiving redundant BAP packets may include: identifying received BAP packets marked with sequence numbers that are separated by a number of combinations defined by the network decoding.
[0056] In some embodiments, the method further includes: determining, based on the BAP routing configuration, whether the sequence number must be removed from the original BAP packet compared to the received redundant BAP packet.
[0057] In addition to copying and network encoding operations, embodiments may provide that transmitting BAP packets includes segmenting the stream of received BAP packets into multiple sub-streams, and transmitting each sub-stream of BAP packets through multiple RLC channels. Thus, the "segmentation" operation provides a balance in the use of the BH link.
[0058] In some embodiments of the present invention, multiple RLC channels belong to multiple egress links. In a variant, multiple RLC channels belong to the same egress link. In another variant, the multiple RLC channels include RLC channels belonging to the same egress link and one RLC channel belonging to a separate egress link.
[0059] In a particular embodiment, the BAP routing identifier includes the BAP address and path identifier of the destination IAB node.
[0060] In some embodiments of the invention, BAP routing configuration is received from the IAB donor central unit (CU) of the IAB network. Therefore, the decision regarding which IAB nodes are the initiators or terminators of certain BAP sublayer operations is centralized at the IAB donor CU.
[0061] In some embodiments, BAP routing configuration is received via a BAP configuration message of one of the following message types: such as the BAP mapping configuration message, the UE context setting request message, and the UE context modification request message as defined in 3GPP TS 38.473, v16.2.0.
[0062] Regarding the configuration itself, some embodiments are provided at the initiator's location. The BAP routing configuration includes a first configuration table consisting of entries, each entry associating a BAP routing identifier with a BAP address of another IAB node. The entries corresponding to the BAP routing identifiers of received BAP packets are further defined as follows:
[0063] The BAP sub-layer operations required to generate at least two packet sub-streams from the received BAP packets; and
[0064] A list of routing entries used to determine the route through which each packet stream is transmitted, via one or more outgoing links.
[0065] Therefore, the IAB donor CU can clearly declare which IAB node will act as the initiator through the BAP configuration table.
[0066] In some embodiments associated with this table, the list of routing entries includes a list of BAP routing identifiers. In variants, the list of routing entries includes a list of BAP addresses of other IAB nodes. In some embodiments, each routing entry in the list corresponds to a specific packet stream and defines an egress link for transmitting that specific packet stream.
[0067] Regarding the configuration itself, some embodiments provide at the terminating point that the BAP routing configuration includes a first configuration table consisting of entries that associate a BAP routing identifier with a BAP address of another IAB node. The entry corresponding to one or more BAP routing identifiers of a received BAP packet is further defined as a BAP sublayer operation to be performed in order to obtain the original BAP packet from the received redundant BAP packet.
[0068] In some embodiments, the first configuration table may include a first enhancement table derived from a backhaul routing configuration table as defined in 3GPP TS 38.300, V16.2.0, Section 6.11.3.
[0069] In some embodiments, the BAP routing configuration includes a second configuration table consisting of entries that associate an egress link with one or more RLC channels.
[0070] An entry corresponding to a determined egress link can be associated with multiple RLC channels.
[0071] The entry may further include a trigger field that defines one or more BAP route identifiers for which multiple RLC channels are to be used.
[0072] The default RLC channel among multiple RLC channels can be used to transmit BAP packets for which the route identifier is not specified in the trigger field.
[0073] The second configuration table may include a second enhancement table derived from a BHRLC channel mapping configuration table, an uplink traffic to BH RLC channel mapping configuration table, or a downlink traffic to BH RLC channel mapping configuration table as defined in 3GPP TS 38.340, V16.1.0, Section 5.2.1.4.
[0074] In the variant, the second configuration table is one of the following (traditional): the BHRLC channel mapping configuration table, the uplink traffic to BHRLC channel mapping configuration table, and the downlink traffic to BHRLC channel mapping configuration table, as defined in 3GPP TS 38.340, V16.1.0, Section 5.2.1.4.
[0075] Given the general nature of radio conditions in an IAB network, it may be advantageous for the IAB donor CU to control when to perform BAP sublayer operations (e.g., poor network conditions at certain IAB nodes) and when not to perform BAP sublayer operations (e.g., good overall network conditions).
[0076] In this regard, the initiating IAB node can control whether or not to perform BAP sublayer operations based on BAP sublayer operation enable / disable commands received from the IAB donor central unit (IAB donor CU) of the IAB network. In this scheme, the IAB donor CU thus sends appropriate commands when needed.
[0077] In some embodiments, the initiating IAB node may subsequently receive a BAP sublayer operation enable / disable command from the IAB provider CU, thereby disabling the BAP sublayer operation without transmitting subsequently received BAP packets with the BAP route identifier over multiple RLC channels. Upon receiving instructions from the IAB provider CU, the initiating IAB node switches between applying and not applying the operation, for example, for the received BAP packet and subsequently received BAP packets with the same BAP route ID.
[0078] From the perspective of the terminator, the terminator IAB node can control whether or not to perform BAP sublayer operations based on BAP sublayer operation enable / disable commands received from the IAB donor central unit (IAB donor CU) of the IAB network. Specifically, the terminator IAB node can subsequently receive BAP sublayer operation enable / disable commands from the IAB donor CU, thereby disabling BAP sublayer operations by omitting subsequently received redundant BAP packets to obtain a single original BAP packet. These redundant BAP packets can then be forwarded only to the next-hop IAB node.
[0079] From the perspective of the IAB donor CU, BAP sublayer operation enable / disable commands can be sent to the IAB node to enable or disable BAP sublayer operations for the BAP packets to be received. Preferably, several commands are sent to the initiator and the terminator. Note that the IAB donor CU can control simultaneous BAP sublayer operations for different sub-parts of the IAB network.
[0080] In some embodiments, the IAB donor CU may establish at least one redundant egress path at the IAB node before enabling BAP sublayer operations that require two egress paths from the IAB node at the IAB node.
[0081] In some embodiments, the BAP sublayer operation enable / disable command is associated with at least one BAP route identifier carried by the received BAP packet. This allows for enable / disable control at the route ID level, meaning that BAP sublayer operations can be disabled for some packet flows while being applied simultaneously for others.
[0082] In other embodiments, a condition is associated with a BAP sublayer operation, and this condition must be met to enable or disable the BAP sublayer operation, respectively. The condition can be used to enable the operation, while other conditions can be used to disable it. This advantageously moves some processing (condition checking) to the IAB node itself, rather than having all processing at the IAB donor CU.
[0083] In specific embodiments, the conditions include one or more of the following:
[0084] - Defines the timing information for when to enable or disable BAP sublayer operations.
[0085] - Defines the radio frame identifier that enables or disables BAP sublayer operation based on which radio frame (including BAP packets).
[0086] - Define the BAP packet identifier that enables or disables BAP sublayer operations based on which received BAP packet.
[0087] - Define the BH link quality threshold for enabling or disabling BAP sublayer operations based on the link quality of which outgoing link.
[0088] Of course, different times and identifiers can be provided to determine the start and end of the BAP sublayer operation.
[0089] The same threshold can be used to allow or disallow the application of BAP sublayer operations: enable the operation for poor link quality (below the threshold) and disable the operation for good link quality (above the threshold).
[0090] In another embodiment, the conditions are included in the BAP sublayer operation enable / disable command. In a variant, the conditions are provided in a message separate from the BAP sublayer operation enable / disable command.
[0091] In some embodiments, the BAP sublayer operation enable / disable command is based on one of the following message types: such as the BAP MAPPING CONFIGURATION message, UECONTEXT SETUP REQUES message, and UE CONTEXT MODIFICATION REQUESTUE message, as defined in 3GPPTS 38.473, v16.2.0. Therefore, standardized messages are used.
[0092] In other embodiments, BAP sublayer operation enable / disable commands respond to status reports sent by the command recipient. This allows the IAB donor CU to make enable or disable decisions based on information provided by the relevant IAB node.
[0093] In a particular embodiment, the status report indicates the quality level of the BH link, allowing IAB nodes to report the quality of their egress BH links. In a variant, the status report includes explicit requests to enable or disable BAP sublayer operations. The IAB node may have already locally determined whether BAP sublayer operations are necessary or whether current operations need to be terminated. This approach advantageously offloads processing load to the IAB node.
[0094] In other specific embodiments, the status report includes an ULRRC MESSAGE TRANSFER message as defined in 3GPP TS 38.401, Section 8.2.4. Therefore, a standardized message is used.
[0095] In other implementations, BAP sublayer operation enable / disable commands are included in one of the received BAP packets. This approach is suitable for BAP packets inserted into the IAB network at the IAB provider. This advantageously eliminates the need for additional information. Furthermore, with a single (first) BAP packet, the IAB provider CU can configure all relevant IAB nodes (initiators and terminators) to apply BAP sublayer operations to that BAP packet and subsequent BAP packets (until a disabling command or disabling condition is met).
[0096] In some embodiments, the received BAP packet further includes a BAP routing configuration that defines the BAP sublayer operations to be performed when BAP sublayer operations are enabled. Therefore, according to the invention, the BAP packet is self-contained for configuring the associated IAB nodes for BAP sublayer operations. In particular, the same BAP routing configuration in the received BAP packet can define BAP sublayer operations and identify one IAB node as the initiator of the BAP sublayer operation and another IAB node as the terminator of the BAP sublayer operation. Preferably, the enable / disable command for the BAP sublayer operation and the BAP routing configuration are included in the BAP header of the received BAP packet.
[0097] Another aspect of the invention relates to a non-transitory computer-readable medium storing a program that, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform any of the methods defined above.
[0098] At least a portion of the method according to the invention can be implemented by a computer. Therefore, the invention can take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which can be referred to herein as “circuit,” “module,” or “system.” Furthermore, the invention can take the form of a computer program product embodied in any tangible medium having computer-usable program code embodied therein.
[0099] Because this invention can be implemented in software, it can be embodied as computer-readable code for provision to a programmable device on any suitable carrier medium. Tangible carrier media may include storage media such as hard disk drives, magnetic tape devices, or solid-state storage devices. Transient carrier media may include signals such as electrical signals, electronic signals, optical signals, acoustic signals, magnetic signals, or electromagnetic signals (e.g., microwave or RF signals). Attached Figure Description
[0100] Embodiments of the invention will now be described by way of example only and with reference to the following figures, in which:
[0101] Figure 1 Examples of communication systems that can implement the present invention according to one or more example embodiments are provided;
[0102] Figure 2 This schematically illustrates the stacks of some protocol layers involved in IAB operations;
[0103] Figure 3 Examples of BAP protocol data units (PDUs) or packet formats;
[0104] Figure 3a Examples are shown in some embodiments Figure 3 The field format is 307;
[0105] Figure 4 Example of routing management in an IAB network;
[0106] Figure 5 Example of routing table in IAB node according to 3GPP TS 38.300;
[0107] Figure 6 Examples of IAB network topologies that can implement the present invention, according to one or more example embodiments, are provided;
[0108] Figure 7 An example of an enhanced routing table of the first type according to an embodiment of the present invention;
[0109] Figure 8 An example of a second type of enhanced routing table according to an embodiment of the present invention;
[0110] Figure 9 A flowchart illustrates an example method for configuring BAP routes at IAB nodes (including IAB donor DUs) by an IAB donor CU, according to an embodiment of the present invention.
[0111] Figure 9a A flowchart illustrates an example method for enabling or disabling BAP sublayer operations according to an embodiment of the present invention.
[0112] Figure 10 A flowchart illustrates an example method for managing the serial numbers of BAP packages according to an embodiment of the present invention; and
[0113] Figure 11 A schematic diagram of a wireless communication device according to an embodiment of the present invention is shown. Detailed Implementation
[0114] In Integrated Access and Backhaul (IAB) networks, IAB nodes are configured as initiators of BAP sublayer processing for transmitting BAP packets over multiple RLC channels. BAP sublayer processing can replicate received BAP packets. The same sequence number is appended to all replicas to allow another IAB node terminating the replication to identify these replicas. In a variant, BAP sublayer processing can perform network coding on a received BAP packet. Consecutive sequence numbers are assigned to the resulting BAP packets to allow another IAB node terminating the network coding to identify these packets. Thus, the terminator of BAP layer processing terminates replication by discarding all but one replica, or by performing network decoding on received packets with consecutive sequence numbers. Replication processing can be nested within another replication or within network coding. This approach advantageously increases the robustness of the wireless network, distributes the processing load across multiple IAB nodes, and reduces bandwidth waste.
[0115] Figure 1 An example of a communication system 100 that can implement the present invention is shown according to one or more example embodiments.
[0116] As described, Example System 100 is a wireless communication system, particularly a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system.
[0117] System 100 includes multiple UEs (user equipment) 132, 133, 131 and 134, a remote core network 110, a main base station 120 and two integrated access and backhaul (IAB) stations 121 and 122.
[0118] The main base station 120 (also referred to as IAB donor 120) is connected to the core network 110 via a wired link 101 (preferably, fiber optic or any other wired device). In one embodiment, the IAB donor 120 is a 5G NR gNB with additional features supporting IAB characteristics (as defined in the 3GPP TS 38.300, v16.2.0 specification document).
[0119] To extend the network coverage of IAB donor 120 and reach remote UEs 132, 133, and 131, the operator has installed IAB stations 121 and 122, also known as IAB nodes 121 and 122. By acting as relay nodes between IAB donor 120 and UEs 132 and 133, IAB nodes 121 and 122 allow for overcoming accessibility issues caused by the presence of building 108, which is an obstacle to radio wave propagation and therefore to direct attachment and further communication between the UEs and IAB donor 120. This is especially true when communication between IAB donor 120 and UEs 132 and 133 operates at millimeter-wave frequencies that are highly sensitive to shading phenomena.
[0120] IAB provider 120 also serves UE 134, which is directly connected to IAB provider 120.
[0121] IAB donor 120 and IAB stations 121 and 122 thus form a backhaul network to accommodate UEs 132, 133, 131 and 134.
[0122] The Integrated Access and Backhaul (IAB) specification extends several 3GPP standard documents, including:
[0123] -TS 38.300RAN architecture (V16.2.0),
[0124] -TS 38.321 MAC protocol (V16.1.0),
[0125] -TS 38.331 Radio Resource Control (RRC) Protocol (V16.1.0),
[0126] -TS 38.340 Backhaul Adapter Protocol Layer (V16.1.0)
[0127] -TS 38.401RAN architecture (V16.2.0),
[0128] -TS 38.473F1 Application Protocol (V16.2.0).
[0129] Since IAB nodes 121 and 122 are connected to UEs 131, 132 and 133 respectively, these IAN nodes are considered to be access IAB nodes for the UEs to which they are connected.
[0130] IAB Supplier 120 is a logical node providing NR-based wireless backhaul and consists of a central unit (CU or gNB-CU function) and connected supplier distribution units (DU or gNB-DU function). The IAB Supplier CU and IAB Supplier DU can be located remotely from each other. The gNB-DU function is defined in 3GPP TS 38.401. Its purpose is to terminate the NR access interface to the UE and the next-hop IAB node, and to terminate the F1 protocol for the IAB Supplier gNB-CU function.
[0131] IAB nodes that can serve multiple radio zones can wirelessly backhaul to IAB donor 120 via one or more hops. They form a directed acyclic graph (DAG) topology with an IAB donor at the root.
[0132] An IAB node consists of an IAB-DU and an IAB-MT (IAB mobile terminal). The gNB-DU function on the IAB node is also called the IAB-DU and allows downlink (towards the UE) connections to the next-hop IAB. The IAB-MT function includes, for example, physical layer, layer 2, RRC, and non-access stratum (NAS) functions to connect to the gNB-DU of the uplink IAB node (including IAB provider 120, which in this case connects to the IAB provider gNB-CU, and thus to the core network 110 (for example, for initialization, registration, and configuration)).
[0133] In this DAG topology, neighboring nodes on the IAB-DU interface are called child nodes, and neighboring nodes on the IAB-MT interface are called parent nodes. The direction towards the child node is also called downlink, while the direction towards the parent node is called uplink.
[0134] IAB donor 120 provides centralized resource, topology, and routing management for the entire IAB topology.
[0135] Figure 2 (a) and (b) schematically illustrate the stacks of some protocol layers involved in IAB operations.
[0136] The F1 interface supports the exchange of signaling information between endpoints, as well as data transmission to each endpoint. From a logical point of view, the F1 interface is a point-to-point interface between endpoints.
[0137] In 5G NR, F1-C is the functional interface in the control plane (CP) between the IAB donor CU and the IAB node DU. F1-U is the functional interface in the user plane (UP) for the same cell. F1-C and F1-U are... Figure 2 Reference numeral 212 is shown in (a). In this example, F1-U and F1-C are carried via two back hops (from the IAB donor to IAB node 1, and then from IAB node 1 to IAB node 2).
[0138] In the user plane, box 210 at the IAB donor CU and IAB node DU refers to the GTP-U layer, and box 211 refers to the UDP layer. GTP-U stands for GPRS Tunneling Protocol User Plane. GTP-U tunnels are used to carry encapsulated PDUs and signaling messages between given GTP-U tunnel endpoint pairs (see 3GPP TS 29.281 for more details), here at box 210 at the IAB donor CU and IAB node DU. The User Datagram Protocol (UDP), as is generally known, is a transport layer protocol that provides best-effort datagram service and is suitable for use with the IP protocol.
[0139] In the control plane, box 210 indicates the F1AP (F1 Application Protocol) layer, and box 211 indicates the SCTP (Flow Control Transport Protocol) layer. The F1 Application Protocol (as defined in 3GPP TS 38.473 and TS 38.450) provides signaling services between the IAB donor CU and IAB node DU, or services associated with the UE. These services include, for example, initialization and configuration. The well-known SCTP layer utilizes congestion control to provide reliability in the sequential transmission of messages.
[0140] F1-U and F1-C rely on the IP transport layer between the IAB donor CU and the IAB node DU as defined in 3GPP TS 38.450.
[0141] When the IAB donor CU is located far from the IAB donor DU, or is in a virtual instantiation on the same physical machine as the IAB donor CU, the transport between the IAB donor DU and the IAB donor CU also uses the IP transport layer over various media (e.g., wires or optical fibers). IAB-specific transports between the IAB donor CU and the IAB donor DU are specified in 3GPP TS 38.401.
[0142] In the diagram, L1 and L2 represent the transport layer and physical layer of the medium suitable for use, respectively.
[0143] The IP layer can also be used for non-F1 traffic, such as operation, management, and maintenance traffic.
[0144] On wireless backhaul, the IP layer itself is carried over the Backhaul Adaptation Protocol (BAP) sublayer, which enables routing over multiple hops. The BAP sublayer is specified in TS 38.340.
[0145] IP traffic from the IAB-DU is routed over the radio backhaul via the BAP sublayer. In the downlink direction, upper-layer packets are encapsulated by the BAP sublayer at the IAB donor DU, thus forming BAP packets or data units. BAP packets are routed by the BAP layer of intermediate IAB nodes (if present) (and the corresponding BAP entities in the IAB-DU and IAB-MT). Finally, BAP packets are decapsulated by the BAP sublayer at the destination IAB node.
[0146] In the uplink direction, upper-layer packets are encapsulated by the BAP sublayer at the access IAB node, thus forming BAP packets or data units. BAP packets are routed by the BAP layer of intermediate IAB nodes (if present) (and the corresponding BAP entities in IAB-DU and IAB-MT). Finally, BAP packets are decapsulated by the BAP sublayer at the IAB donor DU.
[0147] At the BAP sublayer, routing packets are based on the BAP route ID, which is carried in the BAP header. Figure 3 This example illustrates the format of a BAP data protocol data unit (PDU) or packet. It is specified in section 6.2 of the standardization version 16.1.0 of 3GPP TS 38.340.
[0148] Header 30 includes fields 301 through 306. Field 301 (referred to as the D / C field) is a Boolean value indicating whether the corresponding BAP packet is a BAP data packet or a BAP control packet. Fields 302-304 are 1-bit reserved fields, preferably set to 0 (to be ignored by the receiver).
[0149] Fields 305 and 306 together indicate the BAP route ID of the BAP packet. The BAP address field 305 (also known as the DESTINATION field) is located in the leftmost 10 bits, while the BAP path identification field 306 (also known as the PATH field) is located in the rightmost 10 bits.
[0150] Field 305 carries the BAP address of the destination IAB node or IAB donor DU (i.e., on the BAP sublayer). For routing purposes, each IAB node and IAB donor DU (by IAB donor CU) is configured with a specified BAP address. Field 306 carries the path ID that identifies the routing path that the BAP packet should follow in the IAB topology to reach the destination.
[0151] When a packet arrives at the BAP layer from the upper layer, a BAP header is added to the packet, and when the packet arrives at its destination node, the BAP header is stripped by the BAP layer. The selection of the packet's BAP route ID is configured by the IAB provider CU.
[0152] For example, when a BAP packet is generated by an IAB node (i.e., by an IAB provider for downlink traffic or by an access IAB node for uplink traffic), the IAB node constructs a BAP header with a BAP route ID according to the configuration table defined in 3GPP TS 38.340. This table is referred to as the downlink traffic to route ID mapping configuration table in the IAB provider, or the uplink traffic to route ID mapping configuration table in the access IAB node. In intermediate IAB nodes, the BAP header fields are already specified in the BAP packet for forwarding.
[0153] The following is for reference. Figure 5 This describes how these tables are used for routing.
[0154] To handle message transmission over 5G NR radio media, three additional sublayers (RLC, MAC, and PHY) are implemented at each IAB node below the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for packet segmentation or reconstruction. The RLC also handles requests for retransmission of lost packets. The RLC layer is further described in TS 38.322. The MAC (Medium Access Channel) protocol sublayer is responsible for selecting the available transmission format for user data and mapping logical channels to transport channels. MAC also handles part of the hybrid automatic repeat request scheme. The MAC layer is detailed in TS 38.321. On the transmitter side, the MAC encapsulates data packets originating from the RLC. The MAC adds a header carrying the information required for MAC functionality. On the receiver side, the MAC decapsulates data packets originating from the PHY, removes their headers, and passes the remaining data to the RLC. The PHY sublayer provides an electrical interface to the transmission medium (air) by converting the information stream into a physical modulated signal, modulating the carrier frequency on the transmitter side, and converting the physical modulated signal back into an information stream on the receiver side. The PHY layer is described in TS 38.201, TS 38.211, TS 38.212, TS 38.213, and TS 38.214.
[0155] To pass messages to the user plane or control plane above the BAP sublayer, two other sublayers are used: the PDCP (Packet Data Convergence Protocol) sublayer and the SDAP (Service Data Adaptation Protocol) sublayer for user plane communication or the RRC (Radio Resource Control) sublayer for control plane communication.
[0156] The PDCP sublayer handles IP header compression / decompression, encryption / decryption, and, when necessary, packet integrity. It mandates packet numbering on the transmitter side and packet reordering on the receiver side. The PDCP sublayer is described in 3GPP TS38.323.
[0157] The SDAP sublayer 220 on the user plane handles Quality of Service (QoS). The SDAP sublayer is described in TS 38.324. On the UE side, the SDAP sublayer exchanges payload data with the user's applications (voice, video, etc., not shown in the figure). On the IAB provider side, the SDAP sublayer exchanges data with the core network 110 (Internet traffic, cloud, etc.).
[0158] The RRC sublayer 220, used for the control plane, handles the configuration of protocol entities in the user plane protocol stack. The RRC sublayer is described in TS 38.331. The RRC sublayer is responsible for: broadcasting information required for UE communication with the cell; transmitting paging messages; managing connections, including establishing bearers; mobility functions; measurement configuration and reporting; device capabilities, etc.
[0159] The interface between nodes using the PDCP, RLC, MAC, and PHY layers (for both CP and UP) is called NR-Uu. This mainly involves the interface with the UE.
[0160] The interface between nodes using layers BAP, RLC, MAC, and PHY (for both CP and UP) is called the backhaul RLC channel (BH RLC channel). This primarily involves the interface between IAB nodes.
[0161] NR-Uu is the interface between the UE and the radio access network (i.e., its access IAB node (for both CP and UP)).
[0162] Figure 2 (b) is from 3GPP TS 38.300, v16.2.0, and illustrates the protocol stack used to support RRC and NAS connections for IAB-MT. Non-Access Stratum (NAS) protocols handle messages between the core network and the user equipment (here, the IAB node). NAS protocols manage the establishment of communication sessions and maintain communication with the user equipment while the user equipment is mobile. 5G NAS is described in 3GPP TS24.501. The 5G Core Access and Mobility Management Function (AMF) is a function within the core network used to receive all connection and session-related information from the UE connected to the IAB node, as well as similar information specific to the IAB node. The AMF is only responsible for handling connection and mobility management tasks.
[0163] The IAB-MT establishes a signaling radio bearer (SRB) (carrying RRC and NAS messages) with the IAB donor CU. These SRBs are transmitted between the IAB-MT and its parent node via the NR-Uu interface.
[0164] Figure 4 This example illustrates routing management in an IAB network. Routing management at an IAB node acting as a repeater is based on the BAP routing configuration and attempts to determine a BH RLC channel for an egress link used to forward the received BAP packets, based on the ingress link used to receive the BAP packets.
[0165] BAP routing configurations can be manually set at each IAB node in the IAB network. Preferably, the BAP routing configuration is built and can be updated over time by the IAB provider CU, and transmitted to the IAB nodes via F1AP signaling during its initial configuration and the lifetime of the IAB network.
[0166] The BAP routing configuration of the IAB node includes various routing tables. Figure 5 Two of the routing tables are shown in the image.
[0167] Figure 5(a) schematically illustrates entry 500 of the backhaul routing configuration table for the BAP sublayer, as defined in 3GPP TS 38.300, V16.2.0, Section 6.11.3. IAB nodes use this entry to select the egress link to forward or transmit BAP packets or PDUs (Protocol Data Units).
[0168] Field 501 defines the BAP route ID (a combination of the PATH and DESTINATION fields mentioned above), while field 502 specifies the next-hop BAP address, that is, the BAP address of the next IAB node along the path corresponding to route ID 501. The next-hop BAP address 502 thus identifies the egress link used to forward or transmit BAP packets.
[0169] The backhaul route configuration table can contain multiple entries that have the same destination BAP address but different path IDs and next-hop BAP addresses in information element 502. The first entry provides the default next-hop BAP address corresponding to the default path to the destination, and the other entries with the same destination BAP address relate to the backup redundant path to be selected when the default link is unavailable (e.g., due to radio link failure (RLF)).
[0170] Figure 5 (b) schematically illustrates entry 510 of the BH RLC channel mapping configuration table as defined in 3GPP TS 38.300, Section 6.11.3, and / or 3GPP TS 38.340, Section V16.1.0, Section 5.2.1.4.1 for the BAP sublayer. The IAB node acting as a repeater uses this entry to identify the backhaul (BH) RLC channel at which it will forward BAP packets or PDUs via the egress link previously selected using the backhaul routing configuration table.
[0171] Information element (IE) 511 stores the next-hop BAP address as previously defined and typically obtained from the backhaul routing configuration table; IE 512 stores the previous-hop BAP address, i.e., the BAP address of the previous IAB node (from which the BAP packet arrives); IE 513 specifies the ingress RLC channel ID, i.e., the identifier of the RLC channel used to receive the BAP packet; and IE 514 stores the egress RLC channel ID, which provides the RLC channel that will be used by the IAB node to forward the BAP packet.
[0172] Note that for the downlink direction (mother to child direction, for example...) Figure 4For the BH RLC channel (from IAB node 402 to IAB node 403), the BH RLC channel ID is included in the F1AP configuration of the BH RLC channel. For the uplink direction (child to parent direction, e.g., from IAB node 402 to IAB node 401) of the BH RLC channel, the BH RLC channel ID is included in the RRC configuration of the corresponding logical channel.
[0173] Figure 5 (c) and (d) illustrate equivalents of the BH RLC channel mapping configuration table for IAB nodes that do not act as intermediate IAB relay entities. These equivalents are defined in 3GPP TS 38.340, Sections 5.2.1.4.2 and 5.2.1.4.3.
[0174] Figure 5 The table in (c) is called Uplink Traffic to BH RLC Channel Mapping Configuration Table 520. This table is used by the IAB node (not the IAB donor) that has already constructed BAP packets or PDUs based on BAP SDUs (Service Data Units) received from the upper layer to identify the backhaul (BH) RLC channel, thereby enabling the use of… Figure 5 The backhaul routing configuration table described in (a) specifies the previously selected egress link for transmitting these packets in the uplink direction.
[0175] IE 521 specifies the traffic type identifier of the SDU received from the upper layer, IE 522 indicates the next-hop BAP address as previously defined and typically obtained from the backhaul routing configuration table, and IE 523 specifies the egress BH RLC channel that provides the RLC channel to be used by the IAB node to transmit BAP packets.
[0176] Figure 5 The table in (d) is called the Downlink Traffic to BH RLC Channel Mapping Configuration Table 530. The IAB node, which has already constructed BAP packets or PDUs based on the BAP SDUs (Service Data Units) received from the upper layer, uses this table to identify the Backhaul (BH) RLC channel, thereby transmitting these BAP packets in the downlink direction using the egress link previously selected by the Backhaul Routing Configuration Table.
[0177] IE 531 is an IPv6 flow label used to classify IPv6 flows, IE 532 specifies the DSCP (Differential Service Code Point) that is usually indicated in the IPv6 header of the packet, IE 533 indicates the destination IP address, IE 534 indicates the next-hop BAP address as defined above, and IE 535 defines the egress BH RLC channel ID that provides the RLC channel to be used by the IAB node to transmit BAP packets.
[0178] Figure 5The tables in (b), (c), and (d) may consist of several rows (entries), each of which is included in the IE shown in the corresponding figure.
[0179] Next-hop BAP address and egress link are synonymous because they specify the same portion (link) of the IAB network between the current IAB node and the next IAB node with the next-hop BAP address. Therefore, they can be used indiscriminately to specify such IAB network links.
[0180] Return to Figure 4 Routing BAP packets using the BAP sublayer of IAB node 402 will utilize the BAP route ID 305+306 of the BAP packet. The BAP address (DESTINATION field 305) is used for the following purposes:
[0181] 1) Determine whether the BAP packet has reached its destination node on the BAP sublayer, i.e., the IAB node or the IAB donor DU. If the BAP address 305 in the packet's BAP header matches the BAP address configured via RRC on the IAB node or via F1AP on the IAB donor DU, then the BAP packet has reached its destination node.
[0182] 2) Determine the next-hop IAB node for BAP packets that have not yet reached their destination. This applies to BAP packets that have arrived from the previous-hop IAB node on the BAP sublayer or have already been received from the upper layer.
[0183] For packets arriving from the previous hop IAB node or from the upper layer, the determination of the next hop IBA node is based on backhaul routing configuration table 500.
[0184] IAB node 402 resolves the next-hop BAP address 502 to a physical backhaul link, which is either link 420 or link 430. To do this, it looks for an entry in the lookup table with field 501 that matches the BAP route ID 305+306 of the BAP packet. The corresponding field 502 provides the next-hop BAP address.
[0185] The return route configuration table can have multiple entries 500, each with different BAP route IDs but the same destination BAP address (meaning the BAP path IDs are different). These entries can correspond to the same or different egress BH links. In the event that the BH link matching the BAP route ID of a BAP packet experiences a radio link failure (RLF), the IAB node can select another egress BH link (next-hop BAP address) based on a route entry with the same destination BAP address (i.e., by disregarding the BAP path ID). In this way, BAP packets can be delivered via an alternative path if the indicated path is unavailable.
[0186] For example, in the event of a radio link failure on BH link 420, IAB node 402 can choose another BAP route ID that has the same destination BAP address but instead involves BH link 430.
[0187] Next, IAB node 402 obtains the egress BH RLC channel of the selected egress BH link, on which BAP packets will be transmitted or forwarded. To this end, IAB node 402, depending on its role (intermediate relay IAB node, IAB node, or IAB donor transmitting in the uplink or downlink direction), uses either the BH RLC channel mapping configuration table or the uplink-to-BH RLC channel mapping configuration table or the downlink-to-BH RLC channel mapping configuration table.
[0188] For example, for an intermediate relay IAB node, IE 511, 512, and 513 are inputs to the BH RLC channel lookup process, and IE 514 is the output of the BH RLC channel lookup process: IAB node 402 routes the incoming BAP packet received from the ingress BH RLC channel ID 513 to the egress BH RLC channel ID 514, where the ingress BH RLC channel ID 513 belongs to the ingress BH link identified by the previous hop BAP address 512, and the egress BH RLC channel ID 514 belongs to the previously selected egress BH link now identified by the next hop BAP address 511.
[0189] For an IAB node wishing to transmit BAP packets to the IAB provider in the uplink direction, IE 521 and 522 are inputs to the BH RLC channel lookup process, and IE 523 is the output of the BH RLC channel lookup process: IAB node 402 selects the egress BH RLC channel 523 corresponding to table entry 520, in which the traffic type identifier 521 matches the traffic type of the original BAP SDU, and the next-hop BAP address 522 matches the next-hop BAP address previously selected using the backhaul routing configuration table. This applies to BAP SDUs (non-F1-U packets) in the control plane and BAP SDUs (F1-U packets) in the user plane. The traffic type identifier 521 should correspond to the destination IP address and TEID (Tunnel Endpoint Identifier) of the BAP SDU.
[0190] For an IAB node (which may be an IAB donor) that wishes to transmit BAP packets in the downlink direction to a destination IAB node or UE, IEs 531, 532, 533, and 534 are inputs to the BH RLC channel lookup process, and IE 535 is the output of the BH RLC channel lookup process: the IAB node selects the egress BH RLC channel 535 corresponding to table entry 530, which matches the destination IP address 533, IPv6 flow label 531 (used only for encapsulating IPv6 packets in BAP SDUs), and Differential Service Code Point (DSCP) 532 of the original BAPSDU, and where the next-hop BAP address 534 matches the next-hop BAP address previously selected using the backhaul routing configuration table. This applies to BAP SDUs (non-F1-U packets) in the control plane and BAP SDUs (F1-U packets) in the user plane.
[0191] In any case where no match is found, the default BH RLC ID channel is selected.
[0192] This routing process can be implemented in various IAB nodes of the IAB network.
[0193] Figure 6 An example of an IAB network topology illustrating network path diversity is shown. In one embodiment, the BH radio operates in the millimeter-wave band (i.e., above 30 GHz), which is highly sensitive to radio channel interference.
[0194] The IAB BH network 600 consists of an IAB donor 601, similar to IAB donor 120, and multiple IAB nodes 601, 602, 603, 604, 605, 606, 607, 608, and 609, similar to IAB nodes 121 and 122. These IAB nodes are connected via BH links 612, 614, 623, 626, 645, 646, 657, 668, 678, and 689.
[0195] Since IAB nodes 601, 603, 605 and 609 serve UEs 611, 612, 613, 614, 615 and 616 respectively, these IAB nodes also act as access IAB nodes for the corresponding UEs.
[0196] Building 620 represents an obstacle to the propagation of radio signals, thus preventing the establishment of a BH link between IAB node 609 and IAB node 603.
[0197] There are redundant paths from IAB donor 601 to node 609, such as a first default BAP path via IAB nodes 602, 606, and 608, a second BAP path involving IAB nodes 604, 606, and 608, and a third BAP path involving IAB nodes 604, 605, 607, and 608.
[0198] The radio link 626 between IAB nodes 602 and 606 may experience a radio link failure due to some unexpected interference or shadowing phenomena. The default BAP path may therefore become unavailable. In this case, only the second and third paths will be used.
[0199] Path redundancy improves the robustness of data transmission. Other robustness mechanisms are known.
[0200] For example, if the radio link 646 between IAB nodes 604 and 606 experiences a weakness due to interference such as shadowing, then using packet replication of the second and third paths is a way to improve reliability.
[0201] PDCP replication (i.e., PDCP sublayer) Figure 2 The packet replication at (shown) is an existing mechanism. PDCP replication between IAB donor 601 and UEs 614, 615, and 616 means that PDCP replication is end-to-end.
[0202] The first drawback of the end-to-end approach is that PDCP replication-related processing for all data streams is concentrated only on the IAB donor and the UE. This results in a high processing load on both the IAB donor and the UE.
[0203] Furthermore, if PDCP replication is enabled due to a specific IAB link experiencing low quality, the entire IAB network must transmit a copy of the packet. This results in wasted bandwidth.
[0204] In this context, the present invention provides IAB-level management of BH links, i.e., control at the link level.
[0205] For example, this allows packet replication to be performed only on the low-quality portions (one or more links) of the IAB network. Therefore, other parts of the IAB network do not transmit packet copies, thus reducing bandwidth waste. Furthermore, packet replication processing is no longer concentrated on the IAB provider and UE. Instead, it moves to the specific IAB node where the replication ends on the aforementioned low-quality portion.
[0206] More generally, robustness mechanisms using network diversity can be specifically provided to sub-parts of the IAB network, rather than to the entire IAB network.
[0207] See still Figure 6For example, IAB node 604 can be configured according to an embodiment of the invention to perform packet replication at the BAP sublayer, to replicate the received BAP packets and forward the copies via both egress links 645 and 646. Previously, no replication was performed; that is, a single copy of the BAP packets had already been transmitted via link 614, therefore the network bandwidth in link 614 was not wasted.
[0208] The replicas can reach IAB node 608 via two different paths (path 604-606-608 and path 604-605-607-608). IAB node 608 can be configured to terminate the replication process according to an embodiment of the invention. In this case, IAB node 608 receives all replicas and forwards only a single copy of the original BAP packet to access IAB node 609 (or destination IAB node) via egress link 689.
[0209] An alternative to packet duplication is to provide network-encoded versions of multiple BAP packets from the original BAP packet. IAB node 604 can transmit multiple BAP packets via egress links 645 and 646, while IAB node 608 receives all these packets and reassociates them (via network decoding) to recover the original BAP packet. A single copy of the original BAP packet is then forwarded via egress link 689 to access IAB node 609 (or the destination IAB node).
[0210] Network coding is well-known. Therefore, detailed descriptions of network encoders and network decoders are not provided in this article.
[0211] The above example illustrates that robust management at the IAB link level requires one or more IAB nodes to receive Backhaul Adaptation Protocol (BAP) packets with the same BAP routing identifier, perform BAP sublayer operations using BAP routing configuration (which determine multiple Radio Link Control (RLC) channels belonging to one or more egress links for the received BAP packets based on the same BAP routing identifier), and ultimately transmit the BAP packets over multiple RLC channels. These IAB nodes initiate diversity-based mechanisms for sub-segments of the IAB network. These IAB nodes are referred to below as initiators.
[0212] One or more other IAB nodes (at the other end of the network sub-segment) are configured to: receive Backhaul Adaptation Protocol (BAP) packets redundant with the original BAP packets via one or more ingress links; perform BAP sublayer operations using BAP routing configuration (which determines whether the redundancy of the BAP packets ends at the IAB node); and, if affirmative, process the redundant BAP packets to obtain the original BAP packets; and transmit the single original BAP packets via egress links, or transmit the contents of the packets to the upper layer of the IAB node. Because these nodes terminate diversity-based operations for the network sub-segment, they are referred to below as terminators.
[0213] Depending on the direction of the data flow, the initiating IAB node and the terminating IAB node can be indistinguishable as an access IAB node, an intermediate relay IAB node, or even an IAB donor DU. Furthermore, any IAB node can simultaneously act as the initiator of one packet flow and the terminator of another.
[0214] In an embodiment, to make it easier for the terminating IAB node to identify the copy, or to make it easier for the terminating IAB node to identify various BAP packets for proper reassociation via network decoding, the initiating IAB node may add a sequence number to the BAP packets it transmits.
[0215] The configuration of the initiator and terminator can be static and performed manually by the network operator or during the IAB node manufacturing process. In a variant, the BAP routing configurations of the initiator and terminator (for operation according to the invention) are preferably received from the central unit of the IAB donor. Dynamic configurations that can evolve over time can be provided. Furthermore, the method can advantageously be based on the processing of existing IAB node configurations utilizing the IAB donor CU.
[0216] BAP sublayer operations can also be enabled or disabled as needed by the IAB donor CU, as described in more detail below.
[0217] The BAP routing configuration for operation according to an embodiment of the present invention includes the aforementioned backhaul routing configuration, BH RLC channel mapping configuration, uplink traffic to BH RLC channel mapping configuration, and downlink traffic to BH RLC channel mapping configuration table, which can be modified with new fields as appropriate.
[0218] Figure 7 and Figure 8 An enhanced table obtained according to an embodiment of the present invention is shown.
[0219] Figure 7 Example usage Figure 5The backhaul routing configuration table (a) and parameters for appropriate BAP sublayer operations declare two alternatives for the initiator and the terminator (if any). These parameters can, for example, define which data (packets) are involved in the operation and how they must be handled (selection of IAB links). As mentioned above, this enhanced backhaul routing configuration table can be part of the configuration provided by the IAB provider CU to the IAB nodes. This is because the IAB provider CU has a holistic view of the IAB network.
[0220] IE 501 and 502 with Figure 5 (a) is the same as IE 501 and 502.
[0221] Entry 700 of the enhanced backhaul routing configuration table also includes IE 703, IE 704, and IE 705.
[0222] The IE 703 command, known as the replication command IE, instructs the IAB nodes configured using this table to perform a BAP sublayer operation when processing incoming BAP packets. The BAP header of the BAP sublayer operation indicates the route ID value that matches the BAP route ID IE 501. Therefore, IE 703 indicates, through multiple entries 700 provided in the table, which data stream (BAP route ID) should be subjected to the BAP sublayer operation.
[0223] The value taken by IE 703 can also indicate whether the IAB node that must perform BAP sublayer operations is the initiator or the terminator of the mechanism.
[0224] In one embodiment, BAP sublayer operation is based on redundant packet transmission. This means that the initiator obtains packets redundant to the received BAP packet and then transmits the redundant BAP packet through multiple RLC channels. In this case, a terminating party can be defined, which receives BAP packets redundant to the original BAP packet and then processes these BAP packets to obtain the original BAP packet. Then, only the original BAP packet is transmitted through the egress link, or the content of that packet is transmitted to the upper layer of the IAB node.
[0225] Redundancy in packets can be simply a copy or duplicate of the received (original BAP packet). In this case, the redundant BAP packets to be transmitted include the received BAP packet and one or more copies thereof.
[0226] Redundant BAP packets can alternatively be the result of network encoding of received BAP packets. This can be done using BAP packets individually (e.g., by segmenting and combining the resulting segments) or using one or more other received BAP packets (which are thus combined). This means that for the terminator, processing of redundant BAP packets involves network decoding them to obtain the original BAP packets.
[0227] Network coding implements, for example, multiple linear combinations (including recognition) of two packet streams to obtain more combined output streams. On the receiver side (here, the terminator), any combination of two received streams (decoding) allows retrieval of the original two packet streams. Multiple linear combinations (for encoding and decoding) can be represented as matrices.
[0228] In another embodiment, BAP sublayer operation involves only segmenting the incoming packet stream across multiple egress links. The aim is to reduce local bandwidth usage on the BH links. In this case, the initiator segments the received BAP packet stream into multiple (typically two) substreams and transmits each substream of the BAP packet via multiple RLC channels. No terminating agent is required for this segmentation operation. All BAP packets will be received at the end-side (i.e., the destination IAB node).
[0229] These BAP sub-layer operations all generate at least two packet sub-streams from the received BAP packets: a copy stream, a combined output stream, or a split sub-stream.
[0230] BAP sub-level operations can be combined and / or repeated.
[0231] For example, the combined output stream (from network coding) can be split or copied over multiple RLC channels and then decombined (network decoded) in the terminator IAB node.
[0232] Furthermore, for nested sub-subparts of the IAB network, for example if a sub-subpart of the nested network requires higher robustness, the packets copied through the sub-subparts of the IAB network can be replicated again.
[0233] Furthermore, the IAB network can implement and authorize (through configuration) only sub-parts of these possible BAP sublayer operations.
[0234] The IE 704 (referred to as the replicated BAP route ID) has different meanings depending on whether the IAB node is the initiator or the terminator.
[0235] For the initiator, IE 704 indicates a list of routing entries to determine one or more egress BH links traversed for the transmission of multiple generated packets. In a specific case of entry 700, IE 704 may include one or more BAP route IDs traversed for the transmission of BAP packets generated by BAP sublayer operations. The list of BAP route IDs can define which route ID is used for each subflow generated by the BAP sublayer operation: a replicated flow, a combined output flow, or a split subflow. Specifically, each routing entry in list 704 corresponds to a specific packet flow / subflow and defines the egress BH link traversed for the transmission of that specific packet flow / subflow.
[0236] For the terminator, IE 704 can indicate a list of BAP route IDs traversed by the received copy or combined stream. This list can exclude BAP route IDs of IE 501. This is so that a terminator that still receives a BAP packet with BAP route ID 501 can efficiently search for its redundant BAP packets by virtue of the BAP route ID in IE 704, process these BAP packets, and retrieve one or more original BAP packets.
[0237] IE 705 (referred to as the copy parameter) provides the necessary parameters (if present) to perform the BAP sublayer operation specified in IE 703.
[0238] By populating IE 703-705 in the backhaul route configuration table (done by the IAB donor CU), any IAB node becomes aware of which BAP packet flows (BAP route ID 501) must be BAP sublayer operations performed, and (where appropriate) whether it must act as an initiator or terminator.
[0239] The replication command IE 703 can therefore take various values. In an embodiment, one of the following values can be used: "replication initiator" value, "replication terminator" value, "network coding initiator" value, "network coding terminator" value, "segmentation initiator" value, or null value (if the BAP packet matches the BAP route ID of IE 501, the IAB node behaves in transparent mode (i.e., no BAP sublayer operation is required)).
[0240] The replication operation is driven by the "replication initiator" value, which signals the initiator of the replication, and the "replication terminator" value, which signals the terminating party of the replication.
[0241] When the replication command IE 703 uses the "replication initiator" value for a given BAP route ID (of an incoming packet), it instructs the associated IAB node to act as the initiator of the replication operation. Therefore, the IAB node must begin replicating the incoming BAP packet so that it can then be transmitted as defined in other IEs (particularly IE 704, which lists the BAP route IDs used for transmission).
[0242] IE 705 includes a sequence number insertion boolean message that indicates whether an IAB node must insert a sequence number (SN) into the replicated BAP packet. This sequence number insertion boolean message is optional: independent of BAP routing configuration, an IAB node can know whether to add an SN if replication is enabled (or another BAP sublayer operation).
[0243] The SN is used to mark the replica packet, so that the terminator IAB node can easily retrieve a replica of the same original BAP packet from all received BAP packets, and suppress the replica so that the original BAP packet is forwarded only once.
[0244] Preferably, the same SN is indicated in all outgoing BAP packets generated from the same original BAP packet. For each new incoming BAP packet to be copied, the SN can be incremented by 1.
[0245] Of course, other solutions can be envisioned: for example, in the case of producing only a single copy, the original BAP packet can be labeled with SN=2n, while its copy can be labeled with SN=2n+1.
[0246] For example, the SN is inserted into field 307 of the BAP package (e.g. Figure 3 The 2-byte field is shown in the diagram. Field 307 can belong to the header of the BAP packet (immediately before the variable-length payload data 308). Its presence is signaled in the BAP header: for example, bit 302 is used to signal from the BAP header whether the SN (field 307) is provided (bit set to 1) or not provided (bit set to 0) in the BAP data PDU.
[0247] Table 1 illustrates example entry 700 for the replication initiator.
[0248] Table 1
[0249]
[0250] The table configures IAB node 604 as a replication initiator with two outgoing replicated BAP packets (the number of route IDs declared in list 704) dedicated to route ID 1 (501) and the insertion of sequence number (705).
[0251] PATH1, traversing IAB nodes 606 and 608, is the default path used regardless of whether replication is enabled by IE 703, while PATH2, traversing IAB nodes 605, 607, and 608, is the secondary path used when replication is enabled by IE 503 ("Replication Initiator" value). Assuming poor quality of the BH link 646 between IAB nodes 604 and 606, BAP packet replication at IAB node 604 helps prevent service interruptions in the IAB network due to packet loss or potential RLF on that link.
[0252] Incoming BAP packets with route IDs corresponding to field 501 are replicated at the IAB node as multiple copies corresponding to the number of route IDs in list 704 (2 in the example above). Outgoing replicated BAP packets are exact copies of the incoming BAP packets, except for the BAP header, which may, for example, differ from the header specifying the corresponding route ID in list 704. The resulting outgoing replicated BAP packets are transmitted through one or more egress links corresponding to the route IDs in list 704, i.e., to the next-hop BAP address 502 corresponding to these route IDs (as indicated in 501).
[0253] In the example above, IAB node 604 should copy the incoming BAP packet with route ID1 in the header once to obtain two identical outgoing BAP packets, except for the BAP header. One BAP packet is set to route ID1, and the other is set to route ID2. The two outgoing BAP packets are transmitted by the IAB node through two egress BH links: the first outgoing BAP packet with route ID1 is transmitted to IAB node 606 via BH link 646, as shown in field 502 (for the route ID1 entry), and the second outgoing BAP packet with route ID2 is transmitted to IAB node 605 via BH link 645, as shown in field 502 (for the route ID2 entry). In practice, the return route configuration table should contain an additional entry (i.e., an entry for route ID2) to indicate to the IAB node the next-hop BAP address associated with the new route ID, and thus the egress BH link.
[0254] In another example where List 704 is [Route ID1, Route ID2, Route ID3], three copies are made to obtain four outgoing BAP packets transmitted by the IAB node through three egress BH links: the first outgoing BAP packet with Route ID1 goes through BH link 646 to IAB node 606, the second and third outgoing BAP packets with Route ID2 go through BH link 645 to IAB node 605, and the fourth outgoing BAP packet with Route ID3 goes through another BH link to another IAB node (not shown).
[0255] Again, for example, all outgoing BAP packets corresponding to the same original incoming BAP packet are given the same SN.
[0256] When the replication command IE 703 uses a "replication terminator" value for a given BAP route ID (of an incoming packet), it instructs the associated IAB node to act as the terminator of the replication operation. Therefore, the IAB node must terminate the forwarding of the copy and forward only a single copy (the original BAP packet) via a single egress BH link (in the case of intermediate IAB nodes), or decapsulate the BAP packet to transmit a single SDU packet to the upper layer (in the case of the destination IAB node). In either case, the IAB node will check the return route configuration table, even if the BAP packet is to be transmitted to a locally attached UE. In one embodiment of the invention, the single egress BH link is the BH link identified by the PATH field of BAP route ID 501.
[0257] To help IAB nodes retrieve replicas, IE 704 includes a list of other route IDs (sometimes a single route ID) for replicas of the same original BAP packet.
[0258] Furthermore, due to the value of bit 302, the IAB node knows whether a serial number (SN) is provided in the received BAP packets. By retrieving the SN field 307 of various received BAP packets, the IAB node is able to detect a replica with either BAP route ID 501 or list 704.
[0259] For example, received BAP packets with the same SN are copies of the same original BAP packet.
[0260] In the variant that utilizes the initiator's sequence number (described above), received BAP packets with SN = 2n and 2n+1 are considered copies of the same original BAP packet.
[0261] The primary usefulness of the SN lies in its ability to facilitate replica identification by the terminator. Therefore, the SN can typically be removed from the header of the acquired original BAP packet before it is transmitted to the next-hop IAB node. However, in some cases described below, SN removal may not be necessary. Therefore, IE 705 may include sequence number removal Boolean information indicating whether the IAB node needs to remove the SN from the outgoing BAP packet.
[0262] Table 2 illustrates example entry 700 for a replication terminator.
[0263] Table 2
[0264]
[0265] This table configures IAB node 608 as the replication terminator IAB node, where the copy of route ID1 and route ID2 is removed from the incoming BAP packet specified in the packet header. In all cases, the remaining BAP packet after copy removal (i.e., the original BAP packet) is transmitted to the egress BH link 689 between IAB nodes 608 and 609.
[0266] In one embodiment of the invention, the headers of the remaining BAP packets (some of which may still specify route ID2) are all updated to the initial value route ID1 or the default route ID (e.g., route ID1). In practice, all remaining BAP packets must be transmitted over a single egress link, meaning that they must preferably all be assigned to the same route ID for outgoing processing.
[0267] In the example above, incoming replicated BAP packets received by IAB node 608 with route ID1 or route ID2 in the header should be filtered to transmit a single copy of the original BAP packet through the single outgoing BH link 689 identified by IE 502 (or to the upper layer if the IAB node is the destination), while other incoming replicated BAP packets are discarded. To do this, IAB node 608 can identify incoming replicated BAP packets using a sequence number inserted in the BAP header field 307. Two BAP packets marked with the same sequence number represent the same original BAP packet, even though their route ID values are different and they can be received from two different ingoing BH links.
[0268] In this case, parameter 705 is not required.
[0269] This example clearly demonstrates that, due to the present invention, the replication of BAP packets is fully controlled between IAB nodes 604 and 608, while the bandwidth usage of other links (such as BH links 614 and 689) is not affected by the replicated packets.
[0270] Conditional insertion of sequence numbers (due to the Boolean information inserted into the sequence numbers) allows for consecutive replication operations at different initiating IAB nodes. When a second initiating IAB node receives a BAP packet that has already been replicated from the first initiating IAB node, the BAP packet header already contains the SN as described above. Therefore, when performing a second replication operation, the second initiating IAB node knows, based on the Boolean information inserted into the sequence numbers, that it should not insert a new sequence number. Preferably, existing sequence numbers are not modified. In fact, all copies (obtained by one replication operation or two or more consecutive replication operations) have the same SN. Therefore, any terminating IAB node can easily detect copies from incoming BAP packets.
[0271] In this variant, the insertion of the serial number (SN) is not indicated in the backhaul routing configuration table (i.e., no boolean information on sequence number insertion is provided). In this case, when analyzing the header of the BAP packet to be copied, the initiating IAB node determines whether a sequence number exists (e.g., due to bit 302) and can act accordingly: either retain the existing SN for the new copy, or insert the SN if the incoming BAP packet has not yet been copied. This approach reduces processing at the second initiating IAB node because sequence number insertion can be skipped.
[0272] Return to Figure 6 ,exist Figure 6 The BH link 626 between IAB nodes 602 and 606 can now be reused, and IAB donor 601 can perform a first replication with two copies of the BAP packets transmitted via BH links 612 and 614. Therefore, the resulting copies have the same serial number according to the above processing.
[0273] Next, IAB node 604 can also be configured as a replication initiator, thus performing another replication with two copies of any received BAP packets. The replicas are then transmitted to IAB nodes 606 and 605 via BH links 646 and 645, respectively. The replica serial numbers remain unchanged.
[0274] Table 1a illustrates example entry 700 for configuration initiator IAB donor 601.
[0275] Table 1a
[0276]
[0277] As described above, IAB donor 601 acts as the replication initiator, generating two outgoing replication BAP packets and adding the same SN to the BAP header of the outgoing replication BA packet (because the sequence number insertion boolean information is set to true). One packet is then assigned to PATH1 (the default path), traversing IAB nodes 602, 606, and 608 until IAB node 609. This packet is then transmitted by IAB donor 601 to the next-hop IAB node 602 via BH link 612. The other outgoing BAP packet is assigned to PATH2, traversing IAB nodes 604, 606, and 608 until IAB node 609. This packet is then transmitted by IAB donor 601 to the next-hop IAB node 604 via BH link 614.
[0278] Table 1b illustrates example entry 700 for configuring initiator IAB node 604.
[0279] Table 1b
[0280]
[0281] IAB node 604 acts as the replication initiator, generating two outgoing replication BAP packets from the BAP packet assigned to PATH2 (i.e., route ID2) received from IAB donor 601. These incoming BAP packets already include the SN.
[0282] Because the sequence number insertion boolean information is set to false, the initiating IAB node 604 knows that the SN must not be included, but rather the SN of the incoming BAP packet should be preserved. One of the generated copies is then assigned to PATH2, traversing IAB nodes 606 and 608 until it reaches IAB node 609. This copy is then transmitted by IAB node 604 to the next-hop IAB node 606 via BH link 646. Another outgoing BAP packet is assigned to PATH3, traversing IAB nodes 605 and 608 until it reaches IAB node 609. This packet is then transmitted by IAB node 604 to the next-hop IAB node 605 via BH link 645.
[0283] Furthermore, IAB node 606 can be configured as a replication terminator, for example because BH link 668 has high quality. IAB node 608 can also be configured as a replication terminator to provide a copy of each original BAP packet to IAB node 609.
[0284] Table 2a illustrates example entry 700 for configuring the terminator IAB node 606.
[0285] Table 2a
[0286]
[0287] IAB node 606 acts as the replication terminator for this branch of the IAB network to remove replicas. While other replicas are being transmitted simultaneously on other BH links, the SN should remain within the single copy transmitted by the terminator IAB node 606, as the terminator IAB node 608 is also capable of detecting replicas coming from various BH links.
[0288] By reading the sequence number and removing the Boolean information as false, the terminator IAB node 606 knows that the SN must be placed in the outgoing BAP packet. Thus, due to the same SN, the terminator IAB node 606 detects multiple copies from the incoming BAP packet. It then discards the copies to keep only one copy. This single copy is then transmitted via BH link 668 to the next-hop IAB node of PATH1, namely IAB node 608.
[0289] Table 2b illustrates example entry 700 for configuring the terminator IAB node 608.
[0290] Table 2b
[0291]
[0292] IAB node 608 acts as a replication terminator, which removes received copies to forward only one copy. By reading the sequence number removal boolean information as true, the terminator IAB node 608 knows that the SN in the forwarded copy must be removed.
[0293] Therefore, due to the identical serial numbers (SNs) of the replicas, multiple replicas are detected in the BAP packets received from IAB nodes 606 and 605. The replicas are then discarded to keep only one copy, from which the SN is removed (field 307 is cleared and bit 302 is set to 0). This single copy is then transmitted via BH link 689 to the next-hop IAB node of PATH1, namely IAB node 609.
[0294] This example demonstrates that the IAB donor CU can be configured with various IAB nodes to allow nested replication, where replicas are efficiently discarded to forward only a single copy of the original BAP packet at the end.
[0295] The following is for reference. Figure 10 Give an example of SN management (insertion and deletion).
[0296] Network coding operations are driven by the "Network Coding Initiator" value, which signals the initiator of the operation, and the "Network Coding Terminator" value, which signals the terminator of the operation.
[0297] When the replication command IE 703 uses the "Network Coding Initiator" value for a given BAP route ID (of an incoming packet), it instructs the associated IAB node to act as the initiator of the network coding operation. This means that the IAB node will generate a set of combinations from the incoming BAP packet for the given BAP route ID. Parameters for the combinations can be provided in IE 705. These generated combinations (also known as outgoing redundant BAP packets) will be transmitted via one or more egress BH links (e.g., in a manner similar to the replication initiator), as defined in IE 704, which lists the BAP route IDs used for transmission.
[0298] Parameter 705 may include the network coding scheme to be used. For example, one scheme may be based on a combination of several incoming BAP packets. Another scheme may be based on segmenting each incoming BAP packet into segments of the same size and their combinations. In one embodiment of the invention, a parameter associated with the scheme may identify the number of incoming BAP packets or the number of segments to be combined in the combinations.
[0299] Parameter 705 may include network coding coefficients for each linear combination to be used in generating the incoming BAP packet or segment. As a non-limiting example, these coefficients may be eight bits each in the Galois field 256.
[0300] Parameter 705 may include the sequence number insertion Boolean information as described above. This is again to provide the SN in the SN field 307 of the outgoing redundant BAP packet. Using network coding, for each new outgoing redundant BAP packet, the sequence number can be incremented by one: BAP packets obtained by network coding of the same original BAP packet are thus marked with consecutive sequence numbers.
[0301] For example, the SN format could be a.n+t (e.g., encoded with 2 bytes in field 307), where 'a' is the number (integer) of combinations implemented by network encoding (e.g., 4 in the example below).
[0302] n is an incrementing integer that appears with each new network code (i.e., when processing the next BAP packet), and
[0303] t belongs to {0, 1, 2, ..., a-1}. Each of these values is assigned to one of the a outputs of the network encoder.
[0304] In an embodiment, the SN field 307 may include k bits (a≤2) for identifying different combinations when outgoing packets derived from network encoding are present. k The network encoding includes, for example, k=2, output a=4, and the remaining bits (e.g., 14 bits in a 2-byte field) used to count the number of encoding loops or iterations (i.e., the count increments each time a new outgoing packet is generated). The count can be reset each time a new network encoding configuration is used. When the maximum value is reached, the count naturally returns to zero.
[0305] If the SN format coexists in the IAB network, then the SN format is also compatible with replication operations. For both the original and replicated BAP packets, k bits (e.g., 2 bits) can be set to the same value. The count (remaining bits) increments for each new original BAP packet to be replicated.
[0306] Table 3 illustrates example entry 700 for network coding initiators.
[0307] Table 3
[0308]
[0309] The table configures IAB node 604 as a network coding initiator IAB node, which has four linear combinations generated from segments of the received BAP packets and has the sequence number to be inserted.
[0310] PATH1 is the default path (with and without network encoding) through IAB nodes 606 and 608, and PATH2 is the second path (with network encoding) through IAB nodes 605, 607 and 608.
[0311] The segments forming the incoming BAP packets are linearly combined (schema = segmentation). The first and second linear combinations use coefficients (1, 0) and (α11, α12), and are transmitted by IAB node 604 to IAB node 606 (PATH1 corresponding to route ID1 specified in 704 for the two first outgoing packets) via BH link 646 to obtain the outgoing redundant BAP packets. The third and fourth linear combinations use coefficients (0, 1) and (α21, α22), and are transmitted by IAB node 604 to IAB node 605 (PATH2 corresponding to route ID2 specified in 704 for the last two outgoing packets, due to the second entry in the table) via BH link 645 to obtain the outgoing redundant BAP packets.
[0312] Not all sets of the four coefficients in GF 256 are usable. Multiple 1s and 0s must be excluded because they would leave the original data unchanged. Furthermore, (α11 × αl2) should not be equal to (α21 × α22), otherwise the linear combinations would be identical.
[0313] For sequence numbering, outgoing BAP packets generated from the first linear combination can be labeled with SN = 4n; outgoing BAP packets generated from the second linear combination can be labeled with SN = 4n+1; outgoing BAP packets generated from the third linear combination can be labeled with SN = 4n+2; and outgoing BAP packets generated from the fourth linear combination can be labeled with SN = 4n+3.
[0314] When the copy command IE 703 uses the "Network Coding Terminator" value for a given BAP route ID 501 or 704 (of an incoming packet), it instructs the associated IAB node to act as the terminator for the network coding operation. This means that the IAB node will apply network decoding to incoming encoded BAP packets that have a route ID that matches field 501 or 704 in the table.
[0315] The IAB node identifies the received combination by the SN in field 307 (whose presence is indicated by bit 302) and decodes it to retrieve one or more original BAP packets (via segment). Decoding parameters are provided in parameter 705.
[0316] In one embodiment of the invention, the IAB node then transmits the decoded BAP packet via a single egress BH link corresponding to the next-hop BAP address 502 (if the node is an intermediate IAB node), or transmits the BAP packet to an upper layer (if the node is the destination IAB node). In one embodiment of the invention, the single egress BH link is a BH link identified by the PATH field of the BAP route ID 501, i.e., toward the next-hop IAB node 502.
[0317] For the network coding initiator, parameter 705 may include the network coding scheme to be used (segmentation or packet), the network coding coefficients to be used to decode redundant BAP packets, and optionally the number of redundant BAP packets required for decoding (in a variant, this number is derived from the number of combinations provided by the network coding coefficients).
[0318] Regarding the sequence numbering of incoming BAP packets, packets with SN = a.n + t (where t belongs to {0, 1, 2, ..., a-1}) and the same value n are considered redundant to the same one or more original BAP packets. The same number of redundant BAP packets as the number of original inputs (packets or segments of packets) is usually sufficient for correct network decoding and retrieval of the original input. For example, in the example below, two redundant BAP packets are sufficient for network decoding.
[0319] Table 4 illustrates example entry 700 for network coding terminators.
[0320] Table 4
[0321]
[0322] This table configures IAB node 608 as a network coding terminator IAB node, where network decoding can be performed upon receiving two incoming redundant BAP packets (number of segments = 2) with either route ID1 or route ID2 (specified in 501 and 704) in the header. These packets can be identified if their sequence numbers are equal to 4n + t (t belongs to {0, 1, 2, 3} and have the same value n). Therefore, redundant BAP packets corresponding to the same original BAP packet are packets marked with sequence numbers separated by fewer combinations than defined by network decoding.
[0323] For example, for a network coding scheme with four linear combinations, the sequence number matching 4n (where n is an integer) corresponds to the first linear combination of a set of redundant BAP packets, the sequence number matching (4n+1) corresponds to the second linear combination, the sequence number matching (4n+2) corresponds to the third linear combination, and the sequence number matching (4n+3) corresponds to the fourth linear combination. Furthermore, the number of generated combinations in the source IAB node can be derived from the number of rows in the coefficient matrix in IE 705. Therefore, it is sufficient to retrieve two different incoming redundant BAP packets with SNs contained between 4n and 4n+3.
[0324] Of course, combinations of numbers other than 4 can be used.
[0325] Network decoding uses parameter 705 (network coding scheme and coefficients).
[0326] The output of network decoding can be multiple segments of the original BAP packet. In this case, desegmentation is used to reconstruct the original BAP packet. Alternatively, the output can be a different original BAP packet directly.
[0327] One or more BAP packets are transmitted via the egress BH link 689 between IAB nodes 608 and 609 (corresponding to the next-hop BAP address of IE 502). In one embodiment of the invention, the header of the decoded BAP packet may be updated to the initial value route ID1 or the default route ID (such as route ID1). In practice, all decoded BAP packets must be sent via the same link.
[0328] This example clearly demonstrates that, thanks to the present invention, the redundancy introduced by the network-coded BAP packets is completely controlled between IAB nodes 604 and 608, while the bandwidth usage of other links (such as BH links 614 and 689) is not affected by a greater number of packets.
[0329] It can be noted that the copying operation is simply a network encoding operation based on the recognition matrix.
[0330] However, serial numbers can be managed in different ways: by using replication, the same SN is provided in each copy, while by using network coding, consecutive SNs are provided so that it is possible to identify which BAP packet corresponds to which combination.
[0331] What may happen is that, in a manner similar to the nested replication envisioned above, network encoding is enabled for some BAP packets, and then nested replication is enabled for the network-encoded packets (i.e., between the encoding and decoding of the network-encoded packets).
[0332] In this scenario, the network coding initiator can be configured with a sequence number insertion Boolean value set to true (thus, consecutive serial numbers (SNs) are provided to outgoing redundant BAP packets), while the replication initiator can be configured with a sequence number insertion Boolean value set to false (thus, only a copy of the received BAP packet is generated, retaining the SN of that BAP packet). Correspondingly, the replication terminator can be configured with a sequence number removal Boolean value set to false (i.e., the SN is placed in the retained copy of the received replicated BAP packet), while the network coding terminator can be configured with a sequence number removal Boolean value set to true to ultimately remove the SN from the BAP packet.
[0333] The following is for reference. Figure 10 Give an example of SN management (insertion and deletion).
[0334] The split operation is driven by the "split" value signaled to the initiator of replication. No terminating party is required.
[0335] When the replication command IE 703 uses the "Split Initiator" value for a given BAP route ID (of an incoming packet), it instructs the relevant IAB node to act as the initiator of the split operation. This means that the IAB node will split the incoming flow of BAP packets on two or more egress links.
[0336] This embodiment aims at load balancing of the BH link: bandwidth usage is distributed across several paths, while the transmission processing load is distributed across different IAB nodes.
[0337] Since all packets eventually arrive at the same destination IAB node, the splitting operation only requires an initiator (not a terminating one).
[0338] The split is driven by IE 704 and IE 705.
[0339] IE 704 indicates a list of route IDs used to assign BAP packets. As shown in Example Table 5 below, the value [Route ID1, Route ID2] indicates that the incoming BAP packet will be routed and transmitted on the corresponding egress link (specified in IE 502 for the entries corresponding to Route ID1 and Route ID2).
[0340] IE 705 provides parameters for segmentation. For example, the segmentation scheme field indicates the percentage of BAP packets to be transmitted for each route ID (i.e., each egress link) in IE 704, and the segmentation threshold field indicates the default link bandwidth occupancy percentage to be reached to trigger data segmentation in the IAB node. In some embodiments, different segmentation schemes can be defined in IE 705 for different corresponding segmentation thresholds (the segmentation percentage evolves as bandwidth occupancy evolves).
[0341] In the example below, if bandwidth utilization reaches 50%, 40% of the BAP packets for route ID1 are transmitted through the egress link of route ID1 (i.e., BH link 646 to IAB node 606), while 60% of the BAP packets for route ID1 are transmitted through the egress link of route ID2 (i.e., BH link 645 to IAB node 605). The latter's BAP packets may have a BAP header that has been updated to specify route ID2 instead of route ID1.
[0342] Table 5
[0343]
[0344] In some embodiments, IE 704 can remain empty. In this case, the IAB node can set the route ID information element of the outgoing replicated / redundant / split BAP packets to the value of the route ID from another entry in the backhaul route configuration table that has the same DESTINATION value as in IE 501. The selected egress BH link is obtained based on the next-hop BAP address IE502 of the entry with the route ID used.
[0345] Still referencing Figure 7 The difference between replaceable entry 710 and entry 700 in the backhaul route configuration table is IE 714 (compared to IE 704).
[0346] IE 714, known as copying the next-hop BAP address, provides a list of next-hop BAP addresses instead of a list of route IDs (as in IE704). This makes it easier for IAB nodes to determine the egress BH link (because there is no longer a need to search for entries corresponding to route IDs in the list).
[0347] In this scenario, the route ID of all outgoing replicated / redundant / split BAP packets is equal to the route ID of the incoming BAP packets. In other words, the route ID is not modified.
[0348] When IE 703 is set as the replication initiator, IE 714 identifies a list of egress BH links used to transmit outgoing copies. When IE 703 is set as the replication terminator, IE 714 is not used. Incoming copies with a route ID matching the IE 501 entry are removed.
[0349] When IE 703 is set as the network coding initiator, IE 714 represents a list of combinations with corresponding egress BH links. For example, [Next-hop BAP address 1, Next-hop BAP address 1, Next-hop BAP address 2, Next-hop BAP address 2] means that the first and second combinations are transmitted via the egress link associated with next-hop BAP address 1, while the third and fourth combinations are transmitted via the egress link associated with next-hop BAP address 2. When IE 703 is set as the network coding terminator, IE 714 is not used. Incoming redundant BAP packets with a route ID matching the entry in IE 501 are decoded. The number of incoming redundant BAP packets to be received to trigger decoding is indicated by the depth of the coefficient matrix available in IE 705.
[0350] When IE 703 is set as the segment initiator, IE 714 represents a list of egress BH links used to allocate outgoing BAP packets (segmented substreams).
[0351] According to an embodiment of the present invention, the enhanced backhaul routing configuration table described above enables the initiator IAB node to determine the egress BH link to be used for transmitting outgoing BAP packets.
[0352] Traditional BH RLC channel mapping configuration tables, uplink traffic to BH RLC channel mapping configuration tables, and downlink traffic to BH RLC channel mapping configuration tables (as described above) can be used to derive the exit BH RLC channel from the selected exit BH link. Therefore, each substream of the replicated / redundant / segmented BAP packet is directed (and transmitted) to the exit BH RLC channel at the initiator. The original BAP packet transmitted at the terminating point is also directed (and transmitted) to the specific exit BH RLC channel.
[0353] In some embodiments, the enhanced BH RLC channel mapping configuration table, the enhanced uplink traffic to BH RLC channel mapping configuration table, and the enhanced downlink traffic to BH RLC channel mapping configuration table are used by the IAB node to derive multiple egress BH RLC channels from a single selected egress BH link.
[0354] This method aims to provide BH RLC channel diversity, thereby improving transmission robustness.
[0355] Figure 8 Example entries are provided for this BH RLC diversity: Enhanced BH RLC channel mapping configuration table 810, Enhanced uplink traffic to BH RLC channel mapping configuration table 820, and Enhanced downlink traffic to BH RLC channel mapping configuration table 830.
[0356] Replace IE 514, 523, and 534 with IE 814, 823, and 835 respectively.
[0357] Instead of defining a single egress BH RLC channel ID, they comprise a list of egress BH RLC channel IDs. When transmitting an egress BAP packet, the IAB node can alternatively (or use any selection scheme) select one of the egress BH RLC channel IDs for transmission. In embodiments, the BH RLC channel IDs are selected cyclically from the possible values indicated in IE 814, 823, or 835.
[0358] For example, if there are two possible BH RLC channels, a first (more generally, odd) outgoing BAP packet can be transmitted via the first BH RLC channel, while a second (more generally, even) outgoing BAP packet can be transmitted via the second BH RLC channel.
[0359] In some embodiments, control over the BH RLC channel diversity mechanism is provided such that not all BAP packets that match table entries 810, 820, or 830 are transmitted through multiple BH RLC channels.
[0360] Control based on route IDs can be implemented. For example, additional IE 819, 829, or 839, referred to as BAP route IDs, are provided in table entries 810, 820, or 830, respectively. IE 819, 829, or 839 includes one or more triggering BAP route IDs, i.e., BAP route IDs that apply the BH RLC channel diversity mechanism: outgoing BAP packets with only these BAP route IDs are distributed across multiple BH RLC channels in IE 814, 823, or 835. For other BAP route IDs, default BH RLC channel IDs can be used, such as the IDs first declared in IE 814, 823, or 835: outgoing BAP packets with BAP route IDs not listed in IE 819, 829, or 839 are transmitted only on the default BH RLC channel.
[0361] As mentioned above, although the various tables described below can be manually defined in the various IAB nodes of the network, it is preferable that these tables be defined by the IAB donor CU and then transmitted to the IAB node during the BAP routing configuration of the various IAB nodes (including the IAB donor DU).
[0362] Figure 9 This example uses a flowchart to illustrate a method for configuring BAP routes at IAB nodes (including IAB donor DUs) by the IAB donor CU.
[0363] The BAP routing configuration process is initiated by the IAB donor CU 902 to configure the DL / UL (downlink / uplink) routing information and / or traffic mapping information required by the IAB donor DU or IAB node DU (both referred to below as IAB-DU 901).
[0364] IAB donor CU 902 initiates the process by sending a CONFIGURATION REQUEST message 903 to IAB-DU 901 to configure the table above. IAB-DU 901 responds to IAB donor CU 902 using a CONFIGURATION RESPONSE message 904.
[0365] In one embodiment of the present invention, the configuration request message 903 carries the enhanced backhaul routing configuration table of the IAB-DU 901 (i.e., Figure 7The message contains the information required by the IE (as shown). This message may include the entire table. Alternatively, the message may include only the entire entry 700, 710 to be updated or added. Still alternatively, the message may include only information for updating entries already stored in IAB-DU901 and / or for adding new entries.
[0366] In one embodiment of the present invention, the configuration request message 903 carries the BH RLC channel mapping configuration table (i.e., uplink traffic to / downlink traffic to) of the IAB-DU 901. Figure 5 (b) to (c) or Figure 8 The message contains the information required by the IE (as shown). This message may include the entire table. Alternatively, the message may include only the entire entry 810, 820, or 830 to be updated or added. Still alternatively, the message may include only information for updating entries already stored in IAB-DU 901 and / or for adding new entries.
[0367] Various message types can be used for configuration request and response messages.
[0368] In one embodiment, configuration request message 903 is a BAP mapping configuration message, and configuration response message 904 is a BAP mapping configuration confirmation message, as described in 3GPP TS 38.473, v16.2.0, sections 9.2.9.1 and 9.2.9.2.
[0369] Additional fields in the enhanced backhaul routing configuration table (i.e., IE 703-705 or 713-715) can be declared as optional IEs in the BH routing information add-list IEs of the BAP mapping configuration message, as described in 3GPP TS 38.473, v16.2.0. The corresponding declarations can be shown in Table 6.
[0370] Table 6
[0371]
[0372] In the variant, configuration request message 903 is a UE context setting request message, and configuration response message 904 is a UE context setting response message, as described in 3GPP TS 38.473, v16.2.0, sections 9.2.2.21 and 9.2.2.2.
[0373] In another variation, configuration request message 903 is a UE context modification request message, and configuration response message 904 is a UE context modification response message, as described in 3GPP TS 38.473, v16.2.0, sections 9.2.2.7 and 9.2.2.8.
[0374] By considering the enhanced (uplink traffic to / downlink traffic to) BH RLC channel mapping configuration table, IE814, 823, or 835 can be declared as (as described in 3GPP TS 38.473, v16.2.0) egress BH RLC CHID IEs, but modified to carry a list of BHRLC channel ID IEs (as described in 3GPP TS 38.473, v16.2.0, section 9.3.1.113).
[0375] In the variant, a new exit BH RLC CH ID list IE is used to declare IE 814, 823, or 835, wherein the exit BH RLC CH ID list IE carries a list of BH RLC channel ID IEs (as described in Section 9.3.1.113).
[0376] In another variation, traffic mapping information IEs (IEs 814, 823, or 835) are used (as described in 3GPP TS 38.473, v16.2.0, section 9.3.1.95). Advantageously, as described in 3GPP TS 38.473, v16.2.0, the traffic mapping information IE is embedded in a BAP mapping configuration message or a UE context modification request message.
[0377] In some embodiments, Figure 8 All or part of the IEs shown are part of the BH routing information add-list IEs embedded in the BAP mapping configuration message, as described in 3GPP TS 38.473, v16.2.0.
[0378] In some embodiments, the IE of all portions of the IE that configures uplink traffic to the BH RLC channel mapping configuration table (i.e., the IE of entry 820) is transmitted in the GNB-CU configuration update message or F1 setting response message as defined in 3GPP TS 38.473, v16.2.0.
[0379] Using the enhanced backhaul route configuration table described above, the replication command 703 is associated with a route ID, which means that all data flows associated with that route ID will be processed according to the replication command.
[0380] However, it may be useful to specify which data flows are processed using BAP sublayer operations, while others should not. In this regard, it is recommended to provide access IAB nodes and IAB provider DUs with the ability to select appropriate route IDs (if the IAB nodes and IAB provider DUs prefer to apply / not apply the operation to the data flow). When configuring a downlink traffic-to-route-ID mapping configuration table for IAB nodes transmitting in the downlink direction and an uplink traffic-to-route-ID mapping configuration table for IAB nodes transmitting in the uplink direction, the IAB provider CU can assign a route ID to some data flows that will always be empty (replication command 703), while assigning different route IDs to other data flows that can later be processed by replication, network coding, or segmentation. However, for all these data flows, the default path to the destination IAB node can be the same. Such a configuration thus provides the flexibility to avoid systematically applying replication, network coding, or segmentation to all data flows transmitted on the same path.
[0381] In this variant, control over when to apply BAP sublayer operations can be dynamically driven by the IAB provider CU. Therefore, the IAB provider CU can send BAP sublayer operation enable / disable commands (protocol messages) to IAB nodes to enable or disable BAP sublayer operations for the BAP packets to be received. Thus, the initiator and terminater IAB nodes control whether or not to perform BAP sublayer operations based on the BAP sublayer operation enable / disable commands received from the IAB provider CU. Furthermore, when a BAP sublayer operation enable / disable command to be disabled is subsequently received from the IAB provider CU, the initiator or terminater may have already performed BAP sublayer operations (replication, network encoding, segmentation). This means that for the initiator, subsequently received BAP packets with the same BAP route ID are not transmitted through multiple RLC channels; these packets are not replicated, network encoded, or segmented. For the terminater, subsequently received redundant BAP packets are not processed to obtain a single original BAP packet; these packets are not reverse replicated or network decoded, but are all transmitted to the next-hop IAB node.
[0382] Preferably, the BAP sublayer operation enable / disable command is provided in association with the BAP route ID (or more information) that identifies the received BAP packet. This is to provide fine-grained control over the copying / network encoding / segmentation of some packet flows while others are not processed.
[0383] The BAP sublayer operation enable / disable command can be implemented using a dedicated information element (IE) (e.g., named Operation Enable IE). This command can include a Boolean value that, when true, declares the BAP sublayer operation enabled (and thus the IAB node acting as the initiator or terminator will apply the operation), and when false, declares the BAP sublayer operation disabled (and thus the IAB node will stop applying the operation).
[0384] One or more conditions can be associated with a BAP sub-level operation. One or more conditions must be met to enable or disable a BAP sub-level operation. For example, one or more conditions can be declared using a dedicated information element (IE) (e.g., called an operation condition IE), which is provided either in the same message as the command or in a separate message.
[0385] In the absence of declared conditions, BAP sublayer operations are applied immediately by the receiving IAB node (initiator or terminator) in response to receiving a command to enable (or disable) the operation.
[0386] Various conditions that trigger the enabling or disabling of BAP sublayer operations can be considered individually or in combination.
[0387] The first example condition involves timing information. Timing information defines when a BAP sublayer operation is enabled or disabled. For example, the start time can define when the initiator or terminating party begins, for instance, applying a BAP sublayer operation to a given BAP route ID. Similarly, the end time defines when the application of the operation stops. A dedicated IE, namely the timing-enabled IE, can be provided within the operation condition IE.
[0388] The second example condition involves a radio frame identifier. The radio frame identifier defines from which radio frame (including BAP packets) BAP sublayer operations are enabled or disabled. For example, a first radio frame #N can define a first radio frame from which the initiator or terminater begins applying BAP sublayer operations to the BAP packets contained in the frame, for example, against a given BAP route ID. Similarly, a second radio frame #M can define a last radio frame from which the initiator or terminater stops applying BAP sublayer operations to the BAP packets contained in the frame. A dedicated IE, namely the frame identifier IE, can be provided within the operation condition IE.
[0389] The third example condition involves the BAP packet identifier. The BAP packet identifier defines from which a received BAP packet enables or disables BAP sublayer operations. For example, the BAP packet identifier can rely on the sequence number used above. As an example, when the SN value of a received BAP packet (which was previously added by the IAB provider CU) equals the predefined initiating SN, the initiator or terminater begins to actually apply BAP sublayer operations to the BAP packet. In a variant, the initiator or terminater actually applies BAP sublayer operations to all BAP packets with SNs within a specific range. Similarly, when the SN value of a received BAP packet (which was previously added by the IAB provider CU) equals the terminating SN, the initiator or terminater stops applying BAP sublayer operations to BAP packets with a given BAP route ID. In a variant, the initiator or terminater does not actually apply BAP sublayer operations to BAP packets with SNs outside the range (or, in a variant, within another specific range). A dedicated IE, the packet identifier IE, can be provided within the operation condition IE.
[0390] The fourth example condition involves a BH link quality threshold. The BH link quality threshold defines from which link quality of the egress link enables or disables BAP sublayer operations. Specifically, the relevant egress link is the link corresponding to the BAP route ID associated with the BAP sublayer operation enable / disable command. For example, if the egress BH link normally used by the initiator (according to Table 500) for forwarding incoming packets experiences low quality (below the threshold), the initiator begins applying BAP sublayer operations to received BAP packets. Similarly, if the egress BH link normally used by the terminating party (according to Table 500) for forwarding incoming packets experiences low quality (below the threshold), the terminating party may not apply BAP sublayer operations to, for example, allow BAP packets to be copied. Conversely, when the egress BH link normally used by the initiator experiences better quality (above the threshold), the initiator may stop applying BAP sublayer operations.
[0391] Due to these various conditions, the IAB donor CU can trigger replication (or network encoding or partitioning) in various sub-parts of the IAB network at different times.
[0392] Furthermore, the IAB network can be made more intelligent. For example, nodes 601 and 604 can be declared as potential initiators of replication operations using different conditions. For instance, at different times of the day (e.g., estimated based on network occupancy), IAB donor 601 or IAB node 604 can perform replication, causing some BAP packets to be delivered or not delivered via BH links 612 and 626. Of course, other conditions mentioned above can be used to drive this intelligent control when enabling BAP sublayer operations at the IAB node level.
[0393] The configuration request message 903 described above can provide the receiving IAB node with an operation enabling IE (i.e., a BAP sublayer operation enable / disable command) and / or an operation condition IE. Message 903 may include or exclude the above-mentioned table or a portion thereof.
[0394] In some embodiments, configuration request message 903 is a BAP mapping configuration message, UE context setting request message, or UE context modification request message as defined in 3GPP TS 38.473, v16.2.0.
[0395] like Figure 9a As shown, the operation enable IE (i.e., BAP sublayer operation enable / disable command) and / or operation condition IE can be provided to the recipient IAB-DU 901 in the enable request message 950. This message can be appended (or not appended) to the configuration request 903, in which case the configuration request 903 does not include the operation enable IE and the operation condition IE. The recipient IAB-DU 901 responds with one or more enable response messages 951 to confirm the secure configuration.
[0396] Enable request message 950 can be an F1-AP message related to 3GPP TS 38.473.
[0397] In one embodiment, as described in 3GPP TS 38.473, v16.2.0, Sections 9.2.9.1 and 9.2.9.2, the enable request message 950 is a BAP mapping configuration message, and the enable response message 951 is a BAP mapping configuration confirmation message.
[0398] The operation enabling IE and operation condition IE can be declared as optional IEs in the BH routing information add-list IEs of the BAP mapping configuration message as described in 3GPP TS 38.473, v16.2.0. The corresponding declarations can be shown in Table 6a.
[0399] Table 6a
[0400]
[0401] Of course, the additional fields presented in Table 6 can be supplemented by those presented in Table 6a.
[0402] In the variant, as described in 3GPP TS 38.473, v16.2.0, Sections 9.2.2.21 and 9.2.2.2, the Enable Request message 950 is a UE Context Setting Request message, and the Enable Response message 951 is a UE Context Setting Response message.
[0403] In another variation, as described in 3GPP TS 38.473, v16.2.0, Sections 9.2.2.7 and 9.2.2.8, the Enable Request message 950 is a UE Context Modification Request message, and the Enable Response message 951 is a UE Context Modification Response message.
[0404] In yet another variation, the Enable Request message 950 is an RRC message as defined in 3GPP TS 38.331.
[0405] As still shown in the figure, the configuration request message 903 or the enable request message 950 responds to the status message 959 previously sent by the receiver IAB-DU 901.
[0406] Status message 959 can report the BH link quality level. For example, it indicates the SINR (Signal-to-Interference-to-Noise Ratio) level for all or part of the ingress and egress BH links corresponding to the receiver IAB-DU901. The SINR level can be the lowest SINR level among all BH links considered.
[0407] In the variant, status message 959 includes an explicit request from the receiver IAB-DU 901 to enable or disable BAP sublayer operations. This can be done using a dedicated operations enable request IE.
[0408] For example, status message 959 is a UL RRC message transmission message, as defined in 3GPP TS 38.401, section 8.2.4. UL RRC message transmission messages may include measurement report messages storing the measured SINR level.
[0409] The IAB donor CU 902 can therefore determine whether to enable or disable the BAP sublayer operation at the command receiver IAB-DU901 based on the received status message 959.
[0410] If the decision is to enable BAP sublayer operation requiring multiple BH egress links at the receiving IAB-DU 901, and the receiving IAB-DU 901 has only a single BH egress link, then the IAB donor CU 902, in response to receiving status message 959 and before sending enable request message 950, can implement the CU intra-topology redundancy procedure as defined in Section 8.2.4 of 3GPP TS 38.401 to establish redundant paths in the egress IAB topology from the receiving IAB-DU 901. Specifically, the IAB donor CU can establish at least one redundant egress path at the same IAB node before enabling BAP sublayer operation requiring two (or more) egress paths from the IAB node at the receiving IAB node.
[0411] The above example uses a dedicated message sent by the IAB donor CU to enable or disable BAP sublayer operations at the IAB node level.
[0412] In an alternative embodiment, the BAP sublayer operation enable / disable command is directly included in one of the received BAP packets for processing according to the operation. This advantageously links the command directly to a given BAP route ID (defined in the header of the BAP packet). Furthermore, the IAB donor CU can then notify the IAB-DU to enable or disable the operation without sending an enable request message 950 or its equivalent.
[0413] Figure 3 The format of the BAP package or PDU as described above is shown.
[0414] In some embodiments, bit 302 is used to transmit BAP sublayer operation enable / disable commands: the bit is set to true or 1 to enable BAP sublayer operation, and the bit is set to false or 0 to disable BAP sublayer operation. Of course, other bits can be used for the same purpose. Any IAB node transmitting a BAP packet with bit 302 set to 1 can use the BAP routing configuration described above to know whether BAP sublayer operation 703 (replication, network encoding, segmentation) must be applied to the BAP packet (and its corresponding route IDs 305+306), and, if so, which parameters 705 to use.
[0415] In other embodiments, bit 302 is used to signal whether the IAB node transmitting the BAP packet must parse field 307. For example... Figure 3a As shown, field 307 can include BAP routing configurations that define BAP sublayer operations performed when BAP sublayer operations are enabled. However, this is not mandatory. Field 307 can be part of the BAP header.
[0416] Bit 302 can correspond to the BAP sublayer operation enable / disable command as described above: the bit is set to true or 1 to enable BAP sublayer operation, and the bit is set to false or 0 to disable BAP sublayer operation. In this case, field 307 includes only fields 371 to 378, specifically for defining the BAP routing configuration for applying BAP sublayer operation.
[0417] Advantageously, field 307 can be provided in a series of consecutive BAP packets where bit 302 is set to true, so that various IAB nodes can know their roles (from field 307). Subsequent BAP packets may only have bit 302 set to true without field 307. These BAP packets are also processed through the BAP sublayer operation. Finally, one (or more) BAP packets with bit 302 set to false are sent, thus ending the BAP sublayer operation. All these BAP packets have the same route ID 305+306.
[0418] In a variant, bit 302 may simply indicate whether field 307 is provided (bit set to true or 1) or not provided (bit set to false or 0). In this case, field 307 includes fields 370 to 378, where field 370 is a single bit encoding a BAP sublayer operation enable / disable command: the bit is set to true or 1 to enable BAP sublayer operation, and the bit is set to false or 0 to disable BAP sublayer operation.
[0419] When bit 370 is set to false, fields 371 to 378 are optional. When bit 370 is set to true, all or some of fields 371 to 378 can become mandatory, as described below.
[0420] Field 371 provides the byte length of field 307.
[0421] Fields 372 to 376 provide BAP routing configuration for the relevant BAP sublayer operations. Advantageously, BAP routing configuration is defined for both the initiator and the terminator.
[0422] Field 372 indicates the BAP sublayer operation, namely, replication, network encoding, or splitting. This is similar to field 703 above, without the distinction between initiator and terminator.
[0423] Field 373 indicates the BAP address of the initiator IAB node used for the defined BAP sublayer operation. For example, this could be IAB node 604.
[0424] Field 374 indicates the BAP address of the terminating IAB node used for the defined BAP sublayer operation. For example, this could be IAB node 608.
[0425] Advantageously, when BAP packets are transmitted through IAB nodes, the IAB nodes can use fields 373 and 374 to determine which role it must play (initiator, terminator, or none).
[0426] Field 375 includes parameters used for BAP sublayer operations. Field 375 can be similar to IE 705 as described above.
[0427] Field 376 indicates a list identifying one or more next-hop BAP addresses for transmitting BAP packets generated by BAP sublayer operations defined in Field 372. Field 376 can be similar to IE714 for the initiator. Alternatively, Field 376 is similar to IE 704, in which case a conventional backhaul routing configuration table must be used to know the next-hop BAP address, and thus the egress BH link.
[0428] Optional field 377 provides one or more conditions for enabling / disabling BAP sublayer operation, such as the SINR level of the BH link. For example, optional field 377 includes the operation condition IE defined above.
[0429] Field 378 includes the sequence number as provided in the above embodiments: Field 378 is typically filled by the initiator and removed by the terminating party. The terminating party further uses Field 378 to identify (based on BAP sublayer operations) redundant packets to be processed in order to retrieve the original BAP packet.
[0430] Field 307 replaces the additional fields 703-705 / 713-715 of the enhanced backhaul routing configuration table in the above embodiments. In this case, the next-hop BAP address is obtained from field 376 (a conventional backhaul routing configuration table can be used). Then, a conventional BH RLC channel mapping configuration, an uplink traffic to BH RLC channel mapping configuration, or a downlink traffic to BH RLC channel mapping configuration table can be used. Figure 5 (b) to (d)) or the corresponding enhanced table ( Figure 8 Determine the exit BH RLC channel from the known exit BH links.
[0431] Now go to Figure 10 This illustrates an example method 1000 for managing the sequence number (SN) of a BAP packet at a BAP sub-layer of an IAB node. For example, in the case of nested packet replication at the IAB sub-layer, this method supports conditional insertion of the sequence number in the header of the BAP packet.
[0432] After the method initialization at step 1001, at step 1002, the IAB node waits for the arrival of the BAP packet for processing.
[0433] Upon receiving an incoming BAP packet, at step 1003, the IAB node reads the enhanced backhaul route configuration table (or alternatively, field 307 as described above) to determine at step 1004 which processing should be applied to the incoming BAP packet. Specifically, the IAB node reads IE 703 or 713 from the entry with IE 501 that matches the BAP route ID of the incoming BAP packet (or alternatively, field 372 combined with fields 373 or 374).
[0434] If redundant operations (such as copying or network encoding) are to be applied, the incoming BAP packet at step 1005 is transmitted together with parameter 705 (or alternatively, field 375) (such as network encoding coefficients) read from the table to the appropriate processing engine (such as a network encoder or decoder, or a copyer or decopyer).
[0435] The next step 1006 involves waiting for the processing of the incoming BAP packet to finish. If the processing cannot finish (e.g., packet loss for network decoding), the method loops back to step 1002 to process new incoming BAP packets.
[0436] Therefore, processing can end when all required BAP packets have been received and processed. In the case of reverse replication, the first received copy can be processed to generate the original BAP packet to be forwarded, and the serial number (SN) of that copy is stored. Subsequent copies with the same SN are discarded upon receipt.
[0437] When the process is complete, at step 1007, the IAB node obtains the resulting BAP packets (or multiple packets). In the case of a replication initiator, network coding initiator, or network coding terminator, there may be several resulting BAP packets.
[0438] After step 1007 or when no redundant operation is performed (step 1004), the IAB node checks whether the incoming or processed BAP packet has reached its destination.
[0439] This is the case when the DESTINATION field in the header corresponds to the BAP address of the IAB node. If the test is positive, the header is removed at step 1015 and the data portion of each BAP packet is sent to the upper layer.
[0440] If test 1008 is negative, it means that the BAP packet should be transmitted on one or more egress links and BH RLC channels as determined above (due to IE 704 or field 376 and the (uplink / downlink to) BH RLC channel mapping configuration table).
[0441] At step 1009, the IAB node determines the route ID to be set in the header of each outgoing BAP packet based on the information contained in the backhaul route configuration table (IE 704). If necessary, the header is updated with the new route ID to be used.
[0442] Next, at step 1010, the IAB node checks whether a sequence number should be inserted into the header of the outgoing BAP packet. This includes checking whether the sequence number insertion boolean information in parameter 705 or 375 is set to true (only for the initiator). If yes, SN insertion is performed at step 1011, as described above.
[0443] Otherwise, at step 1012, it is checked whether the serial number should be removed from the header. This includes checking whether the serial number removal boolean information in parameter 705 or 375 is set to true (only for the terminator). If yes, the removal is performed at step 1013 as described above.
[0444] If the serial number insertion / removal boolean information is set to false, then both tests 1010 and 1012 are negative, thus avoiding any modification to the SN.
[0445] Finally, at step 1014, an egress link is selected for each outgoing BAP packet based on the backhaul routing configuration table (where the IE 502 of the entry matches the BAP route ID of the packet). Additionally, a BH RLC channel is selected for each outgoing BAP packet using either a conventional or enhanced (uplink / downlink to) BH RLC channel mapping configuration table. The outgoing BAP packet is then transmitted to the next layer for delivery to the next-hop BAP node. The IAB node then loops back to step 1002.
[0446] Figure 11 A schematic representation of a communication device or station according to one or more exemplary embodiments of the present invention is shown.
[0447] The communication device 1100 may preferably be a device such as a microcomputer, workstation, or lightweight portable device. The communication device 1100 includes a preferably connected communication bus 1113.
[0448] - This refers to the central processing unit 1111 of the CPU, such as a microprocessor;
[0449] - Read-only memory 1107, denoted as ROM, stores a computer program that implements the present invention;
[0450] - A random access memory 1112, denoted as RAM, stores executable code of the method according to embodiments of the present invention, and registers suitable for recording variables and parameters required to implement the method according to embodiments of the present invention; and
[0451] - At least one communication interface 1102 connected to a radio communication network 100 (e.g., a wireless communication network according to 5G NR version 16) through which digital data packets or frames or control frames are transmitted. Under the control of a software application running in CPU 1111, frames are written from a FIFO transmit memory in RAM 1112 to the network interface for transmission, or read from the network interface for reception and written to a FIFO receive memory in RAM 1112.
[0452] Alternatively, the communication device 1100 may also include the following components:
[0453] - Data storage component 1104 (such as a hard disk) is used to store a computer program for implementing a method according to one or more embodiments of the present invention;
[0454] - A disk drive 1105 for disk 1106, the disk drive being adapted to read data from disk 1106 or write data to said disk;
[0455] - Screen 1109 is used to display the decoded data and / or serves as a graphical interface with the user using keyboard 1110 or any other indicating component.
[0456] Preferably, the communication bus provides communication and interoperability among various elements included in or connected to the communication device 1100. The representation of the bus is not limiting, and in particular, the central processing unit can operatively communicate instructions to any element of the communication device 1100, either directly or through other elements of the communication device 1100.
[0457] Disk 1106 can be optionally replaced by any information medium (such as a rewritable or non-rewritable compact disc (CD-ROM), ZIP disk, USB key, or memory card, etc.), and generally, it can be replaced by an information storage component that can be read by a microcomputer or microprocessor, integrated or not integrated into the device, may be portable, and is adapted to store one or more programs (the execution of the programs enables the implementation of the methods according to embodiments of the invention).
[0458] The executable code can be selectively stored in read-only memory 1107, on hard disk 1104, or on a removable digital medium, such as disk 1106 as described above. According to an optional variation, the executable code of the program can be received via communication network 1103, through interface 1102, and stored in one of the storage components of communication device 1100 (such as hard disk 1104) before being executed.
[0459] The central processing unit 1111 is preferably adapted to control and guide the execution of instructions or portions of software code of one or more programs according to the invention, which are stored in one of the aforementioned storage components. Upon power-up, one or more programs stored in non-volatile memory (e.g., in hard disk 1104 or read-only memory 1107) are transferred to random access memory 1112, which then contains executable code for one or more programs, as well as registers for storing variables and parameters required to implement the invention.
[0460] In a preferred embodiment, the device is a programmable device that implements the invention using software. However, alternatively, the invention can be implemented in hardware (e.g., in the form of an application-specific integrated circuit or ASIC).
[0461] Although the present invention has been described above with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications within the scope of the present invention will be apparent to those skilled in the art.
[0462] Many further modifications and variations will arise in those skilled in the art when referring to the foregoing illustrative embodiments. These embodiments are given by way of example only and are not intended to limit the scope of the invention, which is defined only by the appended claims. In particular, different features from different embodiments may be interchanged where appropriate.
[0463] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude plural. The fact that different features are defined only in mutually different dependent claims does not indicate that combinations of these features cannot be used advantageously.
Claims
1. A communication method in a wireless network, the wireless network including an integrated access and backhaul network, i.e., an IAB network, the method comprising: At the IAB node Receive BAP packets with the same Backhaul Adaptation Protocol routing identifier, i.e., BAP routing identifier. BAP routing configuration is used to perform BAP sublayer operations, which, for the same BAP routing identifier, determine multiple Radio Link Control (RLC) channels (i.e., multiple egress links) belonging to one or more egress links for the received BAP packets. BAP packets are transmitted through the multiple RLC channels. The transmission of BAP packets includes obtaining BAP packets that are redundant with the received BAP packets, and sending the redundant BAP packets through the plurality of RLC channels.
2. The method according to claim 1, wherein, The redundant BAP packet includes the received BAP packet and one or more copies thereof.
3. The method according to claim 2, further comprising: Add the same serial number to the received BAP packet and its copy.
4. The method according to claim 2, wherein, If the received BAP packet already includes a serial number, the received BAP packet and its copies retain that serial number without adding any other serial numbers.
5. The method according to claim 1, wherein, Obtaining the redundant BAP packets includes: performing network encoding on the received BAP packets.
6. The method according to claim 5, wherein, Redundant BAP packets resulting from network encoding of the same received BAP packet are marked with consecutive sequence numbers.
7. The method according to claim 1, further comprising: The BAP routing configuration determines whether a sequence number must be added to the redundant BAP packet compared to the received BAP packet.
8. A communication method in a wireless network, the wireless network including an integrated access and backhaul network, i.e., an IAB network, the method comprising: At the IAB node Receive redundant BAP packets (i.e., original BAP packets) through one or more ingress links. BAP sublayer operations are performed using BAP routing configuration, wherein the BAP sublayer operations determine whether to terminate BAP packet redundancy at the IAB node, and In cases where certainty is certain, redundant BAP packets are processed to obtain the original BAP packet, and a single original BAP packet is transmitted via the egress link, or the contents of the original BAP packet are transmitted to the upper layer of the IAB node. The process of handling the redundant BAP packets includes: identifying a copy of the original BAP packet and discarding the copy to keep a single copy as a single original BAP packet.
9. The method according to claim 8, wherein, Identifying a copy includes: recognizing received BAP packets marked with the same sequence number.
10. The method according to claim 8, wherein, Processing the redundant BAP packets includes: performing network decoding on the redundant BAP packets to obtain the original BAP packets.
11. The method according to claim 10, wherein, Receiving the redundant BAP packets includes: identifying received BAP packets marked with sequence numbers separated by a number less than the number of combinations defined by network decoding.
12. The method according to claim 8, further comprising: The BAP routing configuration determines whether the sequence number must be removed from the original BAP packet compared to the received redundant BAP packets.
13. The method according to claim 8, wherein, The BAP routing configuration includes a first configuration table consisting of entries that each associate a BAP routing identifier with a BAP address of another IAB node, wherein one or more entries corresponding to one or more BAP routing identifiers of a received BAP packet are further defined as BAP sublayer operations to be performed to obtain the original BAP packet from the received redundant BAP packet.
14. The method according to claim 13, wherein, The BAP routing configuration also includes a second configuration table consisting of entries that associate an egress link with one or more RLC channels, wherein the entry corresponding to the determined egress link is associated with multiple RLC channels.
15. The method according to claim 14, wherein, The entry corresponding to the determined egress link further includes a trigger field that defines one or more BAP route identifiers, wherein the plurality of RLC channels are to be used for the one or more BAP route identifiers.
16. A communication method in a wireless network, the wireless network including an integrated access and backhaul network, i.e., an IAB network, the method comprising: At the central unit of the IAB donor, i.e., the IAB donor CU. Send configuration messages to configure the IAB nodes of the IAB network using the corresponding Backhaul Adaptation Protocol routing configuration, i.e., BAP routing configuration. In one of the BAP routing configurations, an IAB node is configured as the initiator of a BAP sublayer operation. The initiator transmits received BAP packets with the same BAP routing identifier through multiple radio link control channels (RLC channels) belonging to one or more egress links. The transmission of BAP packets includes obtaining BAP packets that are redundant with the received BAP packets, and sending the redundant BAP packets through the plurality of RLC channels.
17. The method according to claim 16, wherein, Another BAP routing configuration in the BAP routing configuration configures another IAB node as the terminator of the same BAP sublayer operation, so as to process the received redundant BAP packets into original BAP packets and transmit a single original BAP packet through the egress link, or transmit the contents of the original BAP packet to the upper layer.
18. A wireless communication device comprising at least one microprocessor configured to perform the method according to any one of claims 1 to 17.
19. An integrated access and backhaul network system, namely an IAB network system, comprising an IAB donor central unit, an IAB donor distribution unit, and one or more IAB nodes, wherein one of the IAB donor distribution unit and the IAB node is configured to perform the method according to any one of claims 1 to 7.
20. The IAB network system according to claim 19, wherein, The other of the IAB donor distribution unit and the IAB node is configured to perform the method according to any one of claims 8 to 15.
21. A non-transitory computer-readable medium storing a program that, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform the method according to any one of claims 1 to 17.
22. A computer program product comprising a program that, when executed by a computer, implements the steps of the method according to any one of claims 1 to 17.