WO2021217424A1 - Gestion de trafic de secours - Google Patents

Gestion de trafic de secours Download PDF

Info

Publication number
WO2021217424A1
WO2021217424A1 PCT/CN2020/087520 CN2020087520W WO2021217424A1 WO 2021217424 A1 WO2021217424 A1 WO 2021217424A1 CN 2020087520 W CN2020087520 W CN 2020087520W WO 2021217424 A1 WO2021217424 A1 WO 2021217424A1
Authority
WO
WIPO (PCT)
Prior art keywords
link
traffic
radio bearer
switching condition
configuration information
Prior art date
Application number
PCT/CN2020/087520
Other languages
English (en)
Inventor
Dawid Koziol
Xiang Xu
Esa Malkamäki
Original Assignee
Nokia Shanghai Bell Co., Ltd.
Nokia Solutions And Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Shanghai Bell Co., Ltd., Nokia Solutions And Networks Oy filed Critical Nokia Shanghai Bell Co., Ltd.
Priority to PCT/CN2020/087520 priority Critical patent/WO2021217424A1/fr
Priority to CN202110458961.7A priority patent/CN113573373B/zh
Publication of WO2021217424A1 publication Critical patent/WO2021217424A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/082—Load balancing or load distribution among bearers or channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • H04W36/30—Reselection being triggered by specific parameters by measured or perceived connection quality data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition

Definitions

  • Embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to methods, devices, apparatuses and computer readable storage medium for backup traffic handling.
  • NR new radio
  • LTE long-term evolution
  • IAB integrated access backhaul
  • 5G fifth generation
  • This may allow easier deployment of a dense network of NR cells in a more integrated manner by building upon many of control and data channels/procedures defined for providing access to terminal devices.
  • example embodiments of the present disclosure provide a solution for backup traffic handling.
  • a first apparatus comprising at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the first apparatus to: receive, from a second apparatus, configuration information of at least one radio bearer on a first link, the configuration information indicating at least one switching condition for switching traffic from a second link to the first link in the case that the second link is unavailable.
  • the first apparatus is also caused to when a traffic is communicated on the second link determine whether the at least one switching condition is satisfied.
  • the first apparatus is further caused to in accordance with a determination that the at least one condition is satisfied, communicate the traffic between the first apparatus and the second apparatus with the at least one radio bearer on the first link.
  • a second apparatus comprising at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the second apparatus to transmit to a first apparatus configuration information of at least one radio bearer on a first link, the configuration information indicating at least one switching condition for switching traffic from a second link to the first link.
  • the second apparatus is further caused to in accordance with a determination that the at least one switching condition being satisfied, communicate a traffic between the first apparatus and the second apparatus with the at least one radio bearer on the first link.
  • a third apparatus comprises at least one processor; and at least one memory including computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the third apparatus to receive, from a second apparatus, configuration information of at least one backup tunnel between the second apparatus and the third apparatus on a first link.
  • the third apparatus is further caused to establish the backup tunnel between the second apparatus and a third apparatus on the first link.
  • the third apparatus is also caused to in accordance with a determination that at least one switching condition is met, communicate the traffic between the third apparatus and the second apparatus on the backup tunnel on the first link.
  • a method comprising receiving, at a first apparatus and from a second apparatus, configuration information of at least one radio bearer on a first link, the configuration information indicating at least one switching condition for switching traffic from a second link to the first link in the case that the second link is unavailable.
  • the method also comprises when a traffic is communicated on the second link, determining whether the at least one condition is satisfied.
  • the method further comprises in accordance with a determination that the at least one switching condition is satisfied, communicating the traffic between the first apparatus and the second apparatus with the at least one radio bearer on the first link.
  • a method comprising transmitting, at a second apparatus and to a first apparatus, configuration information of at least one radio bearer on a first link, the configuration information indicating at least one switching condition for switching traffic from a second link to the first link.
  • the method also comprises in accordance with a determination that the at least one switching condition being satisfied, communicating a traffic between the first apparatus and the second apparatus with the at least one radio bearer on the first link.
  • a method comprising receiving, at a third apparatus and from a second apparatus, configuration information of at least one backup tunnel between the second apparatus and the third apparatus on a first link.
  • the method further comprises establishing the at least one backup tunnel between the second apparatus and the third apparatus on the first link.
  • the method also comprises in accordance with a determination that at least one switching condition is met, communicating the traffic between the third apparatus and the second apparatus on the backup tunnel on the first link.
  • a first apparatus comprises means for receiving from a second apparatus, configuration information of at least one radio bearer on a first link, the configuration information indicating at least one switching condition for switching traffic from a second link to the first link in the case that the second link is unavailable; means for when a traffic is communicated on the second link, determining whether the at least one condition is satisfied; and means for in accordance with a determination that the at least one switching condition is satisfied, communicating the traffic between the first apparatus and the second apparatus with the at least one radio bearer on the first link.
  • a second apparatus comprises means for transmitting to a first apparatus, configuration information of at least one radio bearer on a first link, the configuration information indicating at least one switching condition for switching traffic from a second link to the first link; and means for in accordance with a determination that the at least one switching condition being satisfied, communicating a traffic between the first apparatus and the second apparatus with the at least one radio bearer on the first link.
  • a third apparatus comprises means for receiving from a second apparatus, configuration information of at least one backup tunnel between the second apparatus and the third apparatus on a first link; means for establishing the at least one backup tunnel between the second apparatus and a third apparatus on the first link; and means for in accordance with a determination that a traffic is unable to be communicated on a second link, communicating the traffic between the third apparatus and the second apparatus on the at least one backup tunnel on the first link.
  • a computer readable medium comprises program instructions for causing an apparatus to perform at least the method according to any one of the above fourth, fifth or sixth aspect.
  • Fig. 1 illustrates an example communication environment in which example embodiments of the present disclosure can be implemented
  • Figs. 2A-2C illustrate block diagrams of different scenarios involving IAB nodes according to some example embodiments of the present disclosure
  • Fig. 3 illustrates a signaling flow for backup traffic handling according to some embodiments of the present disclosure
  • Figs. 4A and 4B illustrate block diagrams of IAB node systems according to some example embodiments of the present disclosure, respectively;
  • 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 that is suitable for implementing example embodiments of the present disclosure.
  • Fig. 9 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.
  • references in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, 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 affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
  • first and second etc. 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. 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.
  • the term “and/or” includes any and all combinations of one or more of the listed terms.
  • circuitry may refer to one or more or all of the following:
  • circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.
  • circuitry also covers, 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 server, a cellular network device, or other computing or network device.
  • the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on.
  • NR New Radio
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • WCDMA Wideband Code Division Multiple Access
  • HSPA High-Speed Packet Access
  • NB-IoT Narrow Band Internet of Things
  • the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) communication protocols, and/or any other protocols either currently known or to be developed in the future.
  • suitable generation communication protocols including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) communication protocols, and/or any other protocols either currently known or to be developed in the future.
  • Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system
  • 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 an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a NR NB (also referred to as a gNB) , a NR NB distributed unit (also referred to as a gNB DU) , a 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) , a relay, an Integrated and Access Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network
  • terminal device refers to any end device that may be capable of wireless communication.
  • a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) .
  • UE user equipment
  • SS Subscriber Station
  • MS Mobile Station
  • AT Access Terminal
  • the terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and/
  • an IAB donor node (comprising, for example, donor centralized unit, Donor CU, and donor distributed unit, Donor DU) which is a 5G base station and one or more IAB nodes which is 5G relay station.
  • the IAB node may connect to an upstream IAB node or an IAB donor node via a subset of the UE functionalities of the NR Uu interface (named IAB-MT function of IAB-node) .
  • the node to which the IAB node may connect in upstream direction may be called a parent node or IAB parent node.
  • the IAB-node may provide wireless backhaul to the downstream IAB-nodes and UEs via the network functionalities of the NR Uu interface (named IAB-DU function of IAB-node) .
  • the node to which the IAB node connects in downstream direction may be called a child node or IAB child node.
  • One or more wireless backhaul (BH) radio link channel (RLC) are established between the IAB node and its child IAB node, and between the IAB node and its parent node.
  • the traffic for one or multiple UEs, or one or multiple IABs may be mapped to the same or different BH RLC channel.
  • IAB radio resource control
  • PDCP packet data convergence protocol
  • the network device to use the wireless backhaul, the network device (s) need to be configured or enabled with the information of the wireless backhaul.
  • a backhaul adaption protocol (BAP) entity in the network devices may perform mapping to egress logical channel or egress BH RLC Channel based on a BH RLC channel mapping configuration.
  • the BAP entity in the network devices may perform routing based on the backhaul routing configuration. In another example, some other type of mapping configuration and/or routing configuration may be applied.
  • Multi-Radio Dual Connectivity a multiple Rx/Tx capable UE may be configured to utilize resources provided by two different nodes, one providing NR access and the other one providing either E-UTRA or NR access.
  • One node acts as the Master Node (MN) and the other as the Secondary Node (SN) .
  • MN and SN are connected via a network interface, for example X2 interface or Xn interface, and at least the MN is connected to the core network.
  • the terminal device may leverage benefits of both LTE and 5G connectivity simultaneously.
  • the proposal use MR-DC as example, but can also be used in other dual-connectivity, for example, when the MN or SN uses other 3GPP access technology, or non-3GPP access technology.
  • the MR-DC may also apply to the IAB node.
  • IAB-mobile terminal IAB-MT
  • IAB-MT IAB-mobile terminal
  • eNB which is its Master Node
  • NR gNB which is a Secondary Node
  • the NR gNB may be an IAB node, or a Donor-DU. It maintains an RRC connection with the eNB while the backhaul (BH) traffic is using NR links.
  • F1AP F1 Application Protocol
  • the NR-DC may also apply to the IAB node.
  • IAB-mobile terminal IAB-MT
  • IAB-MT IAB-mobile terminal
  • the NR gNB may be an IAB node, or a Donor-DU.
  • the MN and SN may use same or different frequency bands.
  • 5G usually utilizes a variety of frequency bands within ranges known as Frequency Range 1 (FR1) (e.g. below 7.225 GHz or below 6 GHz) and FR2 (e.g. above 24.250 GHz) for the 5G New Radio.
  • FR1 Frequency Range 1
  • FR2 e.g. above 24.250 GHz
  • the bands in FR1 are envisaged to carry much of the traditional cellular mobile communications traffic.
  • the higher frequency bands in FR2 are aimed at providing short range very high data rate capability for the 5G radio.
  • FR1 frequencies either on LTE or NR
  • RRC and F1AP control traffic signaling
  • MN and SN may use same frequency band, for example, FR1 or FR2, or any other combinations of FR1 and FR2.
  • the BAP layer is only configured in one communication link, for example, between the IAB node and Secondary node, as well as the intermediate nodes between the IAB node and the Secondary Node.
  • the BAP is not configured in the other communication link between the IAB node and the Master Node. With this configuration, the backhaul traffic can only be transmitted over the communication link that is BAP enabled.
  • the communication device may wait a time duration till the link is recovered, then continue to transmit the backhaul traffic.
  • the communication device may connect to another base station supporting the wireless backhaul, then use the new BH link for the backhaul traffic transmission.
  • the conventional technologies such as for example RRC reestablishment procedure, may introduce extra latency and may affect the traffic requiring low latency.
  • a backup radio bearer on a first link is established between a first device and a second device. If a traffic is not able to be communicated on a second link, the radio bearer on the first link is used for the traffic communication. In this way, there is no extra latency. Further, there is no interruption of the traffic communication and performances of the communication are improved.
  • Fig. 1 illustrates a schematic diagram of a communication environment 100 in which embodiments of the present disclosure can be implemented according to some example embodiments of the present disclosure.
  • the communication environment 100 which is a part of a communication network, comprises 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 only an example not limitation.
  • the first device 110, the second device 120, the third device 130 and the fifth device 150 may be network devices.
  • the first device 110 may refer to 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 devices
  • the third device 130 may refer to a secondary node, which may be an IAB donor.
  • the first device 110 may be a parent node of the fifth device 150.
  • the first device 110, the second device 120, the third device 130 and the fifth device 150 can communicate data and control information to 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 system 100 comprises a device 140-1, a device 140-2, a device 140-3, ..., a network device 140-N, which can be collectively referred to as “fourth device (s) 140. ”
  • the fourth device 140 may communicate 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 backhauls.
  • the communication environment 100 may comprise any suitable number of devices and cells.
  • the first device 110 and the fourth device 140 can communicate data and control information to each other.
  • the first device 110 host the base station function or some of the base station functions, e.g. a gNB function or gNB-DU function, for the fourth device 140
  • a link from the fourth device 140 to the first device 110 is referred to as a uplink (UL)
  • a link from the first device 110 to the fourth device 140 is referred to as an downlink (DL) .
  • the fourth device 140 and the first device 110 are interchangeable.
  • the communication environment 100 may include any suitable number of devices and networks adapted for implementing embodiments of the present disclosure.
  • Communications in the communication environment 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) and the fifth generation (5G) and on the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future.
  • s cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) and the fifth generation (5G) and on the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future.
  • IEEE Institute for Electrical and Electronics Engineers
  • the communication may utilize any proper wireless communication technology, comprising 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 Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and/or any other technologies currently known or to be developed in the future.
  • CDMA Code Division Multiple Access
  • FDMA Frequency Division Multiple Access
  • TDMA Time Division Multiple Access
  • FDD Frequency Division Duplex
  • TDD Time Division Duplex
  • MIMO Multiple-Input Multiple-Output
  • OFDM Orthogonal Frequency Division Multiple
  • DFT-s-OFDM Discrete Fourier Transform spread OFDM
  • Figs. 2A-2C illustrate block diagrams of different scenarios in which some example embodiments of the present disclosure can be implemented.
  • the first device 110 is a parent node of the fifth device 150, which also means that the first device 110 is an intermedia node between the third device 130 (i.e., IAB-donor) and the fifth device 150.
  • the second device 120 may have both control plane and user plane connection with a core network device 210.
  • the third device 130 may also have both control plane and user plane connection with a core network device 210, or may only have user plane connection with a core network device 210.
  • the core network device 210 may be a device at evolved packet core or a device at next generation core.
  • the fifth device 150 may use dual-connectivity with the second device 120 (refer to Master node) and the first device 110 (refer to secondary node) .
  • the traffic of the fourth device 140-3 may include the downlink traffic sent to the fourth device 140-3, and the uplink traffic received from the fourth device 140-3.
  • the traffic of the fourth device 140-3 may use the second link.
  • the second link may refer to the communication link including the connection 2010 between the fifth device 150 and the first device 110, and the connection between the first device 110 and the third device 130.
  • the second link may be BAP-enabled, which means the devices of the second link support BAP, and have related configuration for BAP (for example, the mapping configuration, and routing configuration) .
  • the fifth device 150 may have established one or more backup radio bearer (s) 220 with the second device 120.
  • the backup radio bearer may be one or more radio bearers (DRBs) .
  • the second device 120 may also have established user plane tunnel or connection 260, for example, one or more GTP-U tunnels, with the third device 130.
  • the connection 260 may be an X2 connection for EN-DC case, or an Xn connection for NR-DC case.
  • the connection 260 may be related to the backup radio bearer 220. For example, it may be one to one mapping between the backup radio bearer and the GTP-U tunnel.
  • the first link refers to the communication link including the backup radio bearer (s) 220 between the fifth device 150 and the second device 120, and the user plane tunnel or connection 260 between the second device 120 and the third device 130.
  • the first link may not, which means that at least some devices of the first link (e.g. the second device 120) may not support, and not have related configuration as the devices of the second link. There may be a failure on the second link, for example, a failure for the link 2010 between the first device 110 and the fifth device 150.
  • the traffic received from the fourth device 140-3 and the traffic sent to the fourth device 140-3 may start using the first link, for example, using the backup radio bearer 220 established between the fifth device 150 and the second device 120, and the GTP-U tunnel 260 between the second device 120 and the third device 130.
  • the 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 be then sent from the second device 120 to the third device 130 via the GTP-U tunnel 260.
  • the 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 may be then sent from the second device 120 to the fifth device 150 via the backup radio bearer 220.
  • the fourth device 140-3 is not affected by the connectivity failure of the second link, for example, the failure of the connection between the fifth device 150 and its parent node, i.e. the first device 110.
  • only part of traffic originally sent via the second link is switched to the first link, e.g. only the high priority traffic.
  • all traffic originally sent via the second link is switched to the first link.
  • the first link including one or more backup radio bearer (s) 230 between the first device 110 and the second device 120, and the user plane tunnel or connection 260 between the second device 120 and the third device 130 may have been established as shown in Fig. 2B.
  • the connection 260 may be an X2-U connection for EN-DC case, or an Xn-U connection for NR-DC case.
  • the connection 260 is related to the backup radio bearer 220. For example, it may be one to one mapping between the backup radio bearer and the X2/Xn GTP-U tunnel.
  • the first link may refer to the communication link including the backup radio bearer (s) 230 between the first device 110 and the second device 120, and the user plane tunnel or connection 260 between the second device 120 and the third device 130.
  • the second link may refer to the communication link including the connection 2020 between the first device 110 and the third device 130.
  • the first link may not, which means that at least some devices of the first link (e.g. the second device 120) may not support, and not have related configuration as the devices of the second link.
  • the traffic sent/received via the first device 110 may use the second link.
  • the traffic may include the traffic to/from the first device 110 (for example, related to the fourth device 140-1) , and the traffic to/from the child devices of the first device 110, for example, the traffic to/from the fifth device 150.
  • the traffic to/from the child devices may also include the traffic related to the devices connected to the child devices.
  • the traffic to/from the fifth device 150 includes the traffic related to the fourth device 140-3.
  • a failure occurs on the second link, for example, a failure for the link 2020 between the first device 110 and the third device 130.
  • the traffic sent/received via the first device 110 may start using the first link, for example, using the backup radio bearer 230 established between the first device 110 and the second device 120, and the GTP-U tunnel 260 between the second device 120 and the third device 130.
  • the traffic, which is switched to the first link may include at least the traffic to be sent to fifth device 150 and the traffic to be received from the fifth device 150 over at least some of the BH RLC channels between the first device 110 and the fifth device 150.
  • the traffic to/from the first device 110 may include at least some of the traffic sent to the connected devices, e.g. the fourth device 140-1, and the some of the traffic received from the connected devices of the fifth device 150, e.g. the fourth device 140-3.
  • the devices connected to the first device 110 are not affected by the connectivity failure between the first device 110 and its parent node, i.e. the third device 130.
  • the connectivity failure between the first device 110 and its parent node i.e. the third device 130.
  • only part of traffic originally sent via the second link is switched to the first link, e.g. only the high priority traffic.
  • it all traffic originally sent via the second link is switched to the first link.
  • both the first device 110 and the fifth device 150 may have established the first link including the backup radio bearers 240 and 250 with the second device 120, and the user plane tunnel or connection 260 between the second device 120 and the third device 130.
  • the connection 260 may be an X2-U connection for EN-DC case, or an Xn-U connection for NR-DC case.
  • the connection 260 may be related to the backup radio bearer 220. For example, it may be one to one mapping between the backup radio bearer and the X2/Xn GTP-U tunnel.
  • the first link may refer to the communication link including the backup radio bearer (s) 240 (or 250) between the first device 110 (or the fifth device 150) and the second device 120, and the user plane tunnel or connection 260 between the second device 120 and the third device 130.
  • the second link may refer to the communication link including the connection with the third device 130.
  • the second link for the first device 110 may be the connection 2020 between the first device 110 and the third device 130
  • the second link for the fifth device 150 may include the connection 2020 between the first device 110 and the third device 130 and the connection between the fifth device 150 and the first device 110.
  • the first link may not, which means that at least some devices of the first link (e.g. the second device 120) may not support, and not have related configuration as the devices of the second link.
  • the traffic sent/received via the first device 110 and/or the fifth device 150 may use the second link.
  • the traffic may include the traffic to/from the first device 110 (for example, related to the fourth device 140-1) , and the traffic to/from the child devices of the first device 110, for example, the traffic to/from the fifth device 150.
  • the traffic to/from the child devices may also include the traffic related to the devices connected to the child devices.
  • the traffic to/from the fifth device 150 may include the traffic related to the fourth device 140-3.
  • the traffic to/from the first device 110 may start using the first link, for example, using the backup radio bearer 240, and the GTP-U tunnel 260 between the second device 120 and the third device 130.
  • the first device 110 may transmit a backhaul (BH) radio link failure (RLF) notification to its child node, i.e., the fifth device 150.
  • the fifth device 150 may also determine to start using the first link, for example, using the backup radio bearer 250 established between the fifth device 150 and the second device 120, and the GTP-U tunnel 260 between the second device 120 and the third device 130 for some or all traffic.
  • both the traffic to/from the first device 110 and the traffic to/from the fifth device 150 may start using the first link, for example, using the backup radio bearers 240 and 250.
  • the devices connected to the first device 110 are not affected by the connectivity failure between the first device 110 and its parent node, i.e. the third device 130.
  • the connectivity failure between the first device 110 and its parent node i.e. the third device 130.
  • only part of traffic originally sent via the second link is switched to the first link, e.g. only the high priority traffic.
  • it all traffic originally sent via the second link is switched to the first link.
  • the signaling flow 300 may involve the first device 110, the second device 120 and the third device 130.
  • the second device 120 and the third device 130 may be configured with BAP related configuration, for example, bearer mapping configuration and routing configuration.
  • BAP related configuration for example, bearer mapping configuration and routing configuration.
  • embodiments of the present disclosure can also be applied to links on other suitable layers.
  • the BAP layer is only an example for the purpose of illustrations, not limitations. At least one of the first and second link is a BAP based link. For example, both of the first and second links may be a BAP based link.
  • the first link may be a non BAP based link, which means the first link is not BAP enabled or not configured with BAP.
  • the second link may be a non BAP based link. It should be noted that embodiments of the present disclosure can be applied to any suitable types of links.
  • the second device 120 transmits 3005 configuration information of one or more radio bearer (s) for 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.
  • the second link is established between the first device 110 and the third device 130.
  • the configuration information includes the radio bearer configuration, and also indicates one or more switching condition for switching from a second link to the first link , for example, in case that the second link is unavailable.
  • the configuration information may also include the condition for switch back from the first link to the second link, for example, in case the second link is successfully recovered and available.
  • the one or more radio bearers may be used for uplink.
  • the one or more radio bearers may be used for downlink.
  • the first link and the second link may be uplinks.
  • the first link and the second link may be downlinks.
  • the first link may be in FR1 and the second link may be in FR2.
  • the first link may be in FR2 while the second link may be in FR1.
  • the first link may be associated with a macro cell and the second link may be associated with a small cell with limited transmit power.
  • the first link may be associated with a master node and the second link may be associated with a secondary node.
  • the first and second links can be in any suitable frequency bands which may be higher or lower than FR1 and/or FR2.
  • the first and the second links may be in same frequency band. Embodiments of the present disclosure are not limited in the aspect.
  • the Packet Data Convergence Protocol (PDCP) layers 4010-1 and 4010-2 may be used to establish the radio bearer. In this way, efficiency of resources on the first link can be improved.
  • the data carried by the backup data radio bearer of the first link may be tied to a BH RLC channel.
  • N 1 mapping between N radio bearers and one BH RLC channel
  • multiple UE bearers are mapped to a single BH RLC channel, which may be called as an aggregated BH RLC channel, and there may be a backup data radio bearer established for this aggregated BH RLC channel.
  • N 1 mapping, further aggregation may not be needed when BH RLC channels are mapped to backup DRBs.
  • 1: 1 mapping between one radio bearer and one BH RLC channel some additional rules are needed for aggregating multiple BH RLC channels into one backup DRB.
  • the situation of 1: 1 mapping between UE bearers (for example, DRBs) and BH RLC channels means that there is a dedicated BH RLC channel for each UE bearer.
  • 1: 1 mapping there may be multiple BH RLC channels, which implies that some aggregation is needed for the backup DRB, since the number of DRBs is typically limited.
  • the switching condition may comprise a detection of a backhaul failure on the second link.
  • a detection of a beam failure on the second link may also trigger the switching.
  • the switching condition may also comprise an initialization of a beam failure recovery on the second link. An unsuccessful RRC reestablishment on the second link may be regarded as the switching condition in some example embodiments.
  • the switching condition may also relate to link qualities 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, the switching condition is determined to be satisfied.
  • the switching condition may comprise an indication received from a master node or a secondary node, such as for example, the second device 120 or the third device 130.
  • the switching condition may also comprise an indication (for example, the RLF indication) from its parent device, for example, the device 130.
  • the configuration information may comprise types of traffic which can utilize the backup radio bearer.
  • the configuration information may comprise identifiers of terminal devices or identifiers of UE bearers which can use the backup radio bearer.
  • logical channel identifiers may also be included in the configuration information.
  • the types of traffic may be indicated by one or more general packet radio system tunneling protocol user plane (GTP-U) fully qualified tunnel endpoint identifiers (F-TEID) s.
  • GTP-U general packet radio system tunneling protocol user plane
  • F-TEID fully qualified tunnel endpoint identifiers
  • the 5G quality of service (QoS) identifier (5QI) values, or Differentiated Services Code Point (DSCP) , or IPv6 flow label, or BH RLC Channel identity may also be used to indicate the types of traffic.
  • the configuration information may also comprise BH RLC channel (s) identifier (s) which may be used to identify the backhaul traffic between the first device 110 and child devices, for example, the fifth device 150.
  • the identified backhaul traffic will be transmitted via the first link when the switching condition is met, or via the second link when the switching back condition is met.
  • the second device 120 may be a master node.
  • Fig. 4A shows a block diagram of backup radio bearer terminated in master node when the NR-DC is used, according to some example embodiments of the present disclosure.
  • Fig. 4B shows a block diagram of backup radio bearer terminated in secondary node when the NR-DC is used, according to some example embodiments of the present disclosure. As shown in Figs.
  • PDCP layers 4010 for example, 4010-1, 4010-2, 4010-3, 4010-4 and 4010-5) , Xn-U layers 4020 (for example, 4020-1 and 4020-2) , SDAP layers 4030 (for example, 4030-1, 4030-2 and 4030-3) , F1-U layers (for example, 4050-1 and 4050-2) , user datagram protocol (UDP) layers (for example, 4060-1 and 4060-2) , IP layers (for example, 4070-1 and 4070-2) , RLC layers (for example, 4080-1 and 4080-2) , medium access control (MAC) layers 4081 (for example, 4081-1 and 4081-2) and physical (PHY) layers 4082 (for example, 4082-1 and 4082-2) .
  • Xn-U layers 4020 for example, 4020-1 and 4020-2
  • SDAP layers 4030 for example, 4030-1, 4030-2 and 4030-3)
  • F1-U layers for example, 4050-1 and 4050
  • Figs. 4A and 4B may have other layers which are omitted for clarity purposes. It should also be noted that the block diagram shown in Figs. 4A and 4B are for NR-DC, but the block diagrams will be similar for EN-DC where X2-U is used instead of Xn-U and there is no SDAP layer. Embodiments of the present disclosure are described with the reference to Figs. 4A and 4B.
  • the second device 120 may transmit 3010 configuration information to the third device 130.
  • the configuration information may include one or more switching condition for switching from a second link to the first link, for example, in case that the second link is unavailable.
  • the configuration information may also include the condition for switch back from the first link to the second link, for example, in case the second link is successfully recovered and available.
  • a backup tunnel may be established between the second device 120 and the third device 130.
  • the second device 120 may transmit 3010 configuration information of the tunnel, for example, GTP-U F-TEID (s) allocated by the second device 120, to the third device 130 and the third device 130 may establish 3015 at least one backup tunnel with the second device 120, for example, by including the 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 used for the traffic communicated on the backup radio bearer.
  • the configuration information may comprise a flag so that the third device 130 may understand traffic from the backup tunnel should be treated in a special way.
  • an Xn-U module 4020-1 in the second device 120 and an Xn-U module 4020-2 in the third device 130 may establish at least a GTP-U tunnel over an Xn-U interface.
  • an X2-U module 4020-1 in the second device 120 and an X2-U module 4020-2 in the third device 130 may establish at least a GTP-U tunnel over an X2-U interface.
  • the second device 120 may configure the first device 110 on which backup radio bearer is to be used for the traffic (for example, a specific F1-U traffic) .
  • This configuration information to the third device 130 may also include information to identify the type of traffic that can use the first link when the switching condition is met.
  • the identity of the traffic may comprise one or more of GTP-U Fully Qualified TEID (F-TEID) , or Differentiated Services Code Point (DSCP) or IPv6 flow label, or 5QI value, or UE identifier, or UE bearer identifier.
  • the backup radio bearer is terminated in a secondary node, such as for example, the third device 130, as shown in Fig. 4B, there may be no need for a backup tunnel establishment and a normal tunnel, for example, Xn GTP-U tunnel used for split DRBs, can be used. In this way, it has less impact on implementations on the network devices.
  • the first device 110 determines 3020 whether the at least one switching condition is satisfied when the traffic is communicated on the second link. For example, if the first device 110 detects a backhaul link failure on the second link, the first device 110 may determine that the switching condition is satisfied. Alternatively or in addition, if a beam failure on the second link is detected, the switching condition is satisfied. In other example embodiments, the first device 110 may determine that the switching condition is satisfied if a beam failure recovery on the second link initialized. In some embodiments, if there is an unsuccessful RRC reestablishment on the second link, the switching condition is satisfied.
  • the intermediate device may transmit a BH radio link failure (RLF) notification to its child node when the intermediate device detects a failure with the third device 130.
  • the first device 110 may determine that the switching condition is satisfied upon the reception of the BH radio link failure (RLF) notification from the intermediate device.
  • the switching condition is determined to be satisfied if the link quality between the first device 110 and the third device 130 on the second link is below a threshold quality.
  • the first device 110 may receive an indication from the second device 120 or an indication (for example, the RLF indication) from its parent IAB node 130, the first device 110 may determine that the switching condition is determined to be satisfied. In this way, more reliable communication can be achieved.
  • the first device 110 may determine 3025 whether the traffic is applicable to the backup radio bearer based on the configuration information.
  • the configuration information may comprise types of traffic which can utilize the backup radio bearer.
  • the first device 110 communicates the traffic with the backup radio bearer on the first link if the switching condition is satisfied. In this way, the traffic can be communicated without extra latencies. Further, quality of the communication can be improved.
  • the first device 110 may transmit the uplink traffic to the second device 120.
  • the first device 110 may receive the downlink traffic from the second device 120.
  • the traffic may be downlink traffic.
  • the traffic may be uplink traffic. Details of the different scenarios are described later.
  • the first device 110 may transmit the traffic using the backup radio bearer (s) to the second device 120 which forwards the traffic to the third device 130.
  • the first device 110 may transmit 3030 a first indication that the switching condition is satisfied to the second device 120.
  • the second device 120 may transmit 3035 a second indication for switching to the first link to the first device 110, and the second device 120 may also transmit the indication for switching to the first link to the third device 130.
  • the second device 120 may transmit 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 the failure of the second link, for example, the failure of the downlink traffic to the first device via the second link.
  • the third device 130 may inform the second device 120 for the failure of the second link, which cause the second device 120 send the second indication 3035 to the first device 110.
  • the first device 110 may transmit 3040 the traffic to the second device 120 using the backup radio bearer (s) .
  • the second device 120 may configure the first device 110 on which backup radio bearer is to be used for the traffic (for example, a specific F1-U traffic) .
  • the identity of the traffic to be mapped to the backup radio bearers may be GTP-U F-TEID, or Differentiated Services Code Point (DSCP) , or IPv6 flow label, or backup RLC channel identity, or 5QI value, or UE identifier, or UE bearer identifier.
  • the identity may comprise one or more of GTP-U Fully Qualified TEID (F-TEID) or Differentiated Services Code Point (DSCP) or IPv6 flow label.
  • F-TEID Fully Qualified TEID
  • DSCP Differentiated Services Code Point
  • one or more BH RLC channels on which the traffic is communicated are mapped to the radio bearer.
  • backhaul adaptation protocol (BAP) layers or any other type of mapping configuration and/or routing configuration layer may perform the mapping.
  • the first device 110 may transmit 3040 the traffic to the second device 120 with the radio bearer via a NR Uu interface.
  • the traffic may be transmitted on the PDCP layers 4010-1 and 4010-2 (as shown in Fig. 4A) .
  • the second device 120 may further transmit 3045 the traffic to the third device 130 using the backup tunnel over Xn interface (for NR-DC) or X2 interface (for EN-DC) .
  • the third device 130 may remove headers related to both backhaul backup GTP-U tunnel and GTP-U tunnel of the access terminal device’s data.
  • the third device 130 may extract PDCP protocol data unit (PDU) carrying data of the fourth device 140-1 and process the PDCP PDU.
  • PDU PDCP protocol data unit
  • backup DRB When backup DRB is terminated in the master node, it needs to use a separate “backup GTP-U tunnel” which carries the DRB traffic.
  • the backup GTP-U tunnel may be established during the establishment of the first link, which includes the establishment of the backup DRB, and the establishment of the backup GTP-U tunnel, for example during 3010 and 3015.
  • the backup DRB may carry access UEs DRB inside a GTP-U tunnel.
  • the third device 130 may have to remove both headers to get the actual UE data.
  • the second device 120 may request to use the radio bearer for the DL traffic to the first device 110.
  • the control plane for example, the SgNB CU-CP
  • the control plane in the third device 130 may inform the user plane (for example, the SgNB CU-UP) in the third device 130 to use the backup radio bearer for transmitting the DL F1-U data.
  • the third device 130 may transmit 3050 the traffic to the second device 120 and the second device 120 may further transmit 3055 the traffic to the first device 110.
  • the SgNB CU-UP may encapsulate the F1-U GTP-U packet into an Xn-U GTP-U packet and forward to the second device 120 over a corresponding backup Xn-U GTP-U tunnel.
  • the SgNB CU-CP may also inform the SgNB CU-UP on which backup Xn-U tunnel is to be used to carry a specific DL F1-U traffic, which can be identified by the GTP-U F-TEID, or DSCP or IPv6 flow label. This configuration may also be performed during the radio bearer establishment/modification procedure.
  • the second device 120 may decapsulate the packet from the backup Xn-U GTP-U tunnel and transmit the F1 GTP-U packet to the first device 110 with the backup radio bearer.
  • the first device 110 may extract the F1 GTP-U packet from the PDCP PDU of the backup DRB transmitted by the second device 120 and forward the PDCP PDU (of the access UE DRB) encapsulated in the F1 GTP-U packet to fourth device 140-1.
  • the first device 110 may receive PDCP PDUs from the fourth device 140-1 and encapsulate them into F1-U GTP-U/UDP/IP packet which are normally transmitted using the second link, for example, over the backhaul to the third device 130 (for example, Donor CU) (via Donor-DU) .
  • the backup DRB may be used between the first device 110 and the second device120.
  • the PDCP PDUs of that backup DRB contain F1-U GTP-U packets (or GTP-U/UDP/IP packets) .
  • backup DRB is master node terminated (as shown Fig. 4A)
  • the backup DRB PDCP is terminated in the master node (i.e., the second device 120) and the content (i.e., F1-U GTP-U packet or GTP-U/UDP/IP packet) is extracted and forwarded over Xn using a backhaul backup Xn-U tunnel.
  • the third device 130 may encapsulate PDCP PDU of access UE into F1-U, i.e., GTP-U/UDP/IP packet which is forwarded to IAB-node via the backup DRB.
  • the 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.
  • the first device 110 may transmit the traffic with the radio bearer over an Uu interface to the second device 120 which forwards the traffic to the third device 130.
  • the first device 110 may transmit 3030 a first indication that the switching condition is satisfied to the second device 120.
  • the second device 120 may transmit 3035 a second indication for switching to the first link.
  • the first device 110 may transmit 3040 the traffic to the second device 120 with the backup radio bearer.
  • the first device 110 may transmit 3040 the traffic to the second device 120 with the backup radio bearer, after the first device 110 transmit 3030 a first indication that the switching condition is satisfied to the second device 120.
  • the first device 110 may transmit 3040 the traffic to the second device 120 with the backup radio bearer, without sending the first indication to the second device 120.
  • the traffic received from the first device 110 with the backup radio bearer gives an implicit indication to the second device 120 that the switching condition is satisfied.
  • the second device 120 may configure the first device 110 on which backup radio bearer is to be used for the traffic (for example, a specific F1-U traffic) . This configuration may also be performed during the radio bearer establishment/modification procedure.
  • the identity of the traffic to be mapped to the radio bearers may be GTP-U F-TEID, or Differentiated Services Code Point (DSCP) , or IPv6 flow label, or backup RLC channel identity, or 5QI value, or UE identifier, or UE bearer identifier.
  • the mapping may be performed by the SDAP layers 4030-1 and 4030-2. Alternatively, one or more BH RLC channels on which the traffic is communicated can be mapped to the radio bearer.
  • Backhaul adaptation protocol (BAP) layers or any other type of mapping configuration and/or routing configuration layer may perform the mapping.
  • the second device 120 may understand that the traffic and/or packets belongs to the backup radio bearer.
  • the second device 120 may transmit 3045 the traffic and/or packets to the third device 130 over a corresponding Xn GTP-U tunnel.
  • the third device 130 may determine 3047 whether the 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 inform the third device 130 the switching. Alternatively or in addition, the determination may be based on an uplink traffic 3045 received via backup link from the second device 120. In other embodiments, the third device 130 may detect the link failure with the first device 110, e.g., failed to send a downlink traffic to the first device 110 via the second link. When the third device 130 detects the link failure with the first device 110, the third 130 may send an indication to second device 120, which may be further sent to the first device 110.
  • the first device 110 may start to use the first link for the uplink traffic upon the reception of the downlink traffic via the first link, and the downlink traffic was originally sent to the first device via the second link.
  • the third device 130 may extract the traffic and/or packets from the radio bearer.
  • the SgNB CU-UP in the third device 130 may be aware that this is a special radio bearer whose packets are not forwarded to core network device (for example, a User Plane Function UPF) but are processed in the CU-UP itself.
  • core network device for example, a User Plane Function UPF
  • backup DRB is secondary node terminated (as shown in Fig. 4B)
  • backup DRB PDCP is terminated in secondary node and the PDCP PDUs are transferred over Xn/X2 normally using Xn/X2 GTP-U tunnel.
  • the Xn-U modules in Figs. 4A nd 4B are equivalent to GTP-U.
  • the second device 120 may request to use the radio bearer for the DL traffic to the first device 110.
  • the control plane for example, the SgNB CU-CP
  • the control plane in the third device 130 may inform the user plane (for example, the SgNB CU-UP) in the third device 130 to use the radio bearer for transmitting the DL F1-U data.
  • the third device 130 may transmit 3050 the traffic to the second device 120 and the second device 120 may further transmit 3055 the traffic to the first device 110.
  • the SgNB CU-UP may encapsulate the F1-U GTP-U packet into an Xn-U GTP-U packet and forward to the second device 120 over a corresponding Xn GTP-U tunnel.
  • the SgNB CU-CP may also inform the SgNB CU-UP on which the Xn-U tunnel is to be used to carry a specific DL F1-U traffic, which can be identified by the GTP-U F-TEID, or DSCP or IPv6 flow label. This configuration may also be performed during the radio bearer establishment/modification procedure.
  • the third device 130 may encapsulate access UE PDCP PDU into F1-U, i.e., GTP-U/UDP/IP packet which is forwarded to IAB-node via the backup DRB.
  • the second device 120 may forward the PDCP packet to the first device 110.
  • the first device 110 may be aware 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 into the F1-U GTP-U packet to the fourth device 110-1.
  • the PDCP PDU packet may be forwarded over a RLC, medium access control, or physical layer.
  • the first device 110 and the second device 120 may switch back to the second link, i.e. traffic transmission via BAP (or any other type of mapping configuration and/or routing configuration layer) based backhaul links.
  • the first device 110 and the second device 120 may switch back to traffic transmission via BAP based backhaul links if the second device 120 or the third device 130 may transmit reconfiguration.
  • the condition for switching to the second link is satisfied, the first device 110 and the second device 120 may switch from the first link to the second link.
  • the condition may comprise a detection of a backhaul recovery on the second link.
  • a detection of a beam recovery on the second link may also trigger the switching.
  • the first device 110 and the second device 120 may switch from the second link to the first link if other switching condition for switching from the second link to the first link is satisfied.
  • the other switching condition may comprise a detection of a backhaul failure on the first link.
  • a detection of a beam failure on the first link may also trigger the switching.
  • the other switching condition may also comprise an initialization of a beam failure recovery on the first link. An unsuccessful RRC reestablishment on the first link may be regarded as the switching condition in some example embodiments.
  • the backup radio bearer and optionally backup GTP-U tunnel may carry F1-U packets for the UEs.
  • the backup radio bearer and optionally backup GTP-U tunnel may carry the backhaul traffic for the child devices, for example, the traffic of the fifth device.
  • the backup radio bearer may not be connected to any PDU session as normal radio bearers.
  • content from the backup radio bearer may not be forwarded directly to core network device, for example, UPF/gateway, but is decapsulated and processed in the Donor CU.
  • content from the backup radio bearer may not be forwarded to upper layers at IAB-MT of the first device but is provided to IAB-DU instead.
  • the intermediate IAB-node can then use the backup DRB (s) and serve with that in addition to its own access UE’s high priority traffic also the high priority traffic coming from its child IAB-node (s) .
  • the backup DRB (s) may be established early before the connection failure.
  • the mapping to backup radio bearer is preferably made by BAP layer which receives the BAP PDUs from the child IAB-node.
  • the mapping in this case may be simplest by mapping certain incoming BH RLC channels to backup DRB since GTP-U TEID is not readable in the intermediate IAB-node when encryption (e.g., IPsec) of F1-U is applied, and vice versa.
  • DSCP and/or Flow Label could be used in this case since they can be set by the access IAB-node (they may not be set normally for UL traffic or (especially Flow Label) may not be copied normally to IPsec header) .
  • Fig. 5 shows a flowchart of an example method 500 implemented at a first device 110 in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 500 will be described from the perspective of the first device 110.
  • the first device 110 receives configuration information of at least one radio bearer on a first link.
  • the configuration information includes the configuration for one or more radio bearers, and also indicates one or more switching condition for switching from a second link to the first link, for example, in case that the second link is unavailable.
  • the configuration information may also include the condition for switching back from the first link to the second link, for example, in case the second link is successfully recovered and available.
  • the first link may be FR1 and the second link may be FR2.
  • the first link may be FR2 while the second link may be FR1. It should be noted that the first and second links can be in any suitable frequency bands which may be higher or lower than FR1 and/or FR2.
  • the first and second link can also be in the same frequency band.
  • Embodiments of the present disclosure are not limited in the aspect.
  • the Packet Data Convergence Protocol (PDCP) layers 4010-1 and 4010-2 may be used to establish the radio bearer.
  • the data carried by the backup radio bearer may be tied to a BH RLC channel.
  • N: 1 mapping between N radio bearers and one BH RLC channel there may be a backup data radio bearer established for this aggregated BH RLC channel.
  • some additional rules are needed for aggregating multiple BH RLC channels into one backup DRB.
  • the switching condition may comprise a detection of a backhaul failure on the second link.
  • a detection of a beam failure on the second link may also trigger the switching.
  • the switching condition may also comprise an initialization of a beam failure recovery on the second link. An unsuccessful RRC reestablishment on the second link may be regarded as the switching condition in some example embodiments.
  • the switching condition may also relate to link qualities 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, the switching condition is determined to be satisfied.
  • the switching condition may comprise an indication received from the second device 120. If the first device 110 has a parent node, the switching condition may also comprise an indication (for example, the RLF indication) from its parent IAB node, such as for example, the third device 130.
  • the configuration information may comprise types of traffic which can utilize the backup radio bearer.
  • the configuration information may comprise identifiers of terminal devices or identifiers of UE bearers which can use the backup radio bearer.
  • logical channel identifiers may also be included in the configuration information.
  • the types of traffic may be indicated by one or more general packet radio system tunneling protocol user plane (GTP-U) tunnel endpoint identifiers (TEID) s.
  • GTP-U general packet radio system tunneling protocol user plane
  • TEID tunnel endpoint identifiers
  • the 5G quality of service (QoS) identifier (5QI) values, or Differentiated Services Code Point (DSCP) , or IPv6 flow label, or BH RLC Channel identifier, or UE identifier, or UE bearer identifier may also be used to indicate the types of traffic.
  • the configuration information may also comprise BH RLC channel (s) identifier (s) which may be used to identify the backhaul traffic between the first device 110 and child devices, for example, the fifth device 150. The identified backhaul traffic will be transmitted via the first link when the switching condition is met, or via the second link when the switching back condition is met.
  • the first device 110 determines whether the at least one switching 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 the switching condition is satisfied. Alternatively or in addition, if a beam failure on the second link is detected, the switching condition is satisfied. In other example embodiments, the first device 110 may determine that the switching condition is satisfied if a beam failure recovery on the second link initialized. In some embodiments, if there is an unsuccessful RRC reestablishment on the second link, the switching condition is satisfied. In some embodiments, if the first device 110 receives an indication for the failure of the second link from the second device 120 on the first link, the switching condition is satisfied.
  • the intermediate device may transmit a BH radio link failure (RLF) notification to its child node when the intermediate device detects a failure with the third device 130.
  • the first device 110 may determine that the switching condition is satisfied upon the reception of the BH radio link failure (RLF) notification from the intermediate device.
  • the switching condition is determined to be satisfied if the link quality between the first device 110 and the third device 130 on the second link is below a threshold quality.
  • the switching condition is determined to be satisfied if the first device 110 may receive an indication from the second device 120 or an indication (for example, the RLF indication) from its parent IAB node 130, the first device 110 may determine that the switching condition is determined to be satisfied.
  • the first device 110 may determine whether the traffic is applicable to the radio bearer based on the configuration information.
  • the configuration information may comprise types of traffic which can utilize the radio bearer.
  • the first device 110 communicates the traffic with the radio bearer on the first link if the switching condition is satisfied. In this way, the traffic can be communicated without extra latencies. In other embodiments, the first device 110 may communicates the traffic with the radio bearer on the second link if the switching back condition is satisfied. By switching back to the second link, it fully takes the advantage provided by the second link, for high bandwidth and low latency. Further, quality of the communication can be improved.
  • the first device 110 may transmit the traffic to the second device 120.
  • the first device 110 may receive the traffic from the second device 120.
  • the traffic may be downlink traffic.
  • the traffic may be uplink traffic.
  • latencies have been reduced after a failure occurs. Further, no extra signaling is needed and performances of the commutation can also be improved. Reliable communications can be achieved.
  • Fig. 6 shows a flowchart of an example method 600 implemented at a second device 120 in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 600 will be described from the perspective of the second device 120.
  • the second device 120 transmits configuration information of at least one backup radio bearer on a first link.
  • the configuration information may also indicate one or more switching condition for switching from a second link to the first link, for example, in case that the second link is unavailable.
  • the configuration information may also include the condition for switching back from the first link to the second link, for example, in case the second link is successfully recovered and available.
  • the first link may be FR1 and the second link may be FR2.
  • the first link may be FR2 while the second link may be FR1.
  • the first and second links can be in any suitable frequency bands which may be higher or lower than FR1 and/or FR2 and the frequency bands can be the same.
  • Embodiments of the present disclosure are not limited in the aspect.
  • the Packet Data Convergence Protocol (PDCP) layers 4010-1 and 4010-2 may be used to establish the radio bearer.
  • the second device 120 may also transmit a configuration information of at least a backup tunnel to the third device 130.
  • the backup tunnel is related to the backup radio bearer. It may be possible that there is a one to one mapping between the backup radio bearer and the backup tunnel.
  • the data carried by the radio bearer may be tied to a BH RLC channel.
  • N: 1 mapping between N radio bearers and one BH RLC channel there may be a backup data radio bearer established for this aggregated BH RLC channel.
  • some additional rules are needed for aggregating multiple BH RLC channels into one backup DRB.
  • the switching condition may comprise a detection of a backhaul failure on the second link.
  • a detection of a beam failure on the second link may also trigger the switching.
  • the switching condition may also comprise an initialization of a beam failure recovery on the second link. An unsuccessful RRC reestablishment on the second link may be regarded as the switching condition in some example embodiments.
  • the switching condition may also relate to link qualities 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, the switching condition is determined to be satisfied.
  • the switching condition may comprise an indication received from the first device 110 about failure on the second link. If the first device 110 has a parent node, the switching condition may also comprise an indication (for example, the RLF indication) from its parent IAB node, such as for example, the third device 130.
  • the configuration information may comprise types of traffic which can utilize the radio bearer.
  • the configuration information may identifiers of terminal devices or identifiers of UE bearers which can use the radio bearer.
  • logical channel identifiers may also be included in the configuration information.
  • the types of traffic may be indicated by one or more general packet radio system tunneling protocol user plane (GTP-U) tunnel endpoint identifiers (TEID) s.
  • GTP-U general packet radio system tunneling protocol user plane
  • TEID tunnel endpoint identifiers
  • the 5G quality of service (QoS) identifier (5QI) values, or 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 the types of traffic.
  • the configuration information may also comprise BH RLC channel (s) identifier (s) which may be used to identify the backhaul traffic between the first device 110 and child devices, for example, the fifth device 150.
  • the identified backhaul traffic will be transmitted via the first link when the switching condition is met, or via the second link when the switching back condition is met.
  • the second device 120 may be a master node. In some embodiments, if the second device 120 is the 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 further configuration information of the tunnel, for example, the GTP-U F-TEID allocated by the second device 120, and the third device 130 may establish a backup tunnel with the second device 120 and reply the allocated GTP-U F-TEID to the second device 120.
  • the further configuration information may indicate that the tunnel is used for the traffic communicated on the radio bearer. For example, the configuration information may comprise a flag so that the third device 130 may understand traffic from the back tunnel should be treated in a special way.
  • the second device 120 communicates the traffic with the first device 110 using the radio bearer on the first link if the switching condition is satisfied.
  • the switching condition may be the reception of the second link failure indication from the first device 110 or from the third device 130, the detection of a traffic received from the third device 130 over the backup tunnel, or the detection of a traffic received 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.
  • the second device 120 may forward the traffic to the first device 110 over the backup radio bearer. In this way, the traffic can be communicated without extra latencies. Further, quality of the communication can be improved.
  • the second device 120 may configure the first device 110 on which the backup radio bearer is to be used for the traffic (for example, a specific F1-U traffic) , or identities of the traffic to be mapped to the backup radio bearer. This configuration may also be performed during the radio bearer establishment/modification procedure.
  • the identity of the traffic to be mapped to the radio bearers may be GTP-U F-TEID, or Differentiated Services Code Point (DSCP) , or IPv6 flow label, or backup RLC channel identity, or 5QI value, or UE identifier, or UE bearer identifier.
  • DSCP Differentiated Services Code Point
  • the second device 120 may receive a first indication that the switching condition is satisfied from the first device 110.
  • the second device 120 may transmit a second indication to the first device 110 for switching to the first link.
  • Fig. 7 shows a flowchart of an example method 700 implemented at a third device 130 in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 700 will be described from the perspective of the third device 130.
  • the third device 130 receives configuration information of the tunnel.
  • the configuration information may indicate that the tunnel is used for the traffic communicated on the radio bearer.
  • the configuration information may comprise a flag so that the third device 130 may understand traffic from the back tunnel should be treated in a special way.
  • the configuration information may include one or more switching condition for switching from a second link to the first link, for example, in case that the second link is unavailable.
  • the configuration information may also include the condition for switch back from the first link to the second link, for example, in case the second link is successfully recovered and available.
  • this configuration information may also include information to identify the type of traffic that can use the first link when the switching condition is met.
  • the identity of the traffic may comprise one or more of GTP-U Fully Qualified TEID (F-TEID) , or Differentiated Services Code Point (DSCP) or IPv6 flow label, or 5QI value, or UE identifier, or UE bearer identifier.
  • F-TEID Fully Qualified TEID
  • DSCP Differentiated Services Code Point
  • IPv6 flow label or 5QI value, or UE identifier, or UE bearer identifier.
  • the third device 130 establishes at least one backup tunnel with the second device 120.
  • the backup tunnel may be a GTP-U tunnel.
  • One or multiple GTP-U tunnels may be established between the third device 130 and the second device 120.
  • the third device 130 may determine whether the 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 inform the third device 130 the switching. Alternatively or in addition, the determination may be based on an uplink traffic received via backup tunnel from the second device 120. In other embodiments, the third device 130 may detect the link failure with the first device 110, e.g., failed to send a downlink traffic to the first device 110 via the second link. The third device 130 communicates the traffic on the backup tunnel.
  • the third device 130 may receive the traffic from the second device 120 using the backup tunnel over Xn interface for NR-DC or over X2 interface for EN-DC. Alternatively, the third device 130 may transmit the traffic to the second device 120 using the backup tunnel.
  • the SgNB CU-UP may encapsulate the F1-U GTP-U packet into an Xn-U (for NR-DC) or X2-U (for EN-DC) GTP-U packet and forward to the second device 120 over a corresponding backup tunnel.
  • the SgNB CU-CP may also inform the SgNB CU-UP on which backup tunnel is to be used to carry a specific DL F1-U traffic, which can be identified by the GTP-U F-TEID, or DSCP or IPv6 flow label.
  • the third device 130 may remove headers related to both the radio bearer and the backup tunnel of the data.
  • the third device 130 may extract PDCP protocol data unit (PDU) carrying data of the fourth device 140-1 and process the PDCP PDU.
  • PDU PDCP protocol data unit
  • a first apparatus capable of performing any of the method 500 may comprise means for performing the respective operations of the method 500.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the first apparatus may be implemented as or included in the first device 110.
  • the means may comprise at least one processor and at least one memory including computer program code. The at least one memory and computer program code are configured to, with the at least one processor, cause performance of the apparatus.
  • the apparatus comprises means for receiving, at a first device and from a second device, configuration information of at least one radio bearer on a first link, the configuration information indicating at least one switching condition for switching traffic from a second link to the first link; means for determining whether the at least one switching condition is satisfied; and means for in accordance with a determination that the at least one switching condition is satisfied, communicating the traffic between the first device and the second device with the at least one radio bearer on the first link.
  • the at least one switching condition comprises one or more of: a detection of a radio link failure on the second link, a detection of a beam failure on the second link, an initialization of a beam failure recovery on the second link, an unsuccessful radio resource control, RRC, reestablishment on the second link, a link quality between the first device and the second device on the second link being blow a threshold quality, an indication received from the second device or the third device to trigger the switching, or a failure indication received from other devices of the second link.
  • the configuration information further indicates one or more traffic types applicable to the at least one radio bearer
  • the means for communicating the traffic comprises means for determining whether the traffic is applicable to the at least one radio bearer based on the configuration information; and means for in accordance with a determination that the traffic is applicable to the at least one radio bearer, transmitting the traffic to the second device using the at least one radio bearer.
  • 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 a Differentiated Services Code Point (DSCP) or an IPv6 flow label, a backhaul channel identifier, 5G quality of service identifier (5QI) value, a UE identifier, or a UE bearer identifier.
  • GTP-U general packet radio system tunneling protocol user plane
  • F-TEID fully qualified tunnel endpoint identifier
  • DSCP Differentiated Services Code Point
  • IPv6 flow label IPv6 flow label
  • backhaul channel identifier a backhaul channel identifier
  • 5QI 5G quality of service identifier
  • UE identifier a UE bearer identifier
  • the means for communicating the traffic comprises: means for transmitting to the second device a first indication that the at least one switching condition is satisfied; and means for in response to receiving a second indication for switching to the first link, communicating the traffic using the at least one radio bearer based on the second indication.
  • the first link is a non BAP based link and the second link is a BAP based link.
  • the first device is an Integrated Access and Backhaul device and the second device is a network device.
  • a first apparatus capable of performing any of the method 600 may comprise means for performing the respective operations of the method 600.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the first apparatus may be implemented as or included in the second device 120.
  • the means may comprise at least one processor and at least one memory including computer program code. The at least one memory and computer program code are configured to, with the at least one processor, cause performance of the apparatus.
  • the apparatus comprises means for transmitting, at a second device and to a first device, configuration information of at least one radio bearer on a first link, the configuration information indicating at least one switching condition for switching traffic from a second link to the first link; and means for in accordance with a determination that the at least one switching condition being satisfied, communicating a traffic between the first device and the second device with the at least one radio bearer on the first link.
  • the at least one switching condition comprises one or more of: a detection of a radio link failure on the second link, a detection of a beam failure on the second link, an initialization of a beam failure recovery on the second link, an unsuccessful radio resource control, RRC, reestablishment on the second link, a 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 switching condition is satisfied, or a failure indication received from other devices of the second link.
  • the apparatus further comprises means for transmitting to a third device further configuration information of at least one backup tunnel between the second device and the third device on the first link; and means for establishing the at least one backup tunnel between the second device and a third device for the first link.
  • the means for communicating the traffic comprises: means for receiving from the third device the traffic on the back tunnel; means for decapsulating the traffic; and means for transmitting to the first device the decapsulated traffic using the at least one radio bearer on the first link.
  • the means for communicating the traffic comprises: means for receiving from the first device the traffic using the at least one radio bearer, and the apparatus further comprises means for transmitting the traffic to the third device on the backup tunnel.
  • the apparatus further comprises means for receiving from the first device a first indication concerning that the at least one condition is satisfied; and means for transmitting to the first device a second indication to communicate the traffic on the at least one radio bearer.
  • the first link is a non BAP based link and the second link is a BAP based link.
  • the first device is an Integrated Access and Backhaul device and the second device is a network device.
  • a first apparatus capable of performing any of the method 700 may comprise means for performing the respective operations of the method 700.
  • the means may be implemented in any suitable form.
  • the means may be implemented in a circuitry or software module.
  • the first apparatus may be implemented as or included in the third device 130.
  • the means may comprise at least one processor and at least one memory including computer program code. The at least one memory and computer program code are configured to, with the at least one processor, cause performance of the apparatus.
  • the apparatus comprises means for receiving, at a third device and from a second device, configuration information of at least one backup tunnel between the second device and the third device on a first link; means for establishing the at least one backup tunnel between the second device and a third device on the first link; and means for in accordance with a determination that at least one switching condition is met, communicating the traffic between the third device and the second device on the backup tunnel on the first link.
  • the means for communicating the traffic comprises: means for receiving the traffic from the second device on the at least one backup tunnel, or means for transmitting the traffic to the second device on the at least one backup tunnel.
  • the third apparatus further comprises means for determining whether at least one switching condition for switching from a second link to the first link is satisfied based on at least one of: a failure indication about the second link received from the second device, an uplink traffic from the second device, or a detection of a failure delivery of the second link.
  • the first link is a non BAP based link and the second link is a BAP based link.
  • 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 that is suitable for implementing example embodiments of the present disclosure.
  • the device 800 may be provided to implement a communication device, for example, the first device 110 or the second device 120 as shown in Fig. 1.
  • the device 800 includes one or more processors 810, one or more memories 820 coupled to the processor 810, and one or more communication modules 840 coupled to the processor 810.
  • the communication module 840 is for bidirectional communications.
  • the communication module 840 has one or more communication interfaces to facilitate communication with one or more other modules or devices.
  • the communication interfaces may represent any interface that is necessary for communication with other network elements.
  • the communication module 840 may include at least one antenna.
  • the processor 810 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples.
  • the device 800 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.
  • the memory 820 may include one or more non-volatile memories and one or more volatile memories.
  • the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 824, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , an optical disk, a laser disk, and other magnetic storage and/or optical storage.
  • ROM Read Only Memory
  • EPROM electrically programmable read only memory
  • flash memory a hard disk
  • CD compact disc
  • DVD digital video disk
  • optical disk a laser disk
  • RAM random access memory
  • a computer program 830 includes computer executable instructions that are executed by the associated processor 810.
  • the program 830 may be stored in the memory, e.g., ROM 824.
  • the processor 810 may perform any suitable actions and processing by loading the program 830 into the RAM 822.
  • example embodiments of the present disclosure may be implemented by means of the program 830 so that the device 800 may perform any process of the disclosure as discussed with reference to Figs. 2 to 7.
  • the example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.
  • the program 830 may be tangibly contained in a computer readable medium which may be included in the device 800 (such as in the memory 820) or other storage devices that are accessible by the device 800.
  • the device 800 may load the program 830 from the computer readable medium to the RAM 822 for execution.
  • the computer readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and other magnetic storage and/or optical storage.
  • Fig. 9 shows an example of the computer readable medium 900 in form of an optical storage disk.
  • the computer readable medium has the program 830 stored thereon.
  • various embodiments of the present 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 embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method 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 includes computer-executable instructions, such as those included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above with reference to Figs. 2 to 7.
  • program modules include routines, programs, libraries, objects, classes, components, data structures, or the like 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 a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.
  • Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes 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 codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented.
  • the program code may execute entirely on a 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.
  • the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above.
  • Examples of the carrier include a signal, computer readable medium, and the like.
  • the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
  • a computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would 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 of the foregoing.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Des‌ ‌modes‌ ‌de‌ réalisation donnés à titre d'exemple de ‌la‌ présente divulgation se rapportent à la gestion de trafic de secours. Les modes de réalisation de la présente divulgation fournissent une solution permettant une gestion de trafic de secours. Une porteuse radio de secours sur une première liaison est établie entre des premier et second appareils. Si un trafic n'est pas apte à être communiqué sur une seconde liaison, la porteuse radio sur la première liaison est utilisée pour la communication de trafic. De cette manière, il n'y a pas de latence supplémentaire. En outre, il n'y a pas d'interruption de la communication de trafic et les performances de la communication sont améliorées.
PCT/CN2020/087520 2020-04-28 2020-04-28 Gestion de trafic de secours WO2021217424A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2020/087520 WO2021217424A1 (fr) 2020-04-28 2020-04-28 Gestion de trafic de secours
CN202110458961.7A CN113573373B (zh) 2020-04-28 2021-04-27 备用业务处理

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/087520 WO2021217424A1 (fr) 2020-04-28 2020-04-28 Gestion de trafic de secours

Publications (1)

Publication Number Publication Date
WO2021217424A1 true WO2021217424A1 (fr) 2021-11-04

Family

ID=78161367

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/087520 WO2021217424A1 (fr) 2020-04-28 2020-04-28 Gestion de trafic de secours

Country Status (2)

Country Link
CN (1) CN113573373B (fr)
WO (1) WO2021217424A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110164494A1 (en) * 2010-01-07 2011-07-07 Samsung Electronics Co., Ltd. Method for operating a virtual router redundancy protocol router and communication system therefor
CN102868620A (zh) * 2011-07-06 2013-01-09 中兴通讯股份有限公司 跨环业务保护方法及装置
CN105681186A (zh) * 2015-12-18 2016-06-15 瑞斯康达科技发展股份有限公司 一种保护切换方法及保护切换装置
CN106301857A (zh) * 2015-06-08 2017-01-04 华为技术有限公司 一种网络保护的方法、网络节点及系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105144777B (zh) * 2014-03-24 2019-07-09 华为技术有限公司 回程链路的承载分流方法及网络设备
US10104705B2 (en) * 2014-11-05 2018-10-16 Intel IP Corporation Apparatus, system and method of communicating between a cellular manager and a user equipment (UE) via a WLAN access device
CN109803453B (zh) * 2017-11-17 2023-07-07 华为技术有限公司 一种通信方法，通信设备及其通信系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110164494A1 (en) * 2010-01-07 2011-07-07 Samsung Electronics Co., Ltd. Method for operating a virtual router redundancy protocol router and communication system therefor
CN102868620A (zh) * 2011-07-06 2013-01-09 中兴通讯股份有限公司 跨环业务保护方法及装置
CN106301857A (zh) * 2015-06-08 2017-01-04 华为技术有限公司 一种网络保护的方法、网络节点及系统
CN105681186A (zh) * 2015-12-18 2016-06-15 瑞斯康达科技发展股份有限公司 一种保护切换方法及保护切换装置

Also Published As

Publication number Publication date
CN113573373A (zh) 2021-10-29
CN113573373B (zh) 2023-10-10

Similar Documents

Publication Publication Date Title
US20230009565A1 (en) Communication method and apparatus applied to multi-link device in wireless local area network
CN111149419A (zh) 用于rrc恢复/暂停时的nr pdcp保留的方法和设备
US20230012998A1 (en) Communication method, access network device, terminal device, and core network device
US20220394606A1 (en) Methods and Apparatus for Flexible Aggregation of Communications Channels
WO2022067542A1 (fr) Configuration de faible transmission de données
EP4266746A1 (fr) Procédé et appareil de transmission de données
US20230254729A1 (en) Migration method and apparatus for iab-node
US11729688B2 (en) Data lossless handover
CN113873582A (zh) 一种移动边缘计算处理方法以及相关设备
WO2022027391A1 (fr) Dispositifs, procédés, appareils et supports lisibles par ordinateur pour redondance de topologie
US20220312287A1 (en) Device, method, apparatus and computer readable medium for inter-cu topology adaptation
JP2020061732A (ja) ハンドオーバーでのアップリンクベアラーバインディング
WO2021217424A1 (fr) Gestion de trafic de secours
US20230292191A1 (en) Mechanism for cell identity management
WO2022056686A1 (fr) Dispositif, procédé, appareil et support lisible par ordinateur pour communication iab
WO2024055172A1 (fr) Transfert de trafic dans un scénario de relais d'équipement utilisateur à réseau
WO2022226838A1 (fr) Réacheminement de paquets
WO2024026818A1 (fr) Prise en charge de mobilité dans un relais u2n
WO2024093059A1 (fr) Dispositifs réseau, dispositif terminal et procédés de communication
WO2023230882A1 (fr) Délestage de trafic
WO2023283878A1 (fr) Amélioration de modèle entièrement distribué de tsn
WO2023019413A1 (fr) Amélioration sur un réseau de liaison terrestre et d'accès intégré
WO2023151096A1 (fr) Demande de service dans réseau de liaison terrestre et d'accès intégrés
WO2024093187A1 (fr) Dispositifs et procédés dans un environnement à double connectivité multi-radio (mr-dc)
US20240015530A1 (en) Routing in Integrated Access and Backhaul Communication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20933392

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20933392

Country of ref document: EP

Kind code of ref document: A1