CN113573373B

CN113573373B - Standby service handling

Info

Publication number: CN113573373B
Application number: CN202110458961.7A
Authority: CN
Inventors: D·科齐欧; 许翔; E·马尔卡马基
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2020-04-28
Filing date: 2021-04-27
Publication date: 2023-10-10
Anticipated expiration: 2041-04-27
Also published as: WO2021217424A1; CN113573373A

Abstract

Example embodiments of the present disclosure relate to backup service processing. According to an embodiment of the present disclosure, a solution for backup service processing is provided. A backup radio bearer on the first link is established between the first device and the second device. If traffic cannot be transmitted on the second link, the radio bearer on the first link is used for traffic communication. In this way, there is no additional delay. Furthermore, there is no interruption of traffic communication, and the performance of communication is improved.

Description

Standby service handling

Technical Field

Embodiments of the present disclosure relate generally to the field of telecommunications and, in particular, relate to methods, apparatuses, devices and computer readable storage media for backup service processing.

Background

As communication systems develop, more and more technologies have been proposed. For example, since the new wireless (NR) system is expected to have a larger available bandwidth than the Long Term Evolution (LTE) system, it creates an opportunity for the fifth generation (5G) cellular network to develop and deploy an Integrated Access Backhaul (IAB) architecture, where the same infrastructure and spectrum resources will be used for both access and backhaul. This may allow for easier deployment of dense networks of NR cells in a more integrated manner by basing on the many control and data channels/procedures defined for providing access to the terminal device.

Disclosure of Invention

In general, example embodiments of the present disclosure provide a solution for backup service processing.

In a first aspect, a first apparatus is provided. The first apparatus comprises at least one processor and at least one memory including computer program code; the at least one memory and the computer program code are configured to, with the at least one processor, cause the first apparatus to: configuration information of at least one radio bearer on the first link is received from the second apparatus, the configuration information indicating at least one handover condition for switching traffic from the second link to the first link if the second link is not available. The first apparatus is further caused to determine whether at least one handover condition is satisfied when traffic is being transmitted over the second link. The first apparatus is further caused to communicate traffic between the first apparatus and the second apparatus using at least one radio bearer on the first link if the at least one condition is determined to be met.

In a second aspect, a second apparatus is provided. The second apparatus includes at least one processor and at least one memory including computer program code; the at least one memory and the computer program code are configured, with the at least one processor, to cause the second apparatus to transmit configuration information of at least one radio bearer on the first link to the first apparatus, the configuration information indicating at least one handover condition for a service handover from the second link to the first link. The second apparatus is further caused to communicate traffic between the first apparatus and the second apparatus using at least one radio bearer on the first link if the at least one handover condition is determined to be satisfied.

In a third aspect, a third apparatus is provided. The third apparatus includes at least one processor and at least one memory including computer program code; the at least one memory and the computer program code are configured to, with the at least one processor, cause the third apparatus to receive configuration information of at least one backup tunnel between the second apparatus and the third apparatus on the first link from the second apparatus. The third device is also caused to establish a backup tunnel between the second device and the third device over the first link. The third device is further caused to communicate traffic between the third device and the second device over the backup tunnel on the first link if at least one handoff condition is determined to be satisfied.

In a fourth aspect, a method is provided. The method includes receiving, at a first device, configuration information of at least one radio bearer on a first link from a second device, the configuration information indicating at least one handover condition for switching traffic from the second link to the first link if the second link is not available. The method further includes determining whether at least one condition is satisfied when traffic is being transmitted over the second link. The method also includes transmitting traffic between the first device and the second device using at least one radio bearer on the first link if at least one handover condition is determined to be satisfied.

In a fifth aspect, a method is provided. The method includes, at a second apparatus, transmitting configuration information of at least one radio bearer on a first link to a first apparatus, the configuration information indicating at least one handover condition for handing over traffic from the second link to the first link. The method also includes transmitting traffic between the first device and the second device using at least one radio bearer on the first link if at least one handover condition is determined to be satisfied.

In a sixth aspect, a method is provided. The method includes receiving, at a third device, configuration information of at least one backup tunnel between a second device and the third device on a first link from a second device. The method also includes establishing at least one backup tunnel between the second device and the third device over the first link. The method also includes transmitting traffic between the third device and the second device over the backup tunnel on the first link if at least one handoff condition is determined to be satisfied.

In a seventh aspect, a first apparatus is provided. The first device comprises: means for receiving configuration information of at least one radio bearer on the first link from the second apparatus, the configuration information indicating at least one handover condition for handing over traffic from the second link to the first link if the second link is not available; means for determining whether at least one condition is met when traffic is being transmitted over the second link; and means for transmitting traffic between the first device and the second device using at least one radio bearer on the first link if it is determined that the at least one handover condition is satisfied.

In an eighth aspect, a second apparatus is provided. The second device includes: means for transmitting configuration information of at least one radio bearer on the first link to the first apparatus, the configuration information indicating at least one handover condition for handing over traffic from the second link to the first link; and means for transmitting traffic between the first device and the second device using at least one radio bearer on the first link if the at least one handover condition is determined to be satisfied.

In a ninth aspect, a third apparatus is provided. The third device includes: means for receiving configuration information of at least one backup tunnel between a second device and a third device on a first link from a second device; means for establishing at least one backup tunnel between the second device and a third device over the first link; and means for transmitting traffic between the third device and the second device on at least one backup tunnel on the first link if it is determined that traffic cannot be transmitted on the second link.

In a tenth aspect, a computer readable medium is provided. The computer readable medium comprising program instructions for causing an apparatus to perform at least the method according to any one of the fourth, fifth or sixth aspects described above.

It should be appreciated that the "summary of the invention" section is not intended to identify key or essential features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

Some example embodiments will now be described with reference to the accompanying drawings, in which:

FIG. 1 illustrates an example communication environment in which some embodiments of the present disclosure may be implemented;

fig. 2A-2C illustrate block diagrams of different scenarios involving an IAB node, according to some example embodiments of the present disclosure;

fig. 3 illustrates signaling flows for backup traffic processing according to some embodiments of the present disclosure;

fig. 4A and 4B illustrate block diagrams of an IAB node system, respectively, according to some example embodiments of the present disclosure;

fig. 5 illustrates a flowchart of a method implemented at a first apparatus according to some other example embodiments of the present disclosure;

fig. 6 illustrates a flowchart of a method implemented at a second apparatus according to some other example embodiments of the present disclosure;

fig. 7 illustrates a flowchart of a method implemented at a third apparatus according to some other example embodiments of the present disclosure;

FIG. 8 illustrates a simplified block diagram of an apparatus suitable for practicing the example embodiments of the present disclosure; and

Fig. 9 illustrates a block diagram of an example computer-readable medium, according to some example embodiments of the present disclosure.

The same or similar reference numbers will be used throughout the drawings to refer to the same or like elements.

Detailed Description

Principles of the present disclosure will now be described with reference to some example embodiments. It should be understood that these embodiments are described for illustrative purposes only and to assist those skilled in the art in understanding and practicing the present disclosure without imposing any limitation on the scope of the present disclosure. The embodiments described herein may be implemented in various other ways, except as described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

References in the present disclosure to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It will be understood that, although the terms "first" and "second" may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term "and/or" includes any and all combinations of one or more of the listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "has," "including," "has," "having," "containing," and/or "including" when used herein, specify the presence of stated features, elements, and/or components, but do not preclude the presence or addition of one or more other features, elements, components, and/or groups thereof.

As used herein, the term "circuitry" may refer to one or more or all of the following:

(a) Pure hardware circuit implementations (such as implementations in analog and/or digital circuitry only); and

(b) A combination of hardware circuitry and software, such as (as applicable):

(i) Combination of analog and/or digital hardware circuitry and software/firmware, and

(ii) Any portion of a hardware processor, software, and memory having software (including digital signal processors) that work in concert to cause a device, such as a mobile phone or server, to perform various functions; and

(c) Software (e.g., firmware) is required to run but may not exist as hardware circuitry and/or a processor, such as a microprocessor or portion of a microprocessor, when operation is not required.

This definition of "circuitry" applies to all uses of this term in this disclosure, including in any claims. As another example, as used in this disclosure, the term "circuitry" also encompasses an implementation of a pure hardware circuit or processor (or processors) or a hardware circuit or processor and portions of its (or their) accompanying software and/or firmware. The term "circuitry" also encompasses, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other computing or network device.

As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as New Radio (NR), long Term Evolution (LTE), LTE-advanced (LTE-a), wideband Code Division Multiple Access (WCDMA), high Speed Packet Access (HSPA), narrowband internet of things (NB-IoT), and the like. Furthermore, the communication between the terminal device and the network device in the communication network may be performed according to any suitable generation communication protocol, including, but not limited to, first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, fifth generation (5G) communication protocols, and/or any other protocol currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. In view of the rapid development of communications, there will, of course, also be future types of communication technologies and systems that may embody the present disclosure. The scope of the present disclosure should not be limited to only the above-described systems.

As used herein, the term "network device" or "network node" refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a Base Station (BS) or Access Point (AP), e.g., a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), an NR NB (also referred to as a gNB), an NR NB distributed unit (also referred to as a gNB DU), an NR NB centralized unit (also referred to as a gNB CU), a Remote Radio Unit (RRU), a Radio Header (RH), a Remote Radio Head (RRH), relay, integrated Access and Backhaul (IAB) nodes, low power nodes such as femto, pico, non-terrestrial network (NTN) or non-terrestrial network devices such as satellite network devices, low Earth Orbit (LEO) satellites, and Geosynchronous Earth Orbit (GEO) satellites, aircraft network devices, etc., depending on the terminology and technology applied.

The term "terminal device" refers to any terminal device that may be capable of wireless communication. By way of example, and not limitation, a terminal device may also be referred to as a communication device, user Equipment (UE), subscriber Station (SS), portable subscriber station, mobile Station (MS), or Access Terminal (AT). The terminal devices may include, but are not limited to, mobile phones, cellular phones, smart phones, voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal Digital Assistants (PDAs), portable computers, desktop computers, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, notebook computer embedded devices (LEEs), laptop computer mounted devices (LMEs), USB dongles, smart devices, wireless Consumer Premise Equipment (CPE), internet of things (loT) devices, watches or other wearable devices, head Mounted Displays (HMDs), vehicles, drones, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in an industrial and/or automated processing chain environment), consumer electronic devices, devices operating on a commercial and/or industrial wireless network, and the like. In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" may be used interchangeably.

As described above, the IAB technique has been proposed. In an IAB environment, there may be at least an IAB Donor (Donor) node (e.g., including a Donor centralized unit Donor CU and a Donor distributed unit Donor DU) as a 5G base station and one or more IAB nodes as 5G relay stations. At least an IAB node may be present. An IAB node may be connected to an upstream IAB node or an IAB donor node via a subset of the UE functions of the NR Uu interface, referred to as IAB-MT functions of the IAB node. The node to which the IAB node may be connected in the upstream direction may be referred to as a parent node or an IAB parent node. The IAB node may provide a wireless backhaul to downstream IAB nodes and UEs via network functions of the NR Uu interface (referred to as IAB-DU functions of the IAB node). The node to which the IAB node is connected in the downstream direction may be referred to as a child node or an IAB child node. One or more wireless Backhaul (BH) Radio Link Channels (RLC) are established between an IAB node and its child IAB node and between an IAB node and its parent node. Traffic of one or more UEs or one or more IABs may be mapped to the same or different BH RLC channels. In NR IAB, the mobility of IAB has been introduced, so that the IAB topology can be flexibly adapted when needed, e.g. due to changing network load conditions or radio environment and condition changes. Accordingly, a handover (handover) procedure may be used to change a parent node of an IAB node to another parent node. In an IAB, a Radio Resource Control (RRC) or Packet Data Convergence Protocol (PDCP) layer is typically not present in an IAB node. The RRC and PDCP functions of the access UE connected to the IAB node are provided by the IAB donor CU. According to conventional techniques, data is forwarded in an Xn interface between a source network device and a target network device.

In general, to use a wireless backhaul, network device(s) need to be configured or enabled with information of the wireless backhaul. For example, for bearer or Backhaul (BH) Radio Link Channel (RLC) mapping, a Backhaul Adaptive Protocol (BAP) entity in the network device may perform mapping to an egress logical channel or egress BH RLC channel based on the BH RLC channel mapping configuration. Regarding routing, BAP entities in network devices may perform routing based on backhaul routing configurations. In another example, some other type of mapping configuration and/or routing configuration may be applied.

In addition, a technology called multi-radio dual connectivity (MR-DC) was developed. In a multi-radio dual connectivity (MR-DC), a UE with multiple receive/transmit (Rx/Tx) capability may be configured to utilize resources provided by two different nodes, one providing NR access and the other providing E-UTRA or NR access. One node acts as a Master Node (MN) and the other node acts as a Slave Node (SN). The MN and SN are connected via a network interface (e.g., an X2 interface or an Xn interface), and at least the MN is connected to the core network. In this dual connectivity feature, the terminal device may take advantage of both LTE and 5G connectivity. The proposal is exemplified for MR-DC but may also be used in other dual connectivity, for example when the MN or SN uses other 3GPP access technologies or non-3 GPP access technologies.

MR-DC may also be applied to the IAB node. If the IAB node is deployed in EN-DC mode, an IAB mobile terminal (IAB-MT) has a connection with the eNB as its primary node, while the IAB-MT is also connected with the NR gNB as the secondary node. The NR gNB may be an IAB node or a donor-DU. When Backhaul (BH) traffic uses an NR link, it maintains an RRC connection with the eNB. In addition, since LTE links are considered to be more robust and stable, it is agreed that F1 application protocol (F1 AP) signaling over LTE links is supported in addition to F1AP signaling over NR BH links. NR-DC can also be applied to IAB nodes. If the IAB node is deployed in NR-DC mode, an IAB mobile terminal (IAB-MT) has a connection with an NR gNB as its primary node, and the IAB-MT is also connected with another NR gNB as a secondary node. The NR gNB may be an IAB node or a Donor-DU.

In MR-DC, MN and SN may use the same or different frequency bands. For example, it is well known that for 5G new radios, 5G typically uses various frequency bands in a range known as frequency range 1 (FR 1) (e.g., below 7.225GHz or below 6 GHz) and FR2 (e.g., above 24.250 GHz). It is envisaged that the frequency band in FR1 may carry many conventional cellular mobile communications services. The higher frequency band in FR2 is intended to provide short range ultra-high data rate capability for 5G radios. In general, for the IAB EN-DC or NR-DC modes, it has been assumed that user plane backhaul traffic is transmitted using the FR2 link between the IAB-MT and the secondary node, while the FR1 frequency (on LTE or NR) is used only to control traffic signaling between the IAB-MT and the primary node, such as RRC and F1AP. In an example embodiment, MN and SN may also use the same frequency band, such as FR1 or FR2, or any other combination of FR1 and FR 2. When the IAB uses MR-DC, the BAP layer may be configured in only one communication link, e.g., an intermediate node between the IAB node and the secondary node and between the IAB node and the secondary node. BAP is not configured in other communication links between IAP nodes and the master node. With this configuration, backhaul traffic can only be transmitted over BAP-enabled communication links.

According to conventional techniques, if a transmission failure occurs on a communication link for backhaul traffic, the communication device may wait for a period of time until the link recovers and then continue to transmit backhaul traffic. Alternatively, the communication device may connect to another base station supporting wireless backhaul and then use the new BH link for backhaul traffic transmission. However, conventional techniques such as RRC re-establishment procedures may introduce additional delay and may affect traffic requiring low delay.

In order to solve at least some of the above problems. A solution is needed for backup service handling. According to an embodiment of the present disclosure, a solution for backup service processing is provided. A backup radio bearer is established over a first link between a first device and a second device. If traffic cannot be transmitted on the second link, the radio bearer on the first link is used for traffic communication. In this way, there is no additional delay. Furthermore, there is no interruption of traffic communication, and the performance of communication is improved.

Fig. 1 illustrates a schematic diagram of a communication environment 100 in which embodiments of the present disclosure may be implemented, according to some example embodiments of the present disclosure. The communication environment 100, which is part of a communication network, includes a first device 110, a second device 120, a third device 130, and a fifth device 150. It should be noted that the number of devices shown in fig. 1 is merely an example and not limiting. The first device 110, the second device 120, the third device 130, and the fifth device 150 may be network devices. For illustration purposes only, the first device 110 may be referred to as an IAB node; the second device 120 may refer to a master node, which may be an eNB or a gNB, or any other type of network device; the third device 130 may refer to a secondary node, which may be an IAB donor. As shown in fig. 1, the first device 110 may be a parent node of the fifth device 150. In the communication environment 100, the first device 110, the second device 120, the third device 130, and the fifth device 150 may communicate data and control information with each other. It should be noted that the first device 110, the second device 120, the third device 130, and the fifth device 150 are interchangeable.

The communication environment 100 includes devices 140-1, 140-2, 140-3, … …, network devices 140-N, which may be collectively referred to as "fourth devices 140". For example, as shown in fig. 1, the fourth device 140 may be in communication with the first device 110. The first device 110 may also communicate with the second device 120, the fifth device 150, and the third device 130 via a backhaul.

Communication environment 100 may include any suitable number of devices and cells. In the communication environment 100, the first device 110 and the fourth device 140 may communicate data and control information with each other. In the case where the first device 110 hosts the base station functionality or some base station functionality (e.g., the gNB functionality or gNB-DU functionality) of the fourth device 140, the link from the fourth device 140 to the first device 110 is referred to as the Uplink (UL), while the link from the first device 110 to the fourth device 140 is referred to as the Downlink (DL). The fourth device 140 and the first device 110 are interchangeable.

It should be understood that the number of first devices and units shown in fig. 1 and their connections are given for illustrative purposes and are not meant to be limiting. Communication environment 100 may include any suitable number of devices and networks suitable for implementing embodiments of the present disclosure.

Communication in communication environment 100 may be implemented in accordance with any suitable communication protocol including, but not limited to, first generation (1G), second generation (2G), third generation (3G), fourth generation (4G), fifth generation (5G), etc., cellular communication protocols, wireless local area network communication protocols such as Institute of Electrical and Electronics Engineers (IEEE) 802.11, and/or any other protocols currently known or developed in the future. Moreover, the communication may utilize any suitable wireless communication technology, including, but not limited to: code Division Multiple Access (CDMA), frequency Division Multiple Access (FDMA), time Division Multiple Access (TDMA), frequency Division Duplex (FDD), time Division Duplex (TDD), multiple Input Multiple Output (MIMO), orthogonal Frequency Division Multiplexing (OFDM), discrete fourier transform spread spectrum OFDM (DFT-s-OFDM), and/or any other technique currently known or developed in the future.

Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. Fig. 2A-2C illustrate block diagrams of different scenarios in which some example embodiments of the present disclosure may be implemented. As shown in fig. 2A-2C, the first device 110 is a parent node of the fifth device 150, which also means that the first device 110 is an intermediate node between the third device 130 (i.e., IAB-donor) and the fifth device 150. The second device 120 may have both a control plane connection and a user plane connection with the core network device 210. The third device 130 may also have both control plane and user plane connections with the core network device 210 or may have only user plane connections with the core network device 210. The core network device 210 may be a device at an evolved packet core or a device at a next generation core.

For example, as shown in fig. 2A, the fifth device 150 may use dual connectivity with the second device 120 (referred to as a primary node) and the first device 110 (referred to as a secondary node). The traffic of the fourth device 140-3 may include downlink traffic transmitted to the fourth device 140-3 and uplink traffic received from the fourth device 140-3. Traffic of the fourth device 140-3 may use the second link. The second link may refer to a communication link that includes a connection 2010 between the fifth device 150 and the first device 110 and a connection between the first device 110 and the third device 130. In an example embodiment, the second link may be a BAP-enabled link, which means that devices of the second link support BAP and have associated configurations (e.g., mapping configuration and routing configuration) of BAP. In another example embodiment, some other type of mapping configuration and/or routing configuration may be applied. The fifth device 150 may have established one or more backup radio bearers 220 with the second device 120. The backup radio bearer may be one or more radio bearers (DRBs).

The second device 120 may also establish a user plane tunnel or connection 260, e.g., one or more GTP-U tunnels, with the third device 130. Connection 260 may be an X2 connection for the EN-DC case or an Xn connection for the NR-DC case. Connection 260 may be associated with alternate radio bearer 220. For example, it may be a one-to-one mapping between the backup radio bearer and the GTP-U tunnel. The first link refers to a communication link comprising a backup radio bearer 220 between the fifth device 150 and the second device 120 and a user plane tunnel or connection 260 between the second device 120 and the third device 130. In an example embodiment, while the second link may support BAP or any other type of bearer or BH RLC channel mapping configuration and/or routing configuration, the first link may not support, meaning that at least some devices of the first link (e.g., second device 120) may not support and there is no configuration associated with the devices of the second link. There may be a failure on the second link, for example, a failure of the connection 2010 between the first device 110 and the fifth device 150. In this case, if a connection failure between the fifth device 150 and its parent node (i.e., the first device 110) is detected, traffic received from and transmitted to the fourth device 140-3 may begin using the first link, e.g., using the backup radio bearer 220 established between the fifth device 150 and the second device 120 and the GTP-U tunnel 260 established between the second device 120 and the third device 130.

In the uplink direction, traffic received from the fourth device 140-3 may be sent from the fifth device 150 to the second device 120 via the backup radio bearer 220 and may then be sent from the second device 120 to the third device 130 via the GTP-U tunnel 260. In the downlink direction, traffic to the fourth device 140-3 may be sent from the third device 130 to the second device 120 via the GTP-U tunnel 260 and then may be sent from the second device 120 to the fifth device 150 via the backup radio bearer 220. By switching to the first link, the fourth device 140-3 is not affected by a connection failure of the second link (e.g., a failure of the connection between the fifth device 150 and its parent node (i.e., the first device 110)). In one example, only a portion of traffic originally sent via the second link is switched to the first link, e.g., only high priority traffic. In another example, all traffic originally sent via the second link is switched to the first link.

In some embodiments, a first link may have been established as shown in fig. 2B, including one or more backup radio bearers 230 between the first device 110 and the second device 120 and a user plane tunnel or connection 260 between the second device 120 and the third device 130. Connection 260 may be an X2-U connection for the EN-DC case or an Xn-U connection for the NR-DC case. Connection 260 is associated with backup radio bearer 220. For example, it may be a one-to-one mapping between the backup radio bearer and the X2/Xn GTP-U tunnel.

The first link may refer to a communication link comprising a backup radio bearer 230 between the first device 110 and the second device 120 and a user plane tunnel or connection 260 between the second device 120 and the third device 130. The second link may refer to a communication link that includes a connection 2020 between the first device 110 and the third device 130. In an example embodiment, while the second link may support BAP or any other type of bearer or BH RLC channel mapping configuration and/or routing configuration, the first link may not support, meaning that at least some devices of the first link (e.g., second device 120) may not support and there is no configuration associated with the devices of the second link.

Traffic transmitted/received via the first device 110 may use the second link. The traffic may include traffic to/from the first device 110 (e.g., traffic related to the fourth device 140-1) and traffic to/from sub-devices of the first device 110 (e.g., traffic to/from the fifth device 150). Traffic to/from the sub-device may also include traffic related to devices connected to the sub-device. For example, traffic to/from the fifth device 150 includes traffic related to the fourth device 140-3. A failure occurs on the second link, for example, a failure of connection 2020 between first device 110 and third device 130. Traffic sent/received via the first device 110 may begin using the first link, e.g., using the backup radio bearer 230 established between the first device 110 and the second device 120 and the GTP-U tunnel 260 established between the second device 120 and the third device 130. Traffic to be handed over to the first link may include at least traffic to be sent to fifth device 150 and traffic to be received from fifth device 150 on at least some BH RLC channels between first device 110 and fifth device 150. Traffic to/from the first device 110 may include at least some of the traffic sent to the connected device (e.g., the fourth device 140-1) and at least some of the traffic received from the connected device (e.g., the fourth device 140-3) of the fifth device 150. By switching to the first link, the device connected to the first device 110 (e.g., the fourth device 140-1), the child device of the first device 110 (e.g., the fifth device 150), and the device connected to the child device of the first device 110 (e.g., the fourth device 140-3) are not affected by the connection failure between the first device 110 and its parent node (i.e., the third device 130). In one example, only a portion of traffic originally sent via the second link is switched to the first link, e.g., only high priority traffic. In another example, all traffic originally sent via the second link is switched to the first link.

Further, as shown in fig. 2C, the first device 110 and the fifth device 150 may have established a first link with the second device 120 that includes the backup radio bearers 240 and 250 and may have established a user plane tunnel or connection 260 between the second device 120 and the third device 130. Connection 260 may be an X2-U connection for the EN-DC case or an Xn-U connection for the NR-DC case. Connection 260 may be associated with alternate radio bearer 220. For example, it may be a one-to-one mapping between the backup radio bearer and the X2/Xn GTP-U tunnel. The first link may refer to a communication link that includes a backup radio bearer 240 (or 250) between the first device 110 (or fifth device 150) and the second device 120 and a user plane tunnel or connection 260 between the second device 120 and the third device 130.

The second link may refer to a communication link comprising a connection with the third device 130. For example, the second link of the first device 110 may be a connection 2020 between the first device 110 and the third device 130, and the second link of the fifth device 150 may include a connection 2020 between the first device 110 and the third device 130 and a connection between the fifth device 150 and the first device 110. In an example embodiment, while the second link may support BAP or any other type of bearer or BH RLC channel mapping configuration and/or routing configuration, the first link may not support, meaning that at least some devices of the first link (e.g., second device 120) may not support and there is no configuration associated with the devices of the second link.

Traffic transmitted/received via the first device 110 and/or the fifth device 150 may use the second link. The traffic may include traffic to/from the first device 110 (e.g., traffic related to the fourth device 140-1) and traffic to/from sub-devices of the first device 110 (e.g., traffic to/from the fifth device 150). Traffic to/from the sub-device may also include traffic related to devices connected to the sub-device. For example, traffic to/from the fifth device 150 may include traffic related to the fourth device 140-3. There may be a fault on the connection 2020 between the first device 110 and the third device 130. Traffic to/from the first device 110 may begin using the first link, e.g., using the backup radio bearer 240 and the GTP-U tunnel 260 between the second device 120 and the third device 130.

Further, the first device 110 may send a Backhaul (BH) Radio Link Failure (RLF) notification to its child node, i.e., the fifth device 150. Based on the BH RLF notification, the fifth device 150 may also determine to begin using the first link for some or all of the traffic, e.g., using the backup radio bearer 250 established between the fifth device 150 and the second device 120 and the GTP-U tunnel 260 established between the second device 120 and the third device 130. As a result, traffic to/from the first device 110 and traffic to/from the fifth device 150 may both begin using the first link, e.g., using the alternate radio bearers 240 and 250.

By switching to the first link, the device connected to the first device 110 (e.g., the fourth device 140-1), the child device of the first device 110 (e.g., the fifth device 150), and the device connected to the child device of the first device 110 (e.g., the fourth device 140-3) are not affected by the connection failure between the first device 110 and its parent node (i.e., the third device 130). In one example, only a portion of traffic originally sent via the second link is switched to the first link, e.g., only high priority traffic. In another example, all traffic originally sent via the second link is switched to the first link.

Referring now to fig. 3, fig. 3 illustrates a signaling flow 300 for traffic processing according to some example embodiments of the present disclosure. For discussion purposes, the process 300 will be described with reference to FIG. 1. The signaling flow 300 may involve the first device 110, the second device 120, and the third device 130. In an example embodiment, the second device 120 and the third device 130 may be configured with BAP related configurations, such as a bearer mapping configuration and a routing configuration. It should be noted that embodiments of the present disclosure may also be applied to links on other suitable layers. The BAP layer is merely an example for purposes of illustration and not limitation. At least one of the first link and the second link is a BAP-based link. For example, both the first link and the second link may be BAP-based links. Alternatively, the first link may be a non-BAP based link, which means that the first link is not BAP enabled or configured with BAP. In other embodiments, the second link may be a non-BAP based link. It should be noted that embodiments of the present disclosure may be applied to any suitable type of link.

The second device 120 sends 3005 configuration information for one or more radio bearers of the first link. The first link includes the backup radio bearer(s) established between the first device 110 and the second device 120 and the backup tunnel(s) established between the second device 120 and the third device 130. The backup tunnel may be one or more GTP-U tunnels. A second link is established between the first device 110 and the third device 130. The configuration information includes a radio bearer configuration and also indicates one or more handover conditions for handover from the second link to the first link, e.g., if the second link is not available. The configuration information may also include, for example, conditions for switching back from the first link to the second link if the second link was successfully restored and available. One or more radio bearers may be used for the uplink. Alternatively, one or more radio bearers may be used for the downlink. In some embodiments, the first link and the second link may be uplinks. Alternatively, the first link and the second link may be downlink.

In some example embodiments, the first link may be in FR1 and the second link may be in FR 2. Alternatively, the first link may be in FR2 and the second link may be in FR 1. In other embodiments, the first link may be associated with a macro cell and the second link may be associated with a small cell having limited transmission power. In other embodiments, the first link may be associated with a primary node and the second link may be associated with a secondary node. It should be noted that the first link and the second link may be in any suitable frequency band that may be higher or lower than FR1 and/or FR 2. In some embodiments, the first link and the second link may be in the same frequency band. Embodiments of the present disclosure are not limited in this respect. Packet Data Convergence Protocol (PDCP) layers 4010-1 and 4010-2 may be used to establish radio bearers. In this way, resource efficiency on the first link may be improved. The data carried by the backup data radio bearer of the first link may be bonded to the BH RLC channel. In some embodiments, for example, for N between N radio bearers and one BH RLC channel: 1, multiple UE bearers (from the same or different UEs) are mapped to a single BH RLC channel, which may be referred to as an aggregated BH RLC channel, and a backup data radio bearer may be established for the aggregated BH RLC channel. For N:1 mapping, no further aggregation may be needed when the BH RLC channel is mapped to a standby DRB.

Alternatively, for example, for 1 between one radio bearer and one BH RLC channel: 1 mapping, additional rules are required to aggregate multiple BH RLC channels into one spare DRB. UE bearers (e.g., DRBs) and BH RLC channel 1: the 1 mapping case indicates that each UE bearer has a dedicated BH RLC channel. For 1:1 mapping, there may be multiple BH RLC channels, which means that the standby DRBs need some sort of aggregation, as the number of DRBs is typically limited.

In some example embodiments, the handover condition may include detection of a backhaul failure on the second link. Alternatively or additionally, detection of a beam failure on the second link may also trigger a handover. In other example embodiments, the handover condition may further include an initialization of beam fault recovery on the second link. In some example embodiments, unsuccessful RRC re-establishment on the second link may be considered a handover condition.

The handover condition may also relate to the link quality between the first device 110 and the third device 130. For example, if the link quality between the first device 110 and the third device 130 on the second link is below a threshold quality, a handover condition is determined to be met. In other embodiments, the handover condition may include an indication received from the primary node or the secondary node (e.g., the second device 120 or the third device 130). The handoff condition may also include an indication (e.g., RLF indication) from its parent device (e.g., device 130).

Alternatively or additionally, the configuration information may include a traffic type that may utilize the backup radio bearer. For example, the configuration information may include an identifier of a terminal device that may use the backup radio bearer or an identifier of the UE bearer. Alternatively, the logical channel identifier may also be included in the configuration information. In some embodiments, the traffic type may be indicated by one or more general packet radio system tunneling protocol user plane (GTP-U) fully qualified tunnel endpoint identifiers (F-TEIDs). A 5G quality of service (QoS) identifier (5 QI) value or a Differentiated Services Code Point (DSCP) or IPv6 flow label or BH RLC channel identity may also be used to indicate the traffic type. In addition, the configuration information may also include a BH RLC channel identifier that may be used to identify backhaul traffic between the first device 110 and a sub-device (e.g., fifth device 150). The identified backhaul traffic is to be transmitted via a first link when the handover condition is met or via a second link when the handover condition is met.

The second device 120 may be a master node. Fig. 4A illustrates a block diagram of a standby radio bearer terminating in a primary node when NR-DC is used according to some example embodiments of the present disclosure. Fig. 4B illustrates a block diagram of a standby radio bearer terminating in a secondary node when NR-DC is used in accordance with some example embodiments of the present disclosure. As shown in fig. 4A and 4B, there may be PDCP layers 4010 (e.g., 4010-1, 4010-2, 4010-3, 4010-4, and 4010-5), xn-U layers 4020 (e.g., 4020-1 and 4020-2), SDAP layers 4030 (e.g., 4030-1, 4030-2, and 4030-3), F1-U layers (e.g., 4050-1 and 4050-2), user Datagram Protocol (UDP) layers (e.g., 4060-1 and 4060-2), IP layers (e.g., 4070-1 and 4070-2), RLC layers (e.g., 4080-1 and 4080-2), media Access Control (MAC) layers 4081 (e.g., 4081-1 and 4081-2), and Physical (PHY) layers 4082 (e.g., 4082-1 and 4082-2). It should be noted that the devices shown in fig. 4A and 4B may have other layers omitted for clarity. It should also be noted that the block diagrams shown in FIGS. 4A and 4B are for NR-DC, but the block diagram for EN-DC using X2-U instead of Xn-U and without SDAP layer is similar. Embodiments of the present disclosure are described with reference to fig. 4A and 4B.

The second device 120 may send 3010 the configuration information to the third device 130. The configuration information may include one or more handover conditions for switching from the second link to the first link, e.g., if the second link is not available. The configuration information may also include conditions for switching back from the first link to the second link, for example, if the second link is successfully recovered and available.

In some embodiments, if the backup radio bearer terminates in the primary node (e.g., the second device 120), a backup tunnel may be established between the second device 120 and the third device 130. For example, the second device 120 may send 3010 configuration information for the tunnel to the third device 130, e.g., GTP-U F-TEID(s) allocated by the second device 120, and the third device 130 may establish at least one backup tunnel with the second device 120, e.g., by including GTP-U F-TEID(s) allocated by the third device 130. The backup tunnel may be one or more GTP-U tunnels. The configuration information may indicate that the tunnel is for traffic communicated on the backup radio bearer. For example, the configuration information may include a flag so that the third device 130 may understand that traffic from the backup tunnel should be handled in a particular manner. As shown in FIG. 4A, xn-U module 4020-1 in second device 120 and Xn-U module 4020-2 in third device 130 may establish at least a GTP-U tunnel over the Xn-U interface. For the EN-DC case, X2-U module 4020-1 in second device 120 and X2-U module 4020-2 in third device 130 may establish at least a GTP-U tunnel over the X2-U interface. The second device 120 may configure the first device 110 on which the standby radio bearer is to be used for traffic (e.g., specific F1-U traffic). The configuration information to the third device 130 may further include information for identifying a traffic type that can use the first link when the handover condition is satisfied. The identity of the traffic may include one or more of a GTP-U fully qualified TEID (F-TEID), a Differentiated Services Code Point (DSCP), or an IPv6 flow label or a 5QI value or a UE identifier or a UE bearer identifier.

Alternatively, if the backup radio bearer terminates in the secondary node (e.g., third device 130), as shown in fig. 4B, backup tunnel establishment may not be required and a normal tunnel may be used, e.g., an Xn GTP-U tunnel for splitting the DRB. In this way, it has less impact on implementation on the network device.

When traffic is transmitted over the second link, the first device 110 determines 3020 whether at least one handover condition is met. For example, if the first device 110 detects a backhaul link failure on the second link, the first device 110 may determine that the handover condition is satisfied. Alternatively or additionally, the handover condition is satisfied if a beam failure is detected on the second link. In other example embodiments, the first device 110 may determine that the handover condition is met if beam fault recovery on the second link is initialized. In some embodiments, the handover condition is met if there is an unsuccessful RRC re-establishment on the second link. In some other embodiments, if an intermediate device exists between the first device 110 and the third device 130, the intermediate device may transmit a BH Radio Link Failure (RLF) notification to its child node when the intermediate device detects a failure of the third device 130. The first device 110 may determine that the handoff condition is satisfied upon receiving a BH Radio Link Failure (RLF) notification from the intermediate device.

Alternatively or additionally, if the link quality between the first device 110 and the third device 130 on the second link is below a threshold quality, it is determined that the handover condition is met. In other embodiments, the first device 110 may determine that the handoff condition is met if the first device 110 may receive an indication from the second device 120 or an indication (e.g., RLF indication) from its parent IAB node 130. In this way, more reliable communication can be achieved.

In some example embodiments, the first device 110 may determine 3025 whether the traffic is applicable for the backup radio bearer based on the configuration information. As described above, the configuration information may include the type of traffic that may utilize the backup radio bearer.

If the handover condition is met, the first device 110 transmits traffic using the alternate radio bearer on the first link. In this way, traffic can be delivered without additional delay. In addition, the quality of communication can be improved.

The first device 110 may send uplink traffic to the second device 120. Alternatively, the first device 110 may receive downlink traffic from the second device 120. In other words, the traffic may be downlink traffic. In other embodiments, the traffic may be uplink traffic. Details of the different schemes will be described later.

In the event that the backup radio bearer terminates in the primary node, for uplink transmission, in some embodiments, the first device 110 may transmit traffic to the second device 120 using the backup radio bearer(s), which the second device 120 may forward to the third device 130, if the handover condition is met. The first device 110 may send 3030 a first indication to the second device 120 that the handover condition is met. The second device 120 may send 3035 a second indication to the first device 110 for switching to the first link, and the second device 120 may also transmit an indication to the third device 130 for switching to the first link.

Alternatively, the second device 120 may send 3035 a second indication for switching to the first link without waiting for the first indication 3030 from the first device 110. The third device 130 may first detect a failure of the second link, e.g., a failure of downlink traffic to the first device via the second link. The third device 130 may notify the second device 120 of the failure of the second link, which causes the second device 120 to send 3035 a second indication to the first device 110. After receiving the second indication, the first device 110 may send 3040 traffic to the second device 120 using the backup radio bearer. The second device 120 may configure the first device 110 on which the standby radio bearer is to be used for traffic (e.g., specific F1-U traffic). This configuration may also be performed during the radio bearer setup/modification of the second link. In some embodiments, the identity of the traffic to be mapped to the alternate radio bearer may be a GTP-U F-TEID or Differential Service Code Point (DSCP) or IPv6 flow label or alternate RLC channel identity or 5QI value or UE identifier or UE bearer identifier. For example, the identity may include one or more of a GTP-U fully qualified TEID (F-TEID) or a Differentiated Services Code Point (DSCP) or IPv6 flow label. The mapping may be performed by SDAP layers 4030-1 and 4030-2.

Alternatively, one or more BH RLC channels over which traffic is transmitted are mapped to radio bearers. In an example embodiment, a Backhaul Adaptation Protocol (BAP) layer or any other type of mapping configuration and/or routing configuration layer (not shown) may perform the mapping.

The first device 110 may send 3040 traffic to the second device 120 using a radio bearer via the NR Uu interface. Traffic may be sent on PDCP layer 4010-1 and PDCP layer 4010-2 (as shown in figure 4A). The second device 120 may also send 3045 traffic to the third device 130 using the backup tunnel through an Xn interface (for NR-DC) or an X2 interface (for EN-DC).

After receiving the traffic, the third device 130 may remove headers related to both the backhaul backup GTP-U tunnel and the GTP-U tunnel of the data of the access terminal device. The third device 130 may extract PDCP Protocol Data Units (PDUs) carrying data of the fourth device 140-1 and process the PDCP PDUs. When the standby DRB terminates in the primary node, a separate "standby GTP-U tunnel" carrying DRB traffic needs to be used. The backup GTP-U tunnel may be established during the establishment of the first link including the establishment of the backup DRB and the establishment of the backup GTP-U tunnel, e.g., during 3010 and 3015. In this example, the standby DRB may carry the access UE DRB within the GTP-U tunnel. Thus, the third device 130 may have to remove both headers to obtain the actual UE data.

In the case where the backup radio bearer terminates in the primary node, the second device 120 may request that the radio bearer be used for DL traffic to the first device 110 for downlink transmission. The control plane (e.g., sgNB CU-CP) in the third device 130 can inform the user plane (e.g., sgNB CU-UP) in the third device 130 to use the backup radio bearer to send DL F1-U data. The third device 130 may send 3050 traffic to the second device 120, and the second device 120 may also send 3055 traffic to the first device 110. For example, the SgNB CU-UP may encapsulate the F1-U GTP-U packet as an Xn-U GTP-U packet and forward it to the second device 120 through a corresponding backup Xn-U GTP-U tunnel. The SgNB CU-CP may also inform the standby Xn-U tunnel to use thereon for the SgNB CU-UP carrying the specific DL F1-U traffic that may be identified by GTP-U F-TEID or DSCP or IPv6 flow label. This configuration may also be performed during radio bearer setup/modification.

Second device 120 may decapsulate the packets from the backup Xn-U GTP-U tunnel and send the F1 GTP-U packets to first device 110 using the backup radio bearer. The first device 110 may extract the F1 GTP-U packet from the PDCP PDUs of the standby DRB sent by the second device 120 and forward PDCP PDUs (of the access UE DRB) encapsulated in the F1 GTP-U packet to the fourth device 140-1.

In particular, for the uplink, the first device 110 (e.g., an IAB-DU in the first device 110) may receive PDCP PDUs from the fourth device 140-1 and encapsulate them as F1-U GTP-U/UDP/IP packets that are typically sent to the third device 130 (e.g., donor CU) (via the donor-DU) using the second link, e.g., over the backhaul. Now, when the link to the third device 130 is broken, a standby DRB may be used between the first device 110 and the second device 120. The PDCP PDU of the standby DRB contains an F1-U GTP-U packet (or GTP-U/UDP/IP packet). In the UL, if the backup DRB is primary node terminated (as shown in fig. 4A), the backup DRB PDCP is terminated in the primary node (i.e., the second device 120) and the content (i.e., the F1-U GTP-U packet or GTP-U/UDP/IP packet) is extracted and forwarded over Xn using the backhaul backup Xn-U tunnel.

In some embodiments, for the downlink, the third device 130 may encapsulate PDCP PDUs of the access UE as F1-U, i.e., GTP-U/UDP/IP packets forwarded to the IAB node via the standby DRB.

In the case where the standby radio bearer is terminated in the secondary node, as shown in fig. 4B, PDCP layers 4010-1 and 4010-5 may be used to establish the radio bearer between the first device 110 and the third device 130. For uplink transmission, if the handover condition is met, the first device 110 may send traffic to the second device 120 over the Uu interface using the radio bearer, the second device 120 forwarding the traffic to the third device 130.

Alternatively, the first device 110 may send 3030 a first indication to the second device 120 that the handover condition is met. The second device 120 may send 3035 a second indication for switching to the first link. After receiving the second indication, the first device 110 may send 3040 traffic to the second device 120 using the alternate radio bearer. In another example, the second indication 3035 may not be present. After the first device 110 sends 3030 a first indication to the second device 120 that the handover condition is met, the first device 110 may send 3040 traffic to the second device 120 using the backup radio bearer. In yet another example, the first indication 3030 or the second indication 3035 may not be present. When the handover condition is met, the first device 110 may send 3040 traffic to the second device 120 using the backup radio bearer without sending the first indication to the second device 120. Traffic received from the first device 110 using the backup radio bearer provides an implicit indication to the second device 120 that the handover condition is met.

In some embodiments, the second device 120 may configure the first device 110 on which the backup radio bearer is to be used for traffic (e.g., specific F1-U traffic). This configuration may also be performed during radio bearer setup/modification. In some embodiments, the identity of the traffic to be mapped to the radio bearer may be a GTP-U F-TEID or a Differentiated Services Code Point (DSCP) or an IPv6 flow label or a backup RLC channel identity or a 5QI value or a UE identifier or a UE bearer identifier. The mapping may be performed by SDAP layers 4030-1 and 4030-2. Alternatively, one or more BH RLC channels over which traffic is transmitted may be mapped to radio bearers. The Backhaul Adaptation Protocol (BAP) layer or any other type of mapping configuration and/or routing configuration layer (not shown) may perform the mapping.

The second device 120 may understand that the traffic and/or packets belong to the backup radio bearer. Second device 120 may send 3045 traffic and/or packets to third device 130 via a corresponding Xn GTP-U tunnel.

The third device 130 may determine 3047 whether at least one condition for switching from the second link to the first link is satisfied. The determination may be based on an indication received from the second device 120. In other words, after the second device 120 receives the first indication, the second device 120 may notify the third device 130 of the handover. Alternatively or additionally, the determination may be based on uplink traffic 3045 received from the second device 120 via the backup link. In other embodiments, the third device 130 may detect a link failure with the first device 110, e.g., failure to send downlink traffic to the first device 110 via the second link. When the third device 130 detects a link failure with the first device 110, the third device 130 may send an indication to the second device 120, which may be further sent to the first device 110. This may trigger the first device 110 to begin using the first link for uplink traffic. Alternatively, the first device 110 may begin using the first link for uplink traffic when downlink traffic is received via the first link, and the downlink traffic is initially transmitted to the first device via the second link.

The third device 130 may extract traffic and/or packets from the radio bearer. The SgNB CU-UP in the third device 130 can know that this is a special radio bearer, the packets of which are not forwarded to the core network device (e.g. user plane function UPF) but are processed in the CU-UP itself. In particular, if the standby DRB is secondary node terminated (as shown in FIG. 4B), the standby DRB PDCP is terminated in the secondary node and PDCP PDUs are typically transmitted over Xn/X2 using Xn/X2 GTP-U tunnels. The Xn-U module in fig. 4A and 4B is equivalent to GTP-U.

In the case where the backup radio bearer terminates in the secondary node, the second device 120 may request that the radio bearer be used for DL traffic to the first device 110 for downlink transmission. The control plane (e.g., sgNB CU-CP) in the third device 130 can inform the user plane (e.g., sgNB CU-UP) in the third device 130 to use the radio bearer to send DL F1-U data. The third device 130 may send 3050 traffic to the second device 120, and the second device 120 may also send 3055 traffic to the first device 110. For example, the SgNB CU-UP may encapsulate the F1-U GTP-U packet as an Xn-U GTP-U packet and forward it to the second device 120 through a corresponding Xn GTP-U tunnel. The SgNB CU-CP may also inform the Xn-U tunnel to use thereon for the SgNB CU-UP carrying the specific DL F1-U traffic that may be identified by GTP-U F-TEID or DSCP or IPv6 flow label. This configuration may also be performed during radio bearer setup/modification. In some embodiments, for the downlink, the third device 130 may encapsulate the access UE PDCP PDUs as F1-U, i.e., GTP-U/UDP/IP packets that are forwarded to the IAB node via the standby DRB.

The second device 120 can forward the PDCP packet to the first device 110. The first device 110 may know that the PDCP packet belongs to the backup radio bearer. The first device 110 may then extract the F1-U GTP-U packet and forward the (access UE) PDCP PDU encapsulated as the F1-U GTP-U packet to the fourth device 110-1.PDCP PDU packets may be forwarded on the RLC, medium access control, or physical layer.

If the handoff condition for switching from the second link to the first link is no longer satisfied, or the handoff condition for switching from the first link to the second link is satisfied, the first device 110 and the second device 120 may switch back to the second link, i.e., traffic transmission via the BAP (or any other type of mapping configuration and/or routing configuration layer) based backhaul link. Alternatively, if the second device 120 or the third device 130 can send the reconfiguration, the first device 110 and the second device 120 can switch back to traffic transmission via the BAP-based backhaul link. For example, the first device 110 and the second device 120 may switch from the first link to the second link if the conditions for switching to the second link are met. In some example embodiments, the condition may include detection of backhaul restoration on the second link. Alternatively or additionally, detection of beam restoration on the second link may also trigger a handover.

Alternatively, the first device 110 and the second device 120 may switch from the second link to the first link if other switching conditions for switching from the second link to the first link are satisfied. In some example embodiments, another handover condition may include detection of a backhaul failure on the first link. Alternatively or additionally, detection of a beam failure on the first link may also trigger a handover. In other example embodiments, other handover conditions may also include the initialization of beam fault recovery on the first link. In some example embodiments, unsuccessful RRC re-establishment on the first link may be considered a handover condition.

According to embodiments of the present disclosure, the delay has been reduced after the failure. In addition, no additional signaling is required, and the performance of the communication can also be improved. According to embodiments of the present disclosure, the backup radio bearer and the optional backup GTP-U tunnel may carry F1-U packets for the UE. In another embodiment, the backup radio bearer and optional backup GTP-U tunnel may carry backhaul traffic of the sub-device, e.g., traffic of the fifth device. Furthermore, the backup radio bearer may not be connected to any PDU session as the normal radio bearer. In the uplink, content from the backup radio bearer may not be forwarded directly to the core network device (e.g., UPF/gateway), but rather be decapsulated and processed in the donor CU. In the downlink, content from the backup radio bearer may not be forwarded to an upper layer at the IAB-MT of the first device, but provided to the IAB-DU.

The above embodiments of the present disclosure are described with reference to the NR-DC scenario of an Xn interface between the second device 120 and the third device 130. The described proposal is also applicable to EN-DC scenarios where the X2 interface is between the second device 120 and the third device 130. The above embodiments of the present disclosure are described with reference to the scenario where a standby radio bearer terminates in an access IAB node serving an access UE. Embodiments of the present disclosure may also be applied to scenarios where the connection from an access IAB node to its parent node is good, but the BAP-based BH connection from an intermediate IAB node to its parent node fails (especially in the UL direction with multiple IAB hops). The intermediate IAB node may then use and serve the standby DRBs, as well as the high priority traffic from its child IAB nodes in addition to its own high priority traffic for the access UE. The backup DRB may be established earlier before the connection fails.

In this case, the mapping to the backup radio bearer is preferably performed by the BAP layer, which receives BAP PDUs from the sub-IAB nodes. In this case, the mapping can be done most simply by mapping certain incoming BH RLC channels to the standby DRBs, since the GTP-U TEID is not readable in the intermediate IAB node when encryption of F1-U (e.g., IPsec) is applied, and vice versa. Also in this case DSCP and/or flow labels may be used as they may be set by the access IAB node (they may not be normally set for UL traffic or (especially flow labels) may not be normally copied to IPsec headers).

Fig. 5 illustrates a flowchart of an example method 500 implemented at the first device 110, according to some example embodiments of the present disclosure. For discussion purposes, the method 500 will be described from the perspective of the first device 110.

At block 510, the first device 110 receives configuration information for at least one radio bearer on a first link. The configuration information includes a configuration of one or more radio bearers and also indicates one or more handover conditions for switching from the second link to the first link, e.g. if the second link is not available. The configuration information may also include conditions for switching back from the first link to the second link, for example, if the second link is successfully recovered and available. In some example embodiments, the first link may be FR1 and the second link may be FR2. Alternatively, the first link may be FR2 and the second link may be FR1. It should be noted that the first link and the second link may be in any suitable frequency band that may be higher or lower than FR1 and/or FR2. In some embodiments, the first link and the second link may also be in the same frequency band. Embodiments of the present disclosure are not limited in this respect. Packet Data Convergence Protocol (PDCP) layers 4010-1 and 4010-2 may be used to establish radio bearers.

The data carried by the alternate radio bearer may be bound to the BH RLC channel. In some embodiments, for example, for N between N radio bearers and one BH RLC channel: 1, there may be a backup data radio bearer established for the aggregated BH RLC channel. Alternatively, for example, for 1 between one radio bearer and one BH RLC channel: 1 mapping, additional rules are required to aggregate multiple BH RLC channels into one spare DRB.

The handover condition may also relate to the link quality between the first device 110 and the third device 130. For example, if the link quality between the first device 110 and the third device 130 on the second link is below a threshold quality, a handover condition is determined to be met. In other embodiments, the handoff condition may include an indication received from the second device 120. The handoff condition may also include an indication (e.g., RLF indication) from its parent IAB node (e.g., third device 130) if first device 110 has a parent node.

Alternatively or additionally, the configuration information may include a traffic type that may utilize the backup radio bearer. For example, the configuration information may include an identifier of a terminal device that may use the backup radio bearer or an identifier of the UE bearer. Alternatively, the logical channel identifier may also be included in the configuration information. In some embodiments, the traffic type may be indicated by one or more general packet radio system tunneling protocol user plane (GTP-U) Tunnel Endpoint Identifiers (TEIDs). A 5G quality of service (QoS) identifier (5 QI) value or a Differentiated Services Code Point (DSCP) or an IPv6 flow label or a BH RLC channel identifier or a UE bearer identifier may also be used to indicate type of traffic. In addition, the configuration information may also include a BH RLC channel identifier that may be used to identify backhaul traffic between the first device 110 and a sub-device (e.g., fifth device 150). The identified backhaul traffic is to be sent via a first link when the handover condition is met or via a second link when the handover condition is met.

At block 520, the first device 110 determines whether at least one handoff condition is satisfied. For example, if the first device 110 detects a backhaul failure on the second link, the first device 110 may determine that a handover condition is satisfied. Alternatively or additionally, the handover condition is satisfied if a beam failure is detected on the second link. In other example embodiments, the first device 110 may determine that the handover condition is met if beam fault recovery on the second link is initialized. In some embodiments, the handover condition is satisfied if there is no successful RRC re-establishment on the second link. In some embodiments, the handoff condition is satisfied if the first device 110 receives an indication of a failure of the second link from the second device 120 over the first link. In some other embodiments, if an intermediate device exists between the first device 110 and the third device 130, the intermediate device may transmit a BH Radio Link Failure (RLF) notification to its child node when the intermediate device detects a failure of the third device 130. The first device 110 may determine that the handoff condition is satisfied upon receiving a BH Radio Link Failure (RLF) notification from the intermediate device.

Alternatively or additionally, if the link quality between the first device 110 and the third device 130 on the second link is below a threshold quality, it is determined that a handover condition is met. In other embodiments, if the first device 110 may receive an indication from the second device 120 or an indication (e.g., RLF indication) from its parent IAB node 130, the first device 110 may determine that the handoff condition is satisfied.

In some example embodiments, the first device 110 may determine whether the traffic is applicable to the radio bearer based on the configuration information. As described above, the configuration information may include a traffic type that may utilize a radio bearer.

At block 530, if the handover condition is met, the first device 110 communicates traffic using the radio bearer on the first link. In this way, traffic can be delivered without additional delay. In other embodiments, the first device 110 may transmit traffic using the radio bearer on the second link if the back-cut condition is met. By switching back to the second link, it can take full advantage of the advantages provided by the second link to achieve high bandwidth and low latency. In addition, the quality of communication can be improved.

In some embodiments, the first device 110 may transmit traffic to the second device 120. Alternatively, the first device 110 may receive traffic from the second device 120. In other words, the traffic may be downlink traffic. In other embodiments, the traffic may be uplink traffic.

According to embodiments of the present disclosure, the delay has been reduced after the failure. In addition, no additional signaling is required, and the performance of the communication can also be improved. Reliable communication can be achieved.

Fig. 6 illustrates a flowchart of an example method 600 implemented at the second device 120, according to some example embodiments of the present disclosure. For discussion purposes, the method 600 will be described from the perspective of the second device 120.

At block 610, the second device 120 transmits configuration information for at least one backup radio bearer on the first link. The configuration information may also indicate one or more handover conditions for handover from the second link to the first link, e.g., if the second link is not available. The configuration information may also include conditions for switching back from the first link to the second link, for example, if the second link is successfully recovered and available. In some example embodiments, the first link may be FR1 and the second link may be FR2. Alternatively, the first link may be FR2 and the second link may be FR1. It should be noted that the first link and the second link may be in any suitable frequency band that may be higher or lower than FR1 and/or FR2, and these frequency bands may be the same. Embodiments of the present disclosure are not limited in this respect. Packet Data Convergence Protocol (PDCP) layers 4010-1 and 4010-2 may be used to establish radio bearers. The second device 120 may also send configuration information for at least the backup tunnel to the third device 130. The backup tunnel is associated with a backup radio bearer. There may be a one-to-one mapping between the backup radio bearers and the backup tunnels.

Data carried by the radio bearer may be bound to the BH RLC channel. In some embodiments, for example, for N between N radio bearers and one BH RLC channel: 1, there may be a backup data radio bearer established for the aggregated BH RLC channel. Alternatively, for example, for 1 between one radio bearer and one BH RLC channel: 1 mapping, additional rules are required to aggregate multiple BH RLC channels into one spare DRB.

The handover condition may also relate to the link quality between the first device 110 and the third device 130. For example, if the link quality between the first device 110 and the third device 130 on the second link is below a threshold quality, then a handover condition is determined to be satisfied. In other embodiments, the handoff condition may include an indication received from the first device 110 regarding a failure on the second link. The handoff condition may also include an indication (e.g., RLF indication) from its parent IAB node (e.g., third device 130) if first device 110 has a parent node.

Alternatively or additionally, the configuration information may comprise a traffic type that may utilize a radio bearer. For example, the configuration information may be an identifier of a terminal device that may use a radio bearer or an identifier of a UE bearer. Alternatively, the logical channel identifier may also be included in the configuration information. In some embodiments, the traffic type may be indicated by one or more general packet radio system tunneling protocol user plane (GTP-U) Tunnel Endpoint Identifiers (TEIDs). A 5G quality of service (QoS) identifier (5 QI) value or a Differentiated Services Code Point (DSCP) or IPv6 flow label or BH RLC channel identity or UE identifier or UE bearer identifier may also be used to indicate type of traffic. In addition, the configuration information may also include a BH RLC channel identifier that may be used to identify backhaul traffic between the first device 110 and a sub-device (e.g., fifth device 150). The identified backhaul traffic is to be sent via a first link when the handover condition is met or via a second link when the handover condition is met.

The second device 120 may be a master node. In some embodiments, if the second device 120 is a master node, a backup tunnel may be established between the second device 120 and the third device 130. For example, the second device 120 may transmit additional configuration information for the tunnel, e.g., GTP-U F-TEID assigned by the second device 120, the third device 130 may establish a backup tunnel with the second device 120, and reply to the second device 120 with the assigned GTP-U F-TEID. The further configuration information may indicate that the tunnel is for traffic transmitted on a radio bearer. For example, the configuration information may include a flag so that the third device 130 may understand that traffic from the backup tunnel should be handled in a particular manner.

At block 620, if the handoff condition is met, the second device 120 communicates traffic with the first device 110 using the radio bearer on the first link. The handover condition may be the reception of a second link failure indication from the first device 110 or from the third device 130, the detection of traffic received from the third device 130 over the backup tunnel, or the detection of traffic received from the first device 110 over the backup radio bearer. When the second device 120 receives traffic from the first device 110 over the backup radio bearer, the second device 120 may forward the traffic to the third device 130 over the backup tunnel. When the second device 120 receives traffic from the third device 130 over the backup tunnel, the second device 120 may forward the traffic to the first device 110 over the backup radio bearer. In this way, traffic can be delivered without additional delay. In addition, the quality of communication can be improved.

For uplink transmissions, in some embodiments, the second device 120 may configure the first device 110 on which the backup radio bearer is to be used for traffic (e.g., specific F1-U traffic), or configure the identity of the traffic to be mapped to the backup radio bearer. This configuration may also be performed during radio bearer setup/modification. In some embodiments, the identity of the traffic to be mapped to the radio bearer may be a GTP-U F-TEID or a Differentiated Services Code Point (DSCP) or an IPv6 flow label or a backup RLC channel identity or a 5QI value or a UE identifier or a UE bearer identifier.

Alternatively, the second device 120 may receive a first indication from the first device 110 that the handover condition is met. The second device 120 may send a second indication to the first device 110 for switching to the first link.

Fig. 7 illustrates a flowchart of an example method 700 implemented at the third device 130, according to some example embodiments of the present disclosure. For discussion purposes, the method 700 will be described from the perspective of the third device 130.

At block 710, the third device 130 receives configuration information for a tunnel. The configuration information may indicate that the tunnel is for traffic communicated over the radio bearer. For example, the configuration information may include a flag so that the third device 130 may understand that traffic from the backup tunnel should be handled in a particular manner. The configuration information may include one or more handover conditions for switching from the second link to the first link, e.g., if the second link is not available. The configuration information may also include conditions for switching back from the first link to the second link, for example, if the second link is successfully recovered and available. In addition, the configuration information may further include information for identifying a traffic type that can use the first link when the handover condition is satisfied. The identity of the traffic may include one or more of a GTP-U fully qualified TEID (F-TEID), a Differentiated Services Code Point (DSCP), or an IPv6 flow label or a 5QI value or a UE identifier or a UE bearer identifier.

At block 720, the third device 130 establishes at least one backup tunnel with the second device 120. For example, the backup tunnel may be a GTP-U tunnel. One or more GTP-U tunnels may be established between third device 130 and second device 120.

At block 730, the third device 130 may determine whether at least one condition for switching from the second link to the first link is satisfied. The determination may be based on an indication received from the second device 120. In other words, after the second device 120 receives the first indication, the second device 120 may notify the third device 130 of the handover. Alternatively or additionally, the determination may be based on uplink traffic received from the second device 120 via the backup tunnel. In other embodiments, the third device 130 may detect a link failure with the first device 110, e.g., failure to send downlink traffic to the first device 110 via the second link. The third device 130 transmits traffic over the backup tunnel. The third device 130 may receive traffic from the second device 120 over the Xn interface for NR-DC or over the X2 interface for EN-DC using the backup tunnel. Alternatively, the third device 130 may use the backup tunnel to transmit traffic to the second device 120. For example, the SgNB CU-UP may encapsulate the F1-U GTP-U packet as an Xn-U (for NR-DC) or X2-U (for EN-DC) GTP-U packet and forward it to the second device 120 through the corresponding backup tunnel. The SgNB CU-CP may also inform the backup tunnel to use thereon for the SgNB CU-UP carrying the specific DL F1-U traffic that may be identified by GTP-U F-TEID or DSCP or IPv6 flow label.

After receiving the traffic, the third device 130 may remove the header related to both the radio bearer and the backup tunnel for the data. The third device 130 may extract PDCP Protocol Data Units (PDUs) carrying data of the fourth device 140-1 and process the PDCP PDUs.

In some example embodiments, a first apparatus (e.g., first device 110) capable of performing any one of the methods 500 may include means for performing the respective operations of the method 500. The component may be implemented in any suitable form. For example, the components may be implemented in circuitry or software modules. The first apparatus may be implemented as the first device 110 or included in the first device 110. In some embodiments, the component may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause execution of the apparatus.

In some embodiments, the apparatus includes means for receiving, at a first device, configuration information of at least one radio bearer on a first link from a second device, the configuration information indicating at least one handover condition for handing over traffic from the second link to the first link; means for determining whether at least one handover condition is satisfied; and means for transmitting traffic between the first device and the second device using at least one radio bearer on the first link if it is determined that the at least one handover condition is satisfied.

In some embodiments, the at least one handover condition includes one or more of: detection of a radio link failure on the second link, detection of a beam failure on the second link, initialization of beam failure recovery on the second link, unsuccessful radio resource control, RRC, re-establishment on the second link, link quality between the first device and the second device on the second link exceeding a threshold quality, an indication received from the second device or the third device to trigger a handover, or a failure indication received from other devices of the second link.

In some embodiments, the configuration information further indicates one or more traffic types applicable to the at least one radio bearer, and the means for transmitting traffic comprises: means for determining whether the traffic is applicable to at least one radio bearer based on the configuration information; and means for transmitting the traffic to the second device using the at least one radio bearer if it is determined that the traffic is applicable to the at least one radio bearer.

In some embodiments, the traffic type is identified by at least one of: a general packet radio system tunneling protocol user plane (GTP-U) fully qualified tunnel endpoint identifier (F-TEID) or Differentiated Services Code Point (DSCP) or IPv6 flow label, a backhaul channel identifier, a 5G quality of service identifier (5 QI) value, a UE identifier, or a UE bearer identifier.

In some embodiments, the means for transmitting traffic comprises: means for sending a first indication to the second device that at least one handover condition is met; and means for transmitting traffic using at least one radio bearer based on the second indication in response to receiving the second indication for switching to the first link.

In some embodiments, the first link is a non-BAP-based link and the second link is a BAP-based link.

In some embodiments, the first device is an integrated access and backhaul device and the second device is a network device.

In some example embodiments, a first apparatus (e.g., second device 120) capable of performing any one of method 600 may include means for performing the respective operations of method 600. The component may be implemented in any suitable form. For example, the components may be implemented in circuitry or software modules. The first apparatus may be implemented as the second device 120 or included in the second device 120. In some embodiments, the component may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause execution of the apparatus.

In some embodiments, the apparatus comprises: means for transmitting, at the second device, configuration information of at least one radio bearer on the first link to the first device, the configuration information indicating at least one handover condition for handing over traffic from the second link to the first link; and means for transmitting traffic between the first device and the second device using at least one radio bearer on the first link if it is determined that the at least one handover condition is met.

In some embodiments, the at least one handover condition includes one or more of: detection of a radio link failure on the second link, detection of a beam failure on the second link, initialization of beam failure recovery on the second link, unsuccessful radio resource control, RRC, re-establishment on the second link, link quality between the first device and the second device on the second link being below a threshold quality, an indication received from the first device that at least one handover condition is met, or a failure indication received from other devices of the second link.

In some embodiments, the apparatus further comprises: means for sending configuration information of another of the at least one backup tunnel between the second device and the third device on the first link to the third device; and means for establishing at least one backup tunnel for the first link between the second device and the third device.

In some embodiments, the means for transmitting traffic comprises: means for receiving traffic from a third device over the backup tunnel; means for decapsulating the traffic; and means for transmitting the decapsulated traffic to the first device using at least one radio bearer on the first link.

In some embodiments, the means for transmitting traffic comprises: the apparatus further includes means for transmitting the traffic to a third device over the backup tunnel.

In some embodiments, the apparatus further comprises: means for receiving a first indication from a first device that at least one condition is met; and means for sending a second indication to the first device for transmitting traffic on the at least one radio bearer.

In some example embodiments, a first apparatus (e.g., third device 130) capable of performing any one of method 700 may include means for performing the respective operations of method 700. The component may be implemented in any suitable form. For example, the components may be implemented in circuitry or software modules. The first apparatus may be implemented as the third device 130 or included in the third device 130. In some embodiments, the component may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause execution of the apparatus.

In some embodiments, the apparatus comprises: means for receiving, at the third device, configuration information for at least one backup tunnel between the second device and the third device on the first link from the second device; means for establishing at least one backup tunnel between the second device and the third device over the first link; and means for transmitting traffic between the third device and the second device over the backup tunnel on the first link if at least one handover condition is determined to be satisfied.

In some embodiments, the means for transmitting traffic comprises: means for receiving traffic from the second device over the at least one backup tunnel, or means for transmitting traffic to the second device over the at least one backup tunnel.

In some embodiments, the third apparatus further comprises means for determining whether at least one handover condition for handover from the second link to the first link is met based on at least one of: a failure indication received from the second device regarding the second link, uplink traffic from the second device, or detection of failed delivery of the second link.

In some embodiments, the third device is an integrated access and backhaul device and the second device is a network device.

Fig. 8 is a simplified block diagram of a device 800 suitable for implementing example embodiments of the present disclosure. Device 800 may be provided to implement a communication device, such as first device 110 or second device 120 as shown in fig. 1. As shown, the device 800 includes one or more processors 810, one or more memories 820 coupled to the processors 810, and one or more communication modules 840 coupled to the processors 810.

The communication module 840 is used for two-way communication. The communication module 840 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interface may represent any interface necessary to communicate with other network elements. In some example embodiments, the communication module 840 may include at least one antenna.

The processor 810 may be of any type suitable to the local technology network and may include one or more of the following: one or more of general purpose computers, special purpose computers, microprocessors, digital Signal Processors (DSPs) and processors based on a multi-core processor architecture. The device 800 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock that is synchronized to the master processor.

Memory 820 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memory include, but are not limited to, read-only memory (ROM) 824, electrically programmable read-only memory (EPROM), flash memory, a hard disk, a Compact Disk (CD), a Digital Versatile Disk (DVD), an optical disk, a laser disk, and other magnetic and/or optical storage. Examples of volatile memory include, but are not limited to, random Access Memory (RAM) 822 and other volatile memory that will not last for the duration of a power loss.

The computer program 830 includes computer-executable instructions that are executed by an associated processor 810. Program 830 may be stored in a memory (e.g., ROM 824). Processor 810 may perform any suitable actions and processes by loading program 830 into RAM 822.

Some example embodiments of the present disclosure may be implemented by means of the program 830 such that the device 800 may perform any of the processes of the present disclosure as discussed with reference to fig. 2-7. Example embodiments of the present disclosure may also be implemented in hardware or by a combination of software and hardware.

In some example embodiments, the program 830 may be tangibly embodied in a computer-readable medium, which may be included in the device 800 (such as in the memory 820) or other storage device that the device 800 may access. Device 800 may load program 830 from a computer readable medium into RAM 822 for execution. The computer-readable medium may include any type of tangible, non-volatile storage, such as ROM, EPROM, flash memory, hard disk, CD, DVD, and other magnetic and/or optical storage. Fig. 9 shows an example of a computer readable medium 900 in the form of an optical storage disc. The computer readable medium has stored thereon a program 830.

In general, the various embodiments of the disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of the embodiments of the disclosure are illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product comprises computer executable instructions, such as those included in program modules, which are executed in a device on a target physical or virtual processor to perform any of the methods described above with reference to fig. 2-7. Generally, program modules include routines, programs, libraries, objects, classes, components, data types, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within local or distributed devices. In distributed devices, program modules may be located in both local and remote memory storage media.

Program code for carrying out the methods of the present disclosure may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable an apparatus, device, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer readable media, and the like.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus or devices, or any suitable combination thereof. More specific examples of a computer-readable storage medium include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

Moreover, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Also, while the above discussion contains several specific implementation details, these should not be construed as limitations on the scope of the disclosure, but rather as descriptions of features specific to particular embodiments. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the disclosure has been described in language specific to structural features and/or methodological acts, it is to be understood that the disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A first apparatus for communication, comprising:

At least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code are configured to, with the at least one processor, cause the first apparatus to:

receiving configuration information of at least one radio bearer on a first link from a second apparatus, the configuration information indicating at least one handover condition for handing over traffic from the second link to the first link;

determining whether the at least one condition is met when traffic is transmitted over the second link; and

the traffic is communicated between the first device and the second device using the at least one radio bearer on the first link if the at least one handover condition is determined to be satisfied.

2. The first apparatus of claim 1, wherein the at least one handover condition comprises one or more of:

detection of radio link failure on the second link,

detection of beam faults on the second link,

initialization of beam fault recovery on the second link,

unsuccessful radio resource control RRC re-establishment on the second link,

The link quality between the first device and a third device on the second link is below a threshold quality,

an indication received from the second device for triggering the handover, or

A failure indication received from other devices of the second link.

3. The first apparatus of claim 1, wherein the configuration information further indicates one or more traffic types applicable to the at least one radio bearer, and wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first apparatus to:

determining whether the traffic is applicable to the at least one radio bearer on the first link based on the configuration information; and

if it is determined that the traffic is applicable to the at least one radio bearer, transmitting the traffic with the second device using the at least one radio bearer on the first link.

4. A first device according to claim 3, wherein the traffic type is identified by at least one of: a general packet radio system tunneling protocol user plane (GTP-U) fully qualified tunnel endpoint identifier (F-TEID) or Differentiated Services Code Point (DSCP) or IPv6 flow label, a backhaul channel identifier, a 5G quality of service identifier (5 QI) value, a UE identifier, or a UE bearer identifier.

5. The first apparatus of claim 1, wherein when transmitting the traffic, the at least one memory and the computer program code are configured to, with the at least one processor, cause the first apparatus to:

transmitting a first indication to the second apparatus that the at least one handover condition is met; and

in response to receiving a second indication to switch to the first link, the traffic is transmitted using the at least one radio bearer based on the second indication.

6. The first apparatus of claim 1, wherein the first link is a non-Backhaul Adaptation Protocol (BAP) -based link and the second link is a BAP-based link.

7. The first device of any of claims 1-6, wherein the first device is an integrated access and backhaul device and the second device is a network device.

8. A second apparatus for communication, comprising:

at least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to:

Transmitting configuration information of at least one radio bearer on a first link to a first apparatus, the configuration information indicating at least one handover condition for handover from a second link to the first link; and

traffic is communicated between the first device and the second device using the at least one radio bearer on the first link if the at least one handover condition is determined to be satisfied.

9. The second apparatus of claim 8, wherein the at least one handover condition comprises one or more of:

detection of radio link failure on the second link,

detection of beam faults on the second link,

initialization of beam fault recovery on the second link,

unsuccessful radio resource control RRC re-establishment on the second link,

an indication received from the first apparatus that at least one handover condition is met, or

A failure indication received from other devices of the second link.

10. The second apparatus of claim 8, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to:

Transmitting, to a third device, configuration information for another of at least one backup tunnel between the second device and the third device over the first link; and

the at least one backup tunnel is established between the second device and the third device for the first link.

11. The second apparatus of claim 10, wherein when transmitting the traffic, the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to:

receiving the traffic from the third device over the at least one backup tunnel;

decapsulating the traffic; and

the decapsulated traffic is sent to the first device using the at least one radio bearer on the first link.

12. The second apparatus of claim 10, wherein when transmitting the traffic, the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to:

receiving the traffic from the first device using the at least one radio bearer on the first link; and

And sending the service to the third device on the standby tunnel.

13. The second apparatus of claim 8, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to:

receiving a first indication from the first apparatus that the at least one condition is met; and

a second indication is sent to the first apparatus on the at least one radio bearer on the first link for transmitting the traffic.

14. The second apparatus of claim 8, wherein the first link is a non-Backhaul Adaptation Protocol (BAP) -based link and the second link is a BAP-based link.

15. The second device according to any of claims 8 to 14, wherein the first device is an integrated access and backhaul device and the second device is a network device.

16. A third apparatus for communication, comprising:

at least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code are configured to, with the at least one processor, cause the third apparatus to:

Receiving configuration information of at least one backup tunnel between a second device and a third device on a first link from the second device;

establishing the at least one backup tunnel between the second device and the third device over the first link; and

traffic is communicated between the third device and the second device over the at least one backup tunnel on the first link if at least one handoff condition is determined to be satisfied.

17. The third apparatus of claim 16, wherein when transmitting the traffic, the at least one memory and the computer program code are configured to, with the at least one processor, cause the third apparatus to:

receiving said traffic from said second device over said at least one backup tunnel, or

And sending the service to the second device on the at least one standby tunnel.

18. The third apparatus of claim 16, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the third apparatus to:

determining whether at least one handover condition for a handover from a second link to the first link is satisfied based on at least one of:

A failure indication received from the second device regarding the second link;

uplink traffic from the second device, or

Detection of failed delivery of the second link.

19. The third apparatus of claim 16, wherein the first link is a non-Backhaul Adaptation Protocol (BAP) -based link and the second link is a BAP-based link.

20. The third device of any of claims 16-19, wherein the third device is an integrated access and backhaul device and the second device is a network device.

21. A method for communication, comprising:

at a first apparatus, receiving configuration information of at least one radio bearer on a first link from a second apparatus, the configuration information indicating at least one handover condition for handing over traffic from the second link to the first link;

22. The method of claim 21, wherein the at least one handover condition comprises one or more of:

detection of radio link failure on the second link,

detection of beam faults on the second link,

initialization of beam fault recovery on the second link,

unsuccessful radio resource control RRC re-establishment on the second link,

an indication received from the second device for triggering the handover, or

A failure indication received from other devices of the second link.

23. The method of claim 21, wherein the configuration information further indicates one or more traffic types applicable to the at least one radio bearer, and wherein transmitting the traffic comprises:

24. The method of claim 23, wherein the traffic type is identified by at least one of: a general packet radio system tunneling protocol user plane (GTP-U) fully qualified tunnel endpoint identifier (F-TEID) or Differentiated Services Code Point (DSCP) or IPv6 flow label, a backhaul channel identifier, a 5G quality of service identifier (5 QI) value, a UE identifier, or a UE bearer identifier.

25. The method of claim 21, wherein transmitting the traffic comprises:

26. The method of claim 21, wherein the first link is a non-Backhaul Adaptation Protocol (BAP) -based link and the second link is a BAP-based link.

27. The method of any of claims 21 to 26, wherein the first device is an integrated access and backhaul device and the second device is a network device.

28. A method for communication, comprising:

At the second apparatus, transmitting configuration information of at least one radio bearer on the first link to the first apparatus, the configuration information indicating at least one handover condition for handing over traffic from the second link to the first link; and

29. The method of claim 28, wherein the at least one handover condition comprises one or more of:

detection of radio link failure on the second link,

detection of beam faults on the second link,

initialization of beam fault recovery on the second link,

unsuccessful radio resource control RRC re-establishment on the second link,

an indication received from the first apparatus that the at least one handover condition is met, or

A failure indication received from other devices of the second link.

30. The method of claim 28, further comprising:

the at least one backup tunnel for the first link is established between the second device and the third device.

31. The method of claim 30, wherein transmitting the traffic comprises:

decapsulating the traffic; and

32. The method of claim 30, wherein transmitting the traffic comprises:

and sending the service to the third device on the standby tunnel.

33. The method of claim 28, further comprising:

34. The method of claim 28, wherein the second link is a Backhaul Adaptation Protocol (BAP) -based link and the first link is a non-BAP-based link.

35. The method of any of claims 28-34, wherein the first device is an integrated access and backhaul device and the second device is a network device.

36. A method for communication, comprising:

at a third device, receiving configuration information of at least one backup tunnel between a second device and the third device on a first link from a second device;

37. The method of claim 36, wherein transmitting the traffic comprises:

38. The method of claim 36, further comprising:

a failure indication received from the second device regarding the second link;

uplink traffic from the second device, or

Detection of failed delivery of the second link.

39. The method of claim 36, wherein the first link is a non-Backhaul Adaptation Protocol (BAP) -based link and the second link is a BAP-based link.

40. The method of any of claims 36-39, wherein the third device is an integrated access and backhaul device and the second device is a network device.

41. A non-transitory program storage device readable by machine communication, tangibly embodying a program of instructions executable by the machine to perform operations comprising:

the traffic is communicated between a first device and the second device using the at least one radio bearer on the first link if the at least one handover condition is determined to be satisfied.

42. A non-transitory program storage device readable by machine communication, tangibly embodying a program of instructions executable by the machine to perform operations comprising:

transmitting configuration information of at least one radio bearer on a first link to a first apparatus, the configuration information indicating at least one handover condition for handing over traffic from a second link to the first link; and

and if it is determined that the at least one handover condition is satisfied, transmitting traffic between the first device and a second device using the at least one radio bearer on the first link.

43. A non-transitory program storage device readable by machine communication, tangibly embodying a program of instructions executable by the machine to perform operations comprising: