WO2023151096A1 - Service request in an integrated access and backhaul network - Google Patents

Service request in an integrated access and backhaul network Download PDF

Info

Publication number
WO2023151096A1
WO2023151096A1 PCT/CN2022/076251 CN2022076251W WO2023151096A1 WO 2023151096 A1 WO2023151096 A1 WO 2023151096A1 CN 2022076251 W CN2022076251 W CN 2022076251W WO 2023151096 A1 WO2023151096 A1 WO 2023151096A1
Authority
WO
WIPO (PCT)
Prior art keywords
traffic flow
message
backhaul
mapping
service request
Prior art date
Application number
PCT/CN2022/076251
Other languages
French (fr)
Inventor
Matti Einari Laitila
Esa Mikael MALKAMÄKI
Xiang Xu
Ilkka Antero Keskitalo
Henri Markus Koskinen
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/CN2022/076251 priority Critical patent/WO2023151096A1/en
Publication of WO2023151096A1 publication Critical patent/WO2023151096A1/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • H04W72/27Control channels or signalling for resource management between access points

Definitions

  • Embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to a device, method, apparatus and computer readable medium of service request in an Integrated Access and Backhaul (IAB) network.
  • IAB Integrated Access and Backhaul
  • a New Radio (NR) relaying option named as IAB has been discussed, which enables wireless relaying for NR access by using NR for backhauling.
  • a network device is referred to as an IAB node.
  • the terminating node of NR backhauling on network side is referred to as an IAB donor.
  • the IAB donor represents a gNB with additional functionality to support IAB.
  • Backhauling may occur via a single or via multiple hops.
  • example embodiments of the present disclosure provide a solution of service request in an IAB network.
  • a first device 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 device at least to receive, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device; determine, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow; and transmit, to the second device, a first message including the mapping configuration.
  • a second device 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 device at least to transmit, to a first device, a service request including information related to at least one traffic flow associated with a third device; and receive, from the first device, a first message including a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
  • a third device 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 device at least to transmit, to a first device, a service request including information related to at least one traffic flow associated with the third device.
  • a method comprises receiving, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device; determining, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow; and transmitting, to the second device, a first message including the mapping configuration.
  • the method comprises transmitting, to a first device, a service request including information related to at least one traffic flow associated with a third device; and receiving, from the first device, a first message including a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
  • a method comprises transmitting, to a first device, a service request including information related to at least one traffic flow associated with the third device.
  • an apparatus comprising means for receiving, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device; means for determining, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow; and means for transmitting, to the second device, a first message including the mapping configuration.
  • an apparatus comprising means for transmitting, to a first device, a service request including information related to at least one traffic flow associated with a third device; and means for receiving, from the first device, a first message including a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
  • an apparatus comprising means for transmitting, to a first device, a service request including information related to at least one traffic flow associated with the third device.
  • a computer readable medium having a computer program stored thereon which, when executed by at least one processor of a device, causes the device to carry out the method according to the fourth aspect, the fifth aspect or the six aspect.
  • FIG. 1 shows an example communication network in which embodiments of the present disclosure may be implemented
  • FIG. 2 shows a signaling chart illustrating a process of service request in an IAB network according to some example embodiments of the present disclosure
  • FIG. 3 shows a signaling chart illustrating a process of service request in an IAB network according to some example embodiments of the present disclosure
  • FIG. 4 shows a signaling chart illustrating a process of service request in an IAB network according to some example embodiments of the present disclosure
  • FIG. 5 shows a flowchart of an example method of service request in an IAB network according to some example embodiments of the present disclosure
  • FIG. 6 shows a flowchart of an example method of service request in an IAB network according to some example embodiments of the present disclosure
  • FIG. 7 shows a flowchart of an example method of service request in an IAB network according to some example embodiments of the present disclosure
  • FIG. 8 shows a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure.
  • FIG. 9 shows a block diagram of an example computer readable medium in accordance with some 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 example 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.
  • 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 fifth generation (5G) systems, 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.
  • 5G fifth generation
  • 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 future fifth generation (5G) new radio (NR) 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 future fifth generation (5G) new radio (NR) 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
  • the term “network device” 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 Next Generation NodeB (gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, a low power node such as a femto, a pico, and so forth, depending on the applied terminology and technology.
  • BS base station
  • AP access point
  • NodeB or NB node B
  • eNodeB or eNB evolved NodeB
  • gNB Next Generation NodeB
  • RRU Remote Radio Unit
  • RH radio header
  • RRH remote radio head
  • relay a
  • a RAN split architecture comprises a gNB-CU (Centralized unit, hosting RRC, SDAP and PDCP) controlling a plurality of gNB-DUs (Distributed unit, hosting RLC, MAC and PHY) .
  • a network device may correspond to DU part of the IAB node.
  • 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 (IoT) 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/
  • the terminal device may also correspond to Mobile Termination (MT) part of the integrated access and backhaul (IAB) node (a.k.a. a relay node) .
  • MT Mobile Termination
  • IAB integrated access and backhaul
  • the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.
  • a user equipment apparatus such as a cell phone or tablet computer or laptop computer or desktop computer or mobile IoT device or fixed IoT device
  • This user equipment apparatus can, for example, be furnished with corresponding capabilities as described in connection with the fixed and/or the wireless network node (s) , as appropriate.
  • the user equipment apparatus may be the user equipment and/or or a control device, such as a chipset or processor, configured to control the user equipment when installed therein. Examples of such functionalities include the bootstrapping server function and/or the home subscriber server, which may be implemented in the user equipment apparatus by providing the user equipment apparatus with software configured to cause the user equipment apparatus to perform from the point of view of these functions/nodes.
  • FIG. 1 shows an example communication network 100 in which embodiments of the present disclosure can be implemented.
  • the communication network 100 may comprise an IAB donor 101, which may comprise an IAB donor CU 110 (hereinafter may also be referred to as a first device) and an IAB donor DU 120 (hereinafter may also be referred to as a second device) .
  • the communication network 100 may also comprise IAB nodes 102-1 and 102-2, which may also be referred to as an IAB node 102 collectively (Hereinafter the IAB node 102 may also be referred to as a second device) .
  • the IAB node 102-1 may comprise an IAB DU 130-1 and an IAB mobile termination (IAB MT) 140-1.
  • the IAB node 102-2 may comprise an IAB DU 130-2 and an IAB MT 140-2.
  • the IAB nodes 102-1 and 102-2 may communicate with the IAB donor 101.
  • the IAB nodes 102-1 may communicate with the IAB donor 101 via a F1 connection established between the IAB donor CU 110 and IAB DU 130-1.
  • a connection may be established between the IAB donor DU 120 and an IAB MT of an IAB node via a Uu interface.
  • a connection may be established between the IAB donor DU 120 and the IAB MT 140-1 of the IAB node 102-1.
  • the communication network 100 may comprise eNB 150 (hereinafter may also be referred to as a third device 150) , which may communicate with the IAB donor 101 and the IAB node 102-1 or the IAB node 102-2, respectively. As shown in Fig. 1, the communication between the eNB 150 and the IAB donor 101 may be performed via the IAB node 102-2 and the IAB node 102-1. For example, the communication interface between the eNB 150 and IAB donor 101 may use the IAB connectivity between IAB node 102-2 and the IAB donor 101.
  • the communication network 100 may include any suitable number of IAB donors, IAB nodes and the eNBs adapted for implementing implementations of the present disclosure.
  • Communications in the communication system 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 Divided Multiple Address (CDMA) , Frequency Divided Multiple Address (FDMA) , Time Divided Multiple Address (TDMA) , Frequency Divided Duplexer (FDD) , Time Divided Duplexer (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Divided Multiple Access (OFDMA) and/or any other technologies currently known or to be developed in the future.
  • CDMA Code Divided Multiple Address
  • FDMA Frequency Divided Multiple Address
  • TDMA Time Divided Multiple Address
  • FDD Frequency Divided Duplexer
  • TDD Time Divided Duplexer
  • MIMO Multiple-Input Multiple-Output
  • OFDMA Orthogonal Frequency Divided Multiple Access
  • the IAB donor may initiate the backhaul (BH) Radio Link Control (RLC) channel establishment towards an IAB node.
  • BH backhaul
  • RLC Radio Link Control
  • the IAB introduces a protocol layer to perform routing and bearer mapping to RLC channels on the BH links.
  • the new layer may be called BAP (Backhaul Adaptation Protocol) .
  • BAP Backhaul Adaptation Protocol
  • the BAP layer has peer entities in the IAB nodes having BH link established starting from IAB donor DU until the access IAB-node where the BH link should reach. Routing in BAP is based on the Routing ID and related routing table configured by the IAB donor CU.
  • the Routing ID may consist of destination BAP address and the path ID.
  • the configured routing table indicates the next-hop BAP node address (i.e., the egress link) where the BH data is to be forwarded.
  • QoS quality of service
  • the mapping of BH data (bearers) to BH link RLC channels are also configured by the IAB donor CU.
  • the mapping can be 1: 1 or N: 1 mapping, where in the former case each bearer may have its own BH RLC channel enabling the use of advanced/optimized scheduling methods, while in N: 1 mapping case, multiple bearers are aggregated in a single BH RLC channel.
  • the aggregation can be, for example, based on QoS class.
  • the Internet Protocol (IP) layer may be carried over the BAP sublayer, which may enable routing over multiple hops.
  • the IAB donor DU may act as the first hop router of the IP layer.
  • the IP layer can also be used for non-F1 traffic.
  • the IAB IP layer was one of the main arguments for the specified protocol stack, for example, it has been specified that the IAB IP layer may support generic IP transport for any other nodes or equipment or service at the IAB site, for example, the Operations and Maintenance (OAM) interface for IAB node, other Radio Access Technology (RAT) equipment including long Term Evolution (LTE) and Wireless Local Area Network (WLAN) and other site equipment.
  • OFAM Operations and Maintenance
  • the IAB BH traffic can be classified into User Plane (UP) traffic and non-UP traffic.
  • the UP traffic type consists of F1-U tunnels carrying UE radio bearers between the DU and the CU.
  • the non-UP traffic consists of UE associated F1-C signalling-, non-UE associated F1-C signalling and non-F1 traffic types.
  • the UP traffic may be mapped to QoS specific BH channels on F1-U tunnel granularity, based on the QoS parameters of the UE radio bearer corresponding to the F1-tunnel.
  • the CU may receive all the necessary information for the UE bearer management and BH channel management in a session management signaling from the 5G core network (5GC) .
  • 5GC 5G core network
  • the CU may map the QoS flows to radio bearers and corresponding F1-U tunnels based on QoS profiles and define the QoS of the radio bearer.
  • the CU may also dynamically establish/release/modify radio bearers corresponding F1 tunnels and BH channels based on the session management signalling from the 5GC.
  • the mapping of the non-UP traffic to BH channels may be performed on the granularity of the traffic type.
  • the non-UP traffic is RAN internal and not related to UE’s access traffic, so it has no context in 5G core network (CN) and 5G policy framework and therefore it can be fully controlled by the CU.
  • CN 5G core network
  • the non-F1 traffic of an IAB-node may include all IP traffic that is not used for the transport of F1-C or F1-U packets.
  • the non-F1 traffic may include, for example, OAM traffic if it is transferred using the BH RLC channel, non-3GPP signalling like Internet Key Exchange Version 2 (IKEv2) or Stream Control Transmission Protocol (SCTP) connection establishment.
  • IKEv2 Internet Key Exchange Version 2
  • SCTP Stream Control Transmission Protocol
  • the non-F1 traffic type can be used for transporting any IP traffic between the IAB node and IAB donor DU and between IAB nodes.
  • the IAB IP layer may be used for transporting highly dynamic non-F1 IP traffic that varies in volume and QoS requirement.
  • One example of such usage is backhauling LTE base stations.
  • the load of eNB may change rapidly over time and QoS requirements of EPS bearers may also vary.
  • the CU does not receive information about non-F1 sessions through the CP, because 5GC does not have context for non-F1 traffic and the traffic source/sink, for example the eNB, does not have direct CP interface with the CU or the CP interface does not support the management of the non-F1 session.
  • the CU may not receive information through user plane by traffic inspection, because the traffic may be routed directly from IAB donor DU to destination, so it may bypass the CU.
  • traffic differentiation inside the non-F1 traffic type may not be supported by the current specification.
  • the solution of the present disclosure proposes a mechanism for supporting the traffic flow detection in the IAB network or in an LTE eNB connected over the IAB network.
  • the IAB donor CU may receive a service request including information related to at least one traffic flow associated with an eNB or some other node (e.g., from the other radio access technology (RAT) ) connected over the IAB network from an IAB node, an IAB donor DU or the eNB.
  • the IAB donor CU may determine, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow and transmit the mapping configuration to the IAB node or the IAB donor DU.
  • RAT radio access technology
  • a service request procedure for the detected traffic flow may be introduced for supporting the traffic flow detection in the IAB network or in an LTE eNB connected over the IAB network.
  • FIG. 2 shows a signaling chart a process 200 of service request in an IAB network according to some example embodiments of the present disclosure.
  • the process 200 may involve the IAB donor CU 110, the IAB donor DU 120, the IAB node 102, the eNB 150 and a Mobility Management Entity (MME) 230.
  • MME Mobility Management Entity
  • the eNB 150 is integrated with the IAB node 102.
  • the MME 230 transmit 202 a S1 application signaling to the eNB 150 to request, from the eNB, Evolved Packet System (EPS) bearer establishment or modification.
  • EPS Evolved Packet System
  • the IAB node 102 may detect 204 the EPS bearer establishment/modification or the QoS change at the eNB 150.
  • the eNB 150 is integrated with the IAB node 102, as shown in FIG. 2, the LTE control plane events and the eNB’s bearer context may be visible to the control entity of the IAB node 102.
  • the IAB node 102 may transmit 206 a service request to the IAB donor CU 110.
  • the service request may comprise information related to at least one traffic flow associated with the eNB 150, which may comprise, for example, flow descriptors and QoS descriptors.
  • the flow descriptors may include tunnel information related to the eNB, such as an UL Full Qualified Tunnel Endpoint Identifier (F-TEID) of the eNBs S1-U tunnel, IP flow label, a Differentiated Services Code Point (DSCP) associated with at least one UL traffic flow and/or address information related to the source and destination of the at least one traffic flow, such as the source IP address and the destination IP address.
  • F-TEID UL Full Qualified Tunnel Endpoint Identifier
  • DSCP Differentiated Services Code Point
  • the flow descriptors for the downlink (DL) flow transmission may include information such as a DSCP associated with at least one DL traffic flow, the IP flow label, and/or address information related to the source and destination of the at least one traffic flow, such as the source IP address and the destination IP address and/or a DL F-TEID.
  • the QoS descriptor may include one or more LTE QoS parameters, such as QoS Class Identifier (QCI) , Allocation and Retention Priority (ARP) , Guaranteed Bit Rate (GBR) , and/or Max Bit Rate (MBR) .
  • QCI QoS Class Identifier
  • ARP Allocation and Retention Priority
  • GRR Guaranteed Bit Rate
  • MRR Max Bit Rate
  • the QoS descriptor may also indicate a DSCP associated with the at least one traffic flow or any other suitable QoS references.
  • the IAB node 102 may transmit the service request to the IAB donor CU 110 via a Radio Resource Control (RRC) signalling.
  • RRC Radio Resource Control
  • the IAB node 102 may transmit the service request to the IAB donor CU 110 via a F1 application message that is used in the F1 application protocol.
  • the IAB donor CU 110 may determine 208 a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
  • the IAB donor CU 110 may map the QoS descriptors to 5G QoS parameters and perform admission control.
  • the IAB donor CU 110 may be pre-configured with the mapping table from QoS descriptors to 5G QoS parameters. For example, LTE QoS parameters are mapped to 5G QoS parameters.
  • the mapping configuration may comprise routing information for the at least one traffic flow associated with the eNB 150, mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows.
  • the IAB donor CU 110 may also determine a channel configuration of at least one backhaul channel based on the received information.
  • the channel configuration may be configured for establishing the at least one backhaul channel, or modifying the at least one backhaul channel.
  • the IAB donor CU 110 may configure at least one BH channel between the IAB node 102 and the IAB donor DU 120 to meet QoS requirements of the new flow and configure DL routing and channel mapping to the IAB donor DU 120, for example, based on the flow and QoS descriptors included into the service request message.
  • the IAB donor CU 110 may transmit 210 a UE context modification request to the IAB donor DU 120, via a F1 AP procedure.
  • the IAB donor DU 120 may transmit 212 the UE context modification response to the IAB donor CU 110.
  • the IAB donor CU 110 may generate a service response including the determined mapping configuration and optionally the channel configuration and transmit the service response message to the IAB node 102. It is to be understood that the channel configuration can be transmitted in another message other than the service response.
  • the IAB donor CU 110 may transmit 214, to the IAB node 102, a RRC reconfiguration message of the BH channel establishment/modification procedure including the service response message.
  • the IAB node 102 may transmit 216 a RRC reconfiguration complete message to the IAB donor CU 110.
  • the service response message may also be transmit in a separate RRC message.
  • the IAB donor CU 110 may transmit 218 the service response to the IAB node 102 via a F1 application message.
  • the eNB 150 may perform 220 admission controls for the EPS bearer with the IAB node 102 by taking the admission control result from the IAB donor CU 110 into account.
  • the eNB 150 may further transmit 222 EPS bearer setup response to MME 230.
  • the detection of new flow or changed QoS depends on the integration level of the eNB 150 and IAB node 102. If the eNB 150 is integrated with the IAB node 102, the control entity of the IAB node 102 may observe eNB’s CP transactions and bearer context, thus the service detection does not necessitate UP monitoring. In this integrated model, the IAB node 102 may also utilize all UP-protocol layers that are visible at the eNB 150 in traffic mapping to BH channels, for example F-TEIDs of the S1 tunnels. It is also possible to use LTE QoS parameters as QoS descriptors in service request.
  • the IAB node 102 may need to detect service flow and its QoS requirements from the UP packets (BAP Service Data Units (SDUs) ) .
  • the UP may be encrypted, for example S1-U interface may often be secured with IPSec, leaving only outer IP address visible to the IAB node 102, so the detection may be based on the information carried in the IP header.
  • the traffic mapping to BH channels at the access IAB node 102 (and the IAB donor DU 120 in DL) may need to be based on the IP header information. In this scenario the traffic detection and service request could also be performed by the IAB donor DU 120, where the BAP SDUs are also visible.
  • a process of service request in an IAB network in the scenario in which the eNB is external to the IAB node may be further described as below.
  • FIG. 3 shows a signaling chart a process 300 of service request in an IAB network according to some example embodiments of the present disclosure.
  • the process 300 will be described with reference to FIG. 1.
  • the process 300 may involve the IAB donor CU 110, the IAB donor DU 120, the IAB node 102, the eNB 150 and a MME 330.
  • the eNB 150 is external to the IAB node 102.
  • the MME 330 of process 300 transmits 302 a S1 application signaling to the eNB 150 to request, from the eNB, EPS bearer establishment or modification for the EPC.
  • the eNB 150 may transmit 304 a bearer setup/modify response to the MME 330 via a S1 application signaling.
  • the IAB node 102 may detect at least one traffic flow (i.e., from the UP traffic) associated with the eNB 150, either from the eNB 150 or from the MME 330. Alternatively, the QoS detection may also be performed at the IAB donor DU 120.
  • the IAB node 102 may transmit 306 a service request to the IAB donor CU 110.
  • the service request may comprise information related to at least one traffic flow associated with the eNB 150, which may comprise, for example, flow descriptors and QoS descriptors.
  • the QoS descriptors may comprise a DSCP associated with the at least one traffic flow.
  • the flow descriptors may comprise a DSCP associated with the at least one traffic flow and/or address information related to the source and destination of the at least one traffic flow, such as Internet Protocol version 6 (IPv6) flow label, source IP address and the destination IP address.
  • IPv6 Internet Protocol version 6
  • the IAB node 102 may transmit the service request to the IAB donor CU 110 via a Radio Resource Control (RRC) signalling.
  • RRC Radio Resource Control
  • the IAB donor CU 110 may determine 308 a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
  • the mapping configuration may comprise routing information for the at least one traffic flow associated with the eNB 150, mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows.
  • the IAB donor CU 110 may also determine a channel configuration of at least one backhaul channel based on the received information.
  • the channel configuration may be configured for establishing the at least one backhaul channel, or modifying the at least one backhaul channel.
  • the IAB donor CU 110 may transmit 310 a UE context modification request to the IAB donor DU 120, via a F1 AP procedure.
  • the IAB donor DU 120 may transmit 312 the UE context modification response to the IAB donor CU 110.
  • the IAB donor CU 110 may generate a service response including the determined mapping configuration and optionally the channel configuration and transmit the service response message to the IAB node 102. It is to be understood that the channel configuration can be transmitted in another message other than the service response.
  • the IAB donor CU 110 may transmit 314, to the IAB node 102, a RRC reconfiguration message of the BH channel establishment/modification procedure including the service response message. After the RRC reconfiguration completes, the IAB node 102 may transmit 316 an RRC reconfiguration complete message to the IAB donor CU 110.
  • the service request to the IAB donor CU 110 may not come from the IAB node 102, but from the LTE eNB 150 over X2/Xn interface set up between the eNB 150 and the IAB donor CU 110.
  • FIG. 4 shows a signaling chart a process 400 of service request in an IAB network according to some example embodiments of the present disclosure.
  • the process 400 may involve the IAB donor CU 110, the IAB donor DU 120, the IAB node 102, the eNB 150 and a MME 430.
  • the eNB 150 may identify (some characteristic of) the IAB node 102 which has used to be or it is using for its connectivity. Based on the identified information, as shown in FIG. 4, the eNB 150 may transmit 402 an X2 message (for example, an X2 request message or an X2 setup request message) to the IAB donor CU 110. The X2 message may be indicative of an IAB node 102 used for connectivity with the eNB 150. Then the IAB donor CU 110 may transmit 404 an X2 message (for example, an X2 response message or X2 setup response message) to the eNB 150 in response to the X2 message from the eNB 150.
  • an X2 message for example, an X2 response message or X2 setup response message
  • the MME 430 may transmit 406 a S1 application signaling to the eNB 150 to request, from the eNB, EPS bearer establishment or modification. After checking the admission control for LTE bearer, the eNB may transmit 408 the service request to the IAB donor CU 110.
  • the service request may comprise information related to at least one traffic flow associated with the eNB 150. For example, the information may comprise full LTE QoS parameters.
  • the IAB donor CU 110 may determine 410 a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
  • the mapping configuration may comprise routing information for the at least one traffic flow associated with the eNB 150, mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows.
  • the IAB donor CU 110 may also determine a channel configuration of at least one backhaul channel based on the received information.
  • the channel configuration may be configured for establishing the at least one backhaul channel, or modifying the at least one backhaul channel.
  • the IAB donor CU 110 may transmit 412 a UE context modification request to the IAB donor DU 120, via a F1 AP procedure.
  • the IAB donor DU 120 may transmit 414 the UE context modification response to the IAB donor CU 110.
  • the IAB donor CU 110 may transmit 416, to the IAB node 102, an RRC reconfiguration message of the BH channel establishment/modification procedure, which may include the determined mapping configuration and optionally the channel configuration. It is to be understood that the channel configuration can be transmitted in another message.
  • the IAB node 102 may transmit 418 an RRC reconfiguration complete message to the IAB donor CU 110.
  • the IAB donor CU 110 may also send the mapping configuration to the IAB node 102 via F1AP message (not shown in the figure) .
  • the IAB donor CU 110 may transmit 420 a service response message to the eNB 150 via an X2 application protocol message.
  • the service response may indicate that the at least one traffic flow associated with the eNB 150 is allowed to be communicated.
  • the eNB 150 may transmit 422 a S1 application signaling including the bearer setup/modify response to the MME 430.
  • full LTE Qos parameters may be usable in the service request, and the IAB admission control may be part of the eNB’s admission control for the new or modified LTE bearer (as requested by the MME 430) .
  • a service request procedure for the detected traffic flow may be introduced for supporting the traffic flow detection in the IAB network or in an LTE eNB connected over the IAB network.
  • FIG. 5 shows a flowchart of an example method 500 of service request in an IAB network according to some example embodiments of the present disclosure.
  • the method 500 can be implemented at the first device 110 as shown in FIG. 1.
  • the method 500 will be described with reference to FIG. 1.
  • the first device 110 receives, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device.
  • the first device may receive the service request via a radio resource control signaling or in an application protocol procedure.
  • the information comprises at least one of tunnel information related to the third device connected with the second device, address information related to a transmitter and/or a receiver of the at least one traffic flow, a flow label for the at least one traffic flow, or one or more parameters of a quality of service associated with the at least one traffic flow.
  • the first device 110 determines, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
  • the mapping configuration comprises at least one of routing information for the at least one traffic flow, mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows.
  • the first device 110 transmits, to the second device, a first message including the mapping configuration.
  • the first device may determine a channel configuration of at least one backhaul channel based on the received information, and transmit a second message including the channel configuration to the second device for one of establishing the at least one backhaul channel, or modifying the at least one backhaul channel.
  • the first device may determine a channel configuration of at least one backhaul channel based on the received information; and transmit the channel configuration to the second device via the first message.
  • the first message is transmitted to the second device via at least one of a radio resource control message, an application protocol procedure message or a response message in response to the service request.
  • the second message is transmitted to the second device via a radio resource control signaling or in an application protocol procedure (e.g., F1 application procedure) .
  • an application protocol procedure e.g., F1 application procedure
  • the first device may transmit in an application protocol procedure, to the third device, an indication that the at least one traffic flow is allowed.
  • the first device may receive, from the third device, a X2 message (e.g., X2 setup request) from the third device, the X2 message being indicative of a second device used for a connectivity with the third device; and transmit, to the third device, a X2 response message (e.g., X2 setup response message) to the X2 message.
  • a X2 message e.g., X2 setup request
  • a X2 response message e.g., X2 setup response message
  • the first device comprises an integrated access and backhaul donor centralized unit
  • the second device comprises an integrated access and backhaul donor distributed unit or an integrated access backhaul node
  • the third device comprises a long term evolution network device.
  • FIG. 6 shows a flowchart of an example method 600 of service request in an IAB network according to some example embodiments of the present disclosure.
  • the method 600 can be implemented at the second device 120 or 102 as shown in FIG. 1. For the purpose of discussion, the method 600 will be described with reference to FIG. 1.
  • the second device transmits, to a first device, a service request including information related to at least one traffic flow associated with a third device.
  • the second device may transmit the service request to the first device via a radio resource control signaling or in an application protocol procedure.
  • the information comprises at least one of tunnel information related to the third device connected with the second device, address information related toa transmitter and/or a receiver (for example, a starting point and an end point) of the at least one traffic flow, a flow label for the at least one traffic flow, or one or more parameters of a quality of service associated with the at least one traffic flow.
  • the second device receives, from the first device, a first message including a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
  • the mapping configuration comprises at least one of routing information for the at least one traffic flow, mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows
  • the second device may transmit the service request to the first device, if the second device determines that at least one traffic flow associated with the third device or a quality of service change is detected.
  • the second device may receive, from the first device, a second message including the channel configuration of at least one backhaul channel for one of establishing the at least one backhaul channel, or modifying the at least one backhaul channel.
  • the second device may receive, from the first device, a channel configuration of at least one backhaul channel via the first message.
  • the first message is received from the first device in at least one of a radio resource control message, an application protocol procedure message or a response message in response to the service request.
  • the second message is received from the first device via a radio resource control signaling or in an application protocol procedure.
  • the first device comprises an integrated access and backhaul donor centralized unit
  • the second device comprises an integrated access and backhaul donor distributed unit or an integrated access backhaul node
  • the third device comprises a long term evolution network device.
  • FIG. 7 shows a flowchart of an example method 700 of service request in an IAB network according to some example embodiments of the present disclosure.
  • the method 700 can be implemented at the third device 150 as shown in FIG. 1.
  • the method 700 will be described with reference to FIG. 1.
  • the third device transmit, to a first device, a service request including information related to at least one traffic flow associated with the third device.
  • the service request is transmitted to the first device in an application protocol procedure.
  • the information comprises one or more parameters of a quality of service associated with the at least one traffic flow.
  • the third device may receive in an application protocol procedure, from the first device, an indication that the at least one traffic flow is allowed.
  • the third device may transmit, to the first device, a X2 message from the third device, the X2 message being indicative of a second device used for a connectivity with the third device; and receive, from the first device, a X2 response message to the X2 message.
  • the third device may perform a communication for the at least one traffic flow associated with the third device.
  • the first device comprises an integrated access and backhaul donor centralized unit or donor node and the third device comprises a long term evolution network device.
  • the second device comprises an integrated access and backhaul donor distributed unit or an integrated access backhaul node.
  • an apparatus capable of performing the method 500 may comprise means for performing the respective steps 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 apparatus comprises means for receiving, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device; means for determining, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow; and means for transmitting, to the second device, a first message including the mapping configuration.
  • an apparatus capable of performing the method 600 may comprise means for performing the respective steps 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 apparatus comprises means for transmitting, to a first device, a service request including information related to at least one traffic flow associated with a third device; and means for receiving, from the first device, a first message including a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
  • an apparatus capable of performing the method 700 may comprise means for performing the respective steps 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 apparatus comprises means for transmitting, to a first device, a service request including information related to at least one traffic flow associated with the third device.
  • FIG. 8 is a simplified block diagram of a device 800 that is suitable for implementing embodiments of the present disclosure.
  • the device 800 may be provided to implement the communication device, for example the IAB donor CU 110, the IAB donor DU 120, the IAB node 102, or the eNB 150 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 may be for bidirectional communications.
  • the communication module 840 may have 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) , and other magnetic storage and/or optical storage.
  • the volatile memories include, but are not limited to, a random access memory (RAM) 822 and other volatile memories that will not last in the power-down duration.
  • a computer program 830 includes computer executable instructions that may be executed by the associated processor 810.
  • the program 830 may be stored in the ROM 824.
  • the processor 810 may perform any suitable actions and processing by loading the program 830 into the RAM 822.
  • the 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 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 the like.
  • FIG. 9 shows an example of the computer readable medium 900 in form of CD or DVD.
  • 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, device, 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 real or virtual processor, to carry out the methods 200-700 as described above with reference to FIGs. 2-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 device, 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 codes or related data may be carried by any suitable carrier to enable the device, device 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, device, 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.

Abstract

Example embodiments of the present disclosure relate to devices, methods, apparatuses and computer readable storage media of service request in an Integrated Access and Backhaul (IAB) network. The method comprises receiving, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device; determining, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow; and transmitting, to the second device, a first message including the mapping configuration.

Description

SERVICE REQUEST IN AN INTEGRATED ACCESS AND BACKHAUL NETWORK FIELD
Embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to a device, method, apparatus and computer readable medium of service request in an Integrated Access and Backhaul (IAB) network.
BACKGROUND
A New Radio (NR) relaying option named as IAB has been discussed, which enables wireless relaying for NR access by using NR for backhauling. In general, a network device is referred to as an IAB node. The terminating node of NR backhauling on network side is referred to as an IAB donor. The IAB donor represents a gNB with additional functionality to support IAB. Backhauling may occur via a single or via multiple hops.
SUMMARY
In general, example embodiments of the present disclosure provide a solution of service request in an IAB network.
In a first aspect, there is provided a first device. The first device 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 first device at least to receive, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device; determine, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow; and transmit, to the second device, a first message including the mapping configuration.
In a second aspect, there is provided a second device. The second device 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 second device at least to transmit, to a first device, a service request including information related to at least one traffic flow associated with a  third device; and receive, from the first device, a first message including a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
In a second aspect, there is provided a third device. The third device 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 device at least to transmit, to a first device, a service request including information related to at least one traffic flow associated with the third device.
In a fourth aspect, there is provided a method. The method comprises receiving, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device; determining, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow; and transmitting, to the second device, a first message including the mapping configuration.
In a fifth aspect, there is provided method. The method comprises transmitting, to a first device, a service request including information related to at least one traffic flow associated with a third device; and receiving, from the first device, a first message including a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
In a sixth aspect, there is provided a method. The method comprises transmitting, to a first device, a service request including information related to at least one traffic flow associated with the third device.
In a seventh aspect, there is provided an apparatus comprising means for receiving, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device; means for determining, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow; and means for transmitting, to the second device, a first message including the mapping configuration.
In an eighth aspect, there is provided an apparatus comprising means for transmitting, to a first device, a service request including information related to at least one traffic flow associated with a third device; and means for receiving, from the first device, a first message including a mapping configuration for a mapping between at least one  backhaul channel and the at least one traffic flow.
In a ninth aspect, there is provided an apparatus comprising means for transmitting, to a first device, a service request including information related to at least one traffic flow associated with the third device.
In a tenth aspect, there is provided a computer readable medium having a computer program stored thereon which, when executed by at least one processor of a device, causes the device to carry out the method according to the fourth aspect, the fifth aspect or the six aspect.
It is to be understood that the summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.
BRIEF DESCRIPTION OF THE DRAWINGS
Some example embodiments will now be described with reference to the accompanying drawings, where:
FIG. 1 shows an example communication network in which embodiments of the present disclosure may be implemented;
FIG. 2 shows a signaling chart illustrating a process of service request in an IAB network according to some example embodiments of the present disclosure;
FIG. 3 shows a signaling chart illustrating a process of service request in an IAB network according to some example embodiments of the present disclosure;
FIG. 4 shows a signaling chart illustrating a process of service request in an IAB network according to some example embodiments of the present disclosure;
FIG. 5 shows a flowchart of an example method of service request in an IAB network according to some example embodiments of the present disclosure;
FIG. 6 shows a flowchart of an example method of service request in an IAB network according to some example embodiments of the present disclosure;
FIG. 7 shows a flowchart of an example method of service request in an IAB network according to some example embodiments of the present disclosure;
FIG. 8 shows a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure; and
FIG. 9 shows a block diagram of an example computer readable medium in accordance with some embodiments of the present disclosure.
Throughout the drawings, the same or similar reference numerals represent the same or similar element.
DETAILED DESCRIPTION
Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitations as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.
In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.
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 example 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.
It shall be understood that the terms “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 functionalities of various elements. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.
The terminology used herein is for the purpose of describing particular  embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.
As used in this application, the term “circuitry” may refer to one or more or all of the following:
(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and
(b) combinations of hardware circuits and software, such as (as applicable) :
(i) a combination of analog and/or digital hardware circuit (s) with software/firmware and
(ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and
(c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term 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. The term 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.
As used herein, the term “communication network” refers to a network following any suitable communication standards, such as fifth generation (5G) systems, 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. Furthermore, 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 future fifth generation (5G) new radio (NR) 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.
As used herein, the term “network device” 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 Next Generation NodeB (gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, a low power node such as a femto, a pico, and so forth, depending on the applied terminology and technology. A RAN split architecture comprises a gNB-CU (Centralized unit, hosting RRC, SDAP and PDCP) controlling a plurality of gNB-DUs (Distributed unit, hosting RLC, MAC and PHY) . A network device may correspond to DU part of the IAB node.
The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, 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) . 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 (IoT) 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/or industrial wireless networks, and the like. The terminal device may also correspond to Mobile Termination (MT) part of the integrated access and backhaul (IAB) node (a.k.a. a relay node) . In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.
Although functionalities described herein can be performed, in various example embodiments, in a fixed and/or a wireless network node, in other example embodiments, functionalities may be implemented in a user equipment apparatus (such as a cell phone or tablet computer or laptop computer or desktop computer or mobile IoT device or fixed IoT device) . This user equipment apparatus can, for example, be furnished with corresponding capabilities as described in connection with the fixed and/or the wireless network node (s) , as appropriate. The user equipment apparatus may be the user equipment and/or or a control device, such as a chipset or processor, configured to control the user equipment when installed therein. Examples of such functionalities include the bootstrapping server function and/or the home subscriber server, which may be implemented in the user equipment apparatus by providing the user equipment apparatus with software configured to cause the user equipment apparatus to perform from the point of view of these functions/nodes.
FIG. 1 shows an example communication network 100 in which embodiments of the present disclosure can be implemented. As shown in FIG. 1, the communication network 100 may comprise an IAB donor 101, which may comprise an IAB donor CU 110 (hereinafter may also be referred to as a first device) and an IAB donor DU 120 (hereinafter may also be referred to as a second device) . The communication network 100 may also comprise IAB nodes 102-1 and 102-2, which may also be referred to as an IAB node 102 collectively (Hereinafter the IAB node 102 may also be referred to as a second device) .
The IAB node 102-1 may comprise an IAB DU 130-1 and an IAB mobile termination (IAB MT) 140-1. The IAB node 102-2 may comprise an IAB DU 130-2 and an IAB MT 140-2. The IAB nodes 102-1 and 102-2 may communicate with the IAB donor 101. For example, the IAB nodes 102-1 may communicate with the IAB donor 101 via a  F1 connection established between the IAB donor CU 110 and IAB DU 130-1. Furthermore, a connection may be established between the IAB donor DU 120 and an IAB MT of an IAB node via a Uu interface. For example, a connection may be established between the IAB donor DU 120 and the IAB MT 140-1 of the IAB node 102-1.
The communication network 100 may comprise eNB 150 (hereinafter may also be referred to as a third device 150) , which may communicate with the IAB donor 101 and the IAB node 102-1 or the IAB node 102-2, respectively. As shown in Fig. 1, the communication between the eNB 150 and the IAB donor 101 may be performed via the IAB node 102-2 and the IAB node 102-1. For example, the communication interface between the eNB 150 and IAB donor 101 may use the IAB connectivity between IAB node 102-2 and the IAB donor 101.
It is to be understood that the number of the IAB donors, IAB nodes and the eNBs is given for the purpose of illustration without suggesting any limitations to the present disclosure. The communication network 100 may include any suitable number of IAB donors, IAB nodes and the eNBs adapted for implementing implementations of the present disclosure.
Communications in the communication system 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. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Divided Multiple Address (CDMA) , Frequency Divided Multiple Address (FDMA) , Time Divided Multiple Address (TDMA) , Frequency Divided Duplexer (FDD) , Time Divided Duplexer (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Divided Multiple Access (OFDMA) and/or any other technologies currently known or to be developed in the future.
In the communication network 100 as shown in FIG. 1, for the connection setup and communication with the parent node (which can be an IAB node or an IAB donor) , the IAB donor may initiate the backhaul (BH) Radio Link Control (RLC) channel  establishment towards an IAB node.
IAB introduces a protocol layer to perform routing and bearer mapping to RLC channels on the BH links. The new layer may be called BAP (Backhaul Adaptation Protocol) . The BAP layer has peer entities in the IAB nodes having BH link established starting from IAB donor DU until the access IAB-node where the BH link should reach. Routing in BAP is based on the Routing ID and related routing table configured by the IAB donor CU. The Routing ID may consist of destination BAP address and the path ID. The configured routing table indicates the next-hop BAP node address (i.e., the egress link) where the BH data is to be forwarded. The quality of service (QoS) enforcement bases on the QoS specific BH channels. The mapping of BH data (bearers) to BH link RLC channels are also configured by the IAB donor CU. For example, the mapping can be 1: 1 or N: 1 mapping, where in the former case each bearer may have its own BH RLC channel enabling the use of advanced/optimized scheduling methods, while in N: 1 mapping case, multiple bearers are aggregated in a single BH RLC channel. The aggregation can be, for example, based on QoS class.
On the wireless backhaul, the Internet Protocol (IP) layer may be carried over the BAP sublayer, which may enable routing over multiple hops. The IAB donor DU may act as the first hop router of the IP layer. The IP layer can also be used for non-F1 traffic. The IAB IP layer was one of the main arguments for the specified protocol stack, for example, it has been specified that the IAB IP layer may support generic IP transport for any other nodes or equipment or service at the IAB site, for example, the Operations and Maintenance (OAM) interface for IAB node, other Radio Access Technology (RAT) equipment including long Term Evolution (LTE) and Wireless Local Area Network (WLAN) and other site equipment.
The IAB BH traffic can be classified into User Plane (UP) traffic and non-UP traffic. The UP traffic type consists of F1-U tunnels carrying UE radio bearers between the DU and the CU. The non-UP traffic consists of UE associated F1-C signalling-, non-UE associated F1-C signalling and non-F1 traffic types. The UP traffic may be mapped to QoS specific BH channels on F1-U tunnel granularity, based on the QoS parameters of the UE radio bearer corresponding to the F1-tunnel. The CU may receive all the necessary information for the UE bearer management and BH channel management in a session management signaling from the 5G core network (5GC) . The CU may map the QoS flows to radio bearers and corresponding F1-U tunnels based on QoS profiles and define the QoS  of the radio bearer. The CU may also dynamically establish/release/modify radio bearers corresponding F1 tunnels and BH channels based on the session management signalling from the 5GC.
The mapping of the non-UP traffic to BH channels may be performed on the granularity of the traffic type. The non-UP traffic is RAN internal and not related to UE’s access traffic, so it has no context in 5G core network (CN) and 5G policy framework and therefore it can be fully controlled by the CU.
The non-F1 traffic of an IAB-node may include all IP traffic that is not used for the transport of F1-C or F1-U packets. The non-F1 traffic may include, for example, OAM traffic if it is transferred using the BH RLC channel, non-3GPP signalling like Internet Key Exchange Version 2 (IKEv2) or Stream Control Transmission Protocol (SCTP) connection establishment. In general, the non-F1 traffic type (or IAB IP layer) can be used for transporting any IP traffic between the IAB node and IAB donor DU and between IAB nodes.
As described, the IAB IP layer may be used for transporting highly dynamic non-F1 IP traffic that varies in volume and QoS requirement. One example of such usage is backhauling LTE base stations. The load of eNB may change rapidly over time and QoS requirements of EPS bearers may also vary.
Such a dynamic traffic necessitates dynamic BH channel management from the IAB Control Plane (CP) , otherwise the limited radio resources may be wasted.
Currently, the dynamic BH channel management for non-F1 traffic is still impossible. On the one hand, the CU does not receive information about non-F1 sessions through the CP, because 5GC does not have context for non-F1 traffic and the traffic source/sink, for example the eNB, does not have direct CP interface with the CU or the CP interface does not support the management of the non-F1 session. On the other hand, the CU may not receive information through user plane by traffic inspection, because the traffic may be routed directly from IAB donor DU to destination, so it may bypass the CU. Furthermore, traffic differentiation inside the non-F1 traffic type may not be supported by the current specification.
Therefore, the solution of the present disclosure proposes a mechanism for supporting the traffic flow detection in the IAB network or in an LTE eNB connected over the IAB network. In this solution, the IAB donor CU may receive a service request  including information related to at least one traffic flow associated with an eNB or some other node (e.g., from the other radio access technology (RAT) ) connected over the IAB network from an IAB node, an IAB donor DU or the eNB. The IAB donor CU may determine, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow and transmit the mapping configuration to the IAB node or the IAB donor DU.
In this way, a service request procedure for the detected traffic flow may be introduced for supporting the traffic flow detection in the IAB network or in an LTE eNB connected over the IAB network.
Principle and implementations of the present disclosure will be described in detail below with reference to FIGs. 2 to 4.
Now the reference is made to FIG. 2, which shows a signaling chart a process 200 of service request in an IAB network according to some example embodiments of the present disclosure. For the purpose of discussion, the process 200 will be described with reference to FIG. 1. The process 200 may involve the IAB donor CU 110, the IAB donor DU 120, the IAB node 102, the eNB 150 and a Mobility Management Entity (MME) 230. In some scenarios associated with the FIG. 2, the eNB 150 is integrated with the IAB node 102.
As shown in FIG. 2, the MME 230 transmit 202 a S1 application signaling to the eNB 150 to request, from the eNB, Evolved Packet System (EPS) bearer establishment or modification.
Then the IAB node 102 may detect 204 the EPS bearer establishment/modification or the QoS change at the eNB 150. For example, in a case where the eNB 150 is integrated with the IAB node 102, as shown in FIG. 2, the LTE control plane events and the eNB’s bearer context may be visible to the control entity of the IAB node 102.
The IAB node 102 may transmit 206 a service request to the IAB donor CU 110. The service request may comprise information related to at least one traffic flow associated with the eNB 150, which may comprise, for example, flow descriptors and QoS descriptors.
In some example embodiments, for the uplink (UL) flow transmission, the flow descriptors may include tunnel information related to the eNB, such as an UL Full Qualified Tunnel Endpoint Identifier (F-TEID) of the eNBs S1-U tunnel, IP flow label, a Differentiated Services Code Point (DSCP) associated with at least one UL traffic flow  and/or address information related to the source and destination of the at least one traffic flow, such as the source IP address and the destination IP address.
In some example embodiments, the flow descriptors for the downlink (DL) flow transmission may include information such as a DSCP associated with at least one DL traffic flow, the IP flow label, and/or address information related to the source and destination of the at least one traffic flow, such as the source IP address and the destination IP address and/or a DL F-TEID.
In some example embodiments, the QoS descriptor may include one or more LTE QoS parameters, such as QoS Class Identifier (QCI) , Allocation and Retention Priority (ARP) , Guaranteed Bit Rate (GBR) , and/or Max Bit Rate (MBR) . The QoS descriptor may also indicate a DSCP associated with the at least one traffic flow or any other suitable QoS references.
In some example embodiments, the IAB node 102 may transmit the service request to the IAB donor CU 110 via a Radio Resource Control (RRC) signalling.
As another option, it is possible that the IAB node 102 may transmit the service request to the IAB donor CU 110 via a F1 application message that is used in the F1 application protocol.
After receiving the service request, the IAB donor CU 110 may determine 208 a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
For example, the IAB donor CU 110 may map the QoS descriptors to 5G QoS parameters and perform admission control. The IAB donor CU 110 may be pre-configured with the mapping table from QoS descriptors to 5G QoS parameters. For example, LTE QoS parameters are mapped to 5G QoS parameters.
In some example embodiments, the mapping configuration may comprise routing information for the at least one traffic flow associated with the eNB 150, mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows.
Furthermore, the IAB donor CU 110 may also determine a channel configuration  of at least one backhaul channel based on the received information. For example, the channel configuration may be configured for establishing the at least one backhaul channel, or modifying the at least one backhaul channel.
For example, the IAB donor CU 110 may configure at least one BH channel between the IAB node 102 and the IAB donor DU 120 to meet QoS requirements of the new flow and configure DL routing and channel mapping to the IAB donor DU 120, for example, based on the flow and QoS descriptors included into the service request message.
As shown in FIG. 2, the IAB donor CU 110 may transmit 210 a UE context modification request to the IAB donor DU 120, via a F1 AP procedure. The IAB donor DU 120 may transmit 212 the UE context modification response to the IAB donor CU 110.
The IAB donor CU 110 may generate a service response including the determined mapping configuration and optionally the channel configuration and transmit the service response message to the IAB node 102. It is to be understood that the channel configuration can be transmitted in another message other than the service response.
For example, as shown in FIG. 2, the IAB donor CU 110 may transmit 214, to the IAB node 102, a RRC reconfiguration message of the BH channel establishment/modification procedure including the service response message. After the RRC reconfiguration completes, the IAB node 102 may transmit 216 a RRC reconfiguration complete message to the IAB donor CU 110. It is to be understood that the service response message may also be transmit in a separate RRC message.
As another option, the IAB donor CU 110 may transmit 218 the service response to the IAB node 102 via a F1 application message.
Then the eNB 150 may perform 220 admission controls for the EPS bearer with the IAB node 102 by taking the admission control result from the IAB donor CU 110 into account. The eNB 150 may further transmit 222 EPS bearer setup response to MME 230.
It is to be understood that the detection of new flow or changed QoS depends on the integration level of the eNB 150 and IAB node 102. If the eNB 150 is integrated with the IAB node 102, the control entity of the IAB node 102 may observe eNB’s CP transactions and bearer context, thus the service detection does not necessitate UP monitoring. In this integrated model, the IAB node 102 may also utilize all UP-protocol layers that are visible at the eNB 150 in traffic mapping to BH channels, for example F-TEIDs of the S1 tunnels. It is also possible to use LTE QoS parameters as QoS  descriptors in service request.
If the eNB 150 is external to the IAB node 102, the IAB node 102 may need to detect service flow and its QoS requirements from the UP packets (BAP Service Data Units (SDUs) ) . The UP may be encrypted, for example S1-U interface may often be secured with IPSec, leaving only outer IP address visible to the IAB node 102, so the detection may be based on the information carried in the IP header. Similarly, the traffic mapping to BH channels at the access IAB node 102 (and the IAB donor DU 120 in DL) may need to be based on the IP header information. In this scenario the traffic detection and service request could also be performed by the IAB donor DU 120, where the BAP SDUs are also visible. A process of service request in an IAB network in the scenario in which the eNB is external to the IAB node may be further described as below.
Now the reference is made to FIG. 3, which shows a signaling chart a process 300 of service request in an IAB network according to some example embodiments of the present disclosure. For the purpose of discussion, the process 300 will be described with reference to FIG. 1. The process 300 may involve the IAB donor CU 110, the IAB donor DU 120, the IAB node 102, the eNB 150 and a MME 330. In some scenarios associated with the FIG. 3, the eNB 150 is external to the IAB node 102.
Similar with the process 200, the MME 330 of process 300 transmits 302 a S1 application signaling to the eNB 150 to request, from the eNB, EPS bearer establishment or modification for the EPC.
After performing the admission control for LTE bearer, the eNB 150 may transmit 304 a bearer setup/modify response to the MME 330 via a S1 application signaling.
The IAB node 102 may detect at least one traffic flow (i.e., from the UP traffic) associated with the eNB 150, either from the eNB 150 or from the MME 330. Alternatively, the QoS detection may also be performed at the IAB donor DU 120.
After the at least one traffic flow has been detected, the IAB node 102 may transmit 306 a service request to the IAB donor CU 110. The service request may comprise information related to at least one traffic flow associated with the eNB 150, which may comprise, for example, flow descriptors and QoS descriptors.
In some example embodiments, the QoS descriptors may comprise a DSCP associated with the at least one traffic flow. The flow descriptors may comprise a DSCP associated with the at least one traffic flow and/or address information related to the source  and destination of the at least one traffic flow, such as Internet Protocol version 6 (IPv6) flow label, source IP address and the destination IP address.
In some example embodiments, the IAB node 102 may transmit the service request to the IAB donor CU 110 via a Radio Resource Control (RRC) signalling.
Similar with the process 200, after receiving the service request, the IAB donor CU 110 may determine 308 a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
In some example embodiments, the mapping configuration may comprise routing information for the at least one traffic flow associated with the eNB 150, mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows.
Furthermore, the IAB donor CU 110 may also determine a channel configuration of at least one backhaul channel based on the received information. For example, the channel configuration may be configured for establishing the at least one backhaul channel, or modifying the at least one backhaul channel.
Then the IAB donor CU 110 may transmit 310 a UE context modification request to the IAB donor DU 120, via a F1 AP procedure. The IAB donor DU 120 may transmit 312 the UE context modification response to the IAB donor CU 110.
The IAB donor CU 110 may generate a service response including the determined mapping configuration and optionally the channel configuration and transmit the service response message to the IAB node 102. It is to be understood that the channel configuration can be transmitted in another message other than the service response.
As shown in FIG. 3, the IAB donor CU 110 may transmit 314, to the IAB node 102, a RRC reconfiguration message of the BH channel establishment/modification procedure including the service response message. After the RRC reconfiguration completes, the IAB node 102 may transmit 316 an RRC reconfiguration complete message to the IAB donor CU 110.
In some example embodiments, it is also possible that the service request to the IAB donor CU 110 may not come from the IAB node 102, but from the LTE eNB 150 over  X2/Xn interface set up between the eNB 150 and the IAB donor CU 110. Now the reference is made to FIG. 4, which shows a signaling chart a process 400 of service request in an IAB network according to some example embodiments of the present disclosure. For the purpose of discussion, the process 400 will be described based on FIG. 1. The process 400 may involve the IAB donor CU 110, the IAB donor DU 120, the IAB node 102, the eNB 150 and a MME 430.
In the process 400, at set-up of such an X2/Xn interface, the eNB 150 may identify (some characteristic of) the IAB node 102 which has used to be or it is using for its connectivity. Based on the identified information, as shown in FIG. 4, the eNB 150 may transmit 402 an X2 message (for example, an X2 request message or an X2 setup request message) to the IAB donor CU 110. The X2 message may be indicative of an IAB node 102 used for connectivity with the eNB 150. Then the IAB donor CU 110 may transmit 404 an X2 message (for example, an X2 response message or X2 setup response message) to the eNB 150 in response to the X2 message from the eNB 150.
The MME 430 may transmit 406 a S1 application signaling to the eNB 150 to request, from the eNB, EPS bearer establishment or modification. After checking the admission control for LTE bearer, the eNB may transmit 408 the service request to the IAB donor CU 110. The service request may comprise information related to at least one traffic flow associated with the eNB 150. For example, the information may comprise full LTE QoS parameters.
Based on the received information, the IAB donor CU 110 may determine 410 a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
In some example embodiments, the mapping configuration may comprise routing information for the at least one traffic flow associated with the eNB 150, mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows.
Furthermore, the IAB donor CU 110 may also determine a channel configuration of at least one backhaul channel based on the received information. For example, the channel configuration may be configured for establishing the at least one backhaul channel,  or modifying the at least one backhaul channel.
As shown in FIG. 4, the IAB donor CU 110 may transmit 412 a UE context modification request to the IAB donor DU 120, via a F1 AP procedure. The IAB donor DU 120 may transmit 414 the UE context modification response to the IAB donor CU 110.
The IAB donor CU 110 may transmit 416, to the IAB node 102, an RRC reconfiguration message of the BH channel establishment/modification procedure, which may include the determined mapping configuration and optionally the channel configuration. It is to be understood that the channel configuration can be transmitted in another message. After the RRC reconfiguration completes, the IAB node 102 may transmit 418 an RRC reconfiguration complete message to the IAB donor CU 110. The IAB donor CU 110 may also send the mapping configuration to the IAB node 102 via F1AP message (not shown in the figure) .
The IAB donor CU 110 may transmit 420 a service response message to the eNB 150 via an X2 application protocol message. For example, the service response may indicate that the at least one traffic flow associated with the eNB 150 is allowed to be communicated. Then the eNB 150 may transmit 422 a S1 application signaling including the bearer setup/modify response to the MME 430.
In this case, regardless of whether the eNB 150 is integrated with the IAB node 102, full LTE Qos parameters may be usable in the service request, and the IAB admission control may be part of the eNB’s admission control for the new or modified LTE bearer (as requested by the MME 430) .
In this way, a service request procedure for the detected traffic flow may be introduced for supporting the traffic flow detection in the IAB network or in an LTE eNB connected over the IAB network.
FIG. 5 shows a flowchart of an example method 500 of service request in an IAB network according to some example embodiments of the present disclosure. The method 500 can be implemented at the first device 110 as shown in FIG. 1. For the purpose of discussion, the method 500 will be described with reference to FIG. 1.
At 510, the first device 110 receives, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device.
In some example embodiments, the first device may receive the service request via a radio resource control signaling or in an application protocol procedure.
In some example embodiments, the information comprises at least one of tunnel information related to the third device connected with the second device, address information related to a transmitter and/or a receiver of the at least one traffic flow, a flow label for the at least one traffic flow, or one or more parameters of a quality of service associated with the at least one traffic flow.
At 520, the first device 110 determines, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
In some example embodiments, the mapping configuration comprises at least one of routing information for the at least one traffic flow, mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows.
At 530, the first device 110 transmits, to the second device, a first message including the mapping configuration.
In some example embodiments, the first device may determine a channel configuration of at least one backhaul channel based on the received information, and transmit a second message including the channel configuration to the second device for one of establishing the at least one backhaul channel, or modifying the at least one backhaul channel.
In some example embodiments, the first device may determine a channel configuration of at least one backhaul channel based on the received information; and transmit the channel configuration to the second device via the first message.
In some example embodiments, the first message is transmitted to the second device via at least one of a radio resource control message, an application protocol procedure message or a response message in response to the service request.
In some example embodiments, the second message is transmitted to the second device via a radio resource control signaling or in an application protocol procedure (e.g., F1 application procedure) .
In some example embodiments, the first device may transmit in an application protocol procedure, to the third device, an indication that the at least one traffic flow is allowed.
In some example embodiments, the first device may receive, from the third device, a X2 message (e.g., X2 setup request) from the third device, the X2 message being indicative of a second device used for a connectivity with the third device; and transmit, to the third device, a X2 response message (e.g., X2 setup response message) to the X2 message.
In some example embodiments, the first device comprises an integrated access and backhaul donor centralized unit, the second device comprises an integrated access and backhaul donor distributed unit or an integrated access backhaul node, the third device comprises a long term evolution network device.
FIG. 6 shows a flowchart of an example method 600 of service request in an IAB network according to some example embodiments of the present disclosure. The method 600 can be implemented at the  second device  120 or 102 as shown in FIG. 1. For the purpose of discussion, the method 600 will be described with reference to FIG. 1.
At 610, the second device transmits, to a first device, a service request including information related to at least one traffic flow associated with a third device.
In some example embodiments, the second device may transmit the service request to the first device via a radio resource control signaling or in an application protocol procedure.
In some example embodiments, the information comprises at least one of tunnel information related to the third device connected with the second device, address information related toa transmitter and/or a receiver (for example, a starting point and an end point) of the at least one traffic flow, a flow label for the at least one traffic flow, or one or more parameters of a quality of service associated with the at least one traffic flow.
At 620, the second device receives, from the first device, a first message including a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
In some example embodiments, the mapping configuration comprises at least one of routing information for the at least one traffic flow, mapping information indicative of  mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows
In some example embodiments, the second device may transmit the service request to the first device, if the second device determines that at least one traffic flow associated with the third device or a quality of service change is detected.
In some example embodiments, the second device may receive, from the first device, a second message including the channel configuration of at least one backhaul channel for one of establishing the at least one backhaul channel, or modifying the at least one backhaul channel.
In some example embodiments, the second device may receive, from the first device, a channel configuration of at least one backhaul channel via the first message.
In some example embodiments, the first message is received from the first device in at least one of a radio resource control message, an application protocol procedure message or a response message in response to the service request.
In some example embodiments, the second message is received from the first device via a radio resource control signaling or in an application protocol procedure.
In some example embodiments, the first device comprises an integrated access and backhaul donor centralized unit, the second device comprises an integrated access and backhaul donor distributed unit or an integrated access backhaul node, the third device comprises a long term evolution network device.
FIG. 7 shows a flowchart of an example method 700 of service request in an IAB network according to some example embodiments of the present disclosure. The method 700 can be implemented at the third device 150 as shown in FIG. 1. For the purpose of discussion, the method 700 will be described with reference to FIG. 1.
At 710, the third device transmit, to a first device, a service request including information related to at least one traffic flow associated with the third device.
In some example embodiments, the service request is transmitted to the first device in an application protocol procedure.
In some example embodiments, the information comprises one or more parameters of a quality of service associated with the at least one traffic flow.
In some example embodiments, the third device may receive in an application protocol procedure, from the first device, an indication that the at least one traffic flow is allowed.
In some example embodiments, the third device may transmit, to the first device, a X2 message from the third device, the X2 message being indicative of a second device used for a connectivity with the third device; and receive, from the first device, a X2 response message to the X2 message.
In some example embodiments, if the third device determines that at least one backhaul channel associated with the at least one traffic flow has been established or modified by a second device, or at least one traffic flow is allowed, the third device may perform a communication for the at least one traffic flow associated with the third device.
In some example embodiments, the first device comprises an integrated access and backhaul donor centralized unit or donor node and the third device comprises a long term evolution network device.
In some example embodiments, the second device comprises an integrated access and backhaul donor distributed unit or an integrated access backhaul node.
In some example embodiments, an apparatus capable of performing the method 500 (for example, implemented at the first device 110) may comprise means for performing the respective steps of the method 500. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.
In some example embodiments, the apparatus comprises means for receiving, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device; means for determining, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow; and means for transmitting, to the second device, a first message including the mapping configuration.
In some example embodiments, an apparatus capable of performing the method 600 (for example, implemented at the second device 120 or 102) may comprise means for performing the respective steps of the method 600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.
In some example embodiments, the apparatus comprises means for transmitting, to a first device, a service request including information related to at least one traffic flow associated with a third device; and means for receiving, from the first device, a first message including a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
In some example embodiments, an apparatus capable of performing the method 700 (for example, implemented at the third device 150) may comprise means for performing the respective steps of the method 700. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.
In some example embodiments, the apparatus comprises means for transmitting, to a first device, a service request including information related to at least one traffic flow associated with the third device.
FIG. 8 is a simplified block diagram of a device 800 that is suitable for implementing embodiments of the present disclosure. The device 800 may be provided to implement the communication device, for example the IAB donor CU 110, the IAB donor DU 120, the IAB node 102, or the eNB 150 as shown in FIG. 1. As shown, 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 may be for bidirectional communications. The communication module 840 may have 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. In some example embodiments, the communication module 840 may include at least one antenna.
The processor 810 may be of any type suitable to the local 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. Examples of 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) , and other magnetic storage and/or optical storage. Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 822 and other volatile memories that will not last in the power-down duration.
computer program 830 includes computer executable instructions that may be executed by the associated processor 810. The program 830 may be stored in the ROM 824. The processor 810 may perform any suitable actions and processing by loading the program 830 into the RAM 822.
The 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 embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.
In some embodiments, 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 the like.
FIG. 9 shows an example of the computer readable medium 900 in form of CD or DVD. The computer readable medium has the program 830 stored thereon.
Generally, 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, device, 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 real or virtual processor, to carry out the methods 200-700 as described above with reference to FIGs. 2-7. Generally, 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 device, 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.
In the context of the present disclosure, the computer program codes or related data may be carried by any suitable carrier to enable the device, device 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, device, 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.
Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.
Although the present disclosure has been described in languages specific to structural features and/or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims (62)

  1. A first device 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 device at least to:
    receive, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device;
    determine, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow; and
    transmit, to the second device, a first message including the mapping configuration.
  2. The first device of claim 1, wherein the first device is caused to receive the service request by:
    receiving the service request via a radio resource control signaling or in an application protocol procedure.
  3. The first device of claim 1 or 2, wherein the information comprises at least one of:
    tunnel information related to the third device connected with the second device,
    one or more differentiated services code points associated with the at least one traffic flow,
    address information related to a transmitter and/or a receiver of the at least one traffic flow,
    a flow label for the at least one traffic flow, or
    one or more parameters of a quality of service associated with the at least one traffic flow.
  4. The first device of claim 1, wherein the first device is further caused to:
    determine a channel configuration of at least one backhaul channel based on the received information, and
    transmit a second message including the channel configuration to the second  device for one of:
    establishing the at least one backhaul channel, or
    modifying the at least one backhaul channel.
  5. The first device of claim 1, wherein the first device is further caused to:
    determine a channel configuration of at least one backhaul channel based on the received information; and
    transmit the channel configuration to the second device via the first message.
  6. The first device of claim 1, wherein the mapping configuration comprises at least one of:
    routing information for the at least one traffic flow,
    mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or
    mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows.
  7. The first device of claim 1 or 5, wherein the first message is at least one of:
    a radio resource control message;
    an application protocol message, or
    a response message in response to the service request.
  8. The first device of claim 4, wherein the second message is transmitted to the second device via a radio resource control signaling or in an application protocol procedure.
  9. The first device of claim 1, wherein the first device is further caused to:
    transmit, to the third device, an indication that the at least one traffic flow is allowed in an application protocol procedure.
  10. The first device of claim any of claims 1, 4, 5, and 9, wherein the first device is further caused to:
    receive, from the third device, a X2 message from the third device, the X2 message being indicative of a second device used for a connectivity with the third device; and
    transmit, to the third device, a X2 response message to the X2 message.
  11. The first device of any of claims 1-10, wherein the first device comprises an integrated access and backhaul donor centralized unit, the second device comprises an integrated access and backhaul donor distributed unit or an integrated access backhaul node, the third device comprises a long term evolution network device.
  12. A second device 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 device at least to:
    transmit, to a first device, a service request including information related to at least one traffic flow associated with a third device; and
    receive, from the first device, a first message including a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
  13. The second device of claim 12, wherein the second device is caused to transmit the service request by:
    transmitting the service request to the first device via a radio resource control signaling or in an application protocol procedure.
  14. The second device of claim 12, wherein the information comprises at least one of:
    tunnel information related to the third device connected with the second device,
    one or more differentiated services code points associated with the at least one traffic flow,
    address information related to a transmitter and/or a receiver of the at least one traffic flow,
    a flow label for the at least one traffic flow, or
    one or more parameters of a quality of service associated with the at least one traffic flow.
  15. The second device of claim 12, wherein the second device is caused to transmit  the service request by:
    in accordance with a determination that the at least one traffic flow associated with the third device or a quality of service change is detected, transmitting the service request to the first device.
  16. The second device of claim 12, wherein the second device is further caused to:
    receive, from the first device, a second message including the channel configuration of at least one backhaul channel for one of:
    establishing the at least one backhaul channel, or
    modifying the at least one backhaul channel.
  17. The second device of claim 12, wherein the second device is further caused to:
    receive, from the first device, a channel configuration of at least one backhaul channel via the first message.
  18. The second device of claim 12, wherein the mapping configuration comprises at least one of:
    routing information for the at least one traffic flow,
    mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or
    mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows.
  19. The second device of claim 12 or 14, wherein the first message is at least one of:
    a radio resource control message;
    an application protocol message, or
    a response message in response to the service request.
  20. The second device of claim 16, wherein the second message is received from the first device via a radio resource control signaling or in an application protocol procedure.
  21. The second device of any of claims 12-20, wherein the first device comprises  an integrated access and backhaul donor centralized unit, the second device comprises an integrated access and backhaul donor distributed unit or an integrated access backhaul node, the third device comprises a long term evolution network device.
  22. A third device 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 third device at least to:
    transmit, to a first device, a service request including information related to at least one traffic flow associated with the third device.
  23. The third device of claim 22, wherein the service request is transmitted to the first device in an application protocol procedure.
  24. The third device of claim 22, wherein the information comprises one or more parameters of a quality of service associated with the at least one traffic flow.
  25. The third device of claim 22, wherein the third device is further caused to:
    receive, from the first device, an indication that the at least one traffic flow is allowed in an application protocol procedure.
  26. The third device of claim 22, wherein the third device is further caused to:
    transmit, to the first device, a X2 message from the third device, the X2 message being indicative of a second device used for a connectivity with the third device; and
    receive, from the first device, a X2 response message to the X2 message.
  27. The third device of claim 22, wherein the third device is further caused to:
    in accordance with a determination that at least one backhaul channel associated with the at least one traffic flow has been established or modified by a second device, or at least one traffic flow is allowed, perform a communication for the at least one traffic flow associated with third device.
  28. The third device of any of claims 22-27, wherein the first device comprises an  integrated access and backhaul donor centralized unit and the third device comprises a long term evolution network device.
  29. The third device of claim 26 or 27, wherein the second device comprises an integrated access and backhaul donor distributed unit or an integrated access backhaul node.
  30. A method comprising:
    receiving, at a first device and from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device;
    determining, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow; and
    transmitting, to the second device, a first message including the mapping configuration.
  31. The method of claim 30, wherein receiving the service request comprises:
    receiving the service request via a radio resource control signaling or in an application protocol procedure.
  32. The method of claim 30 or 31, wherein the information comprises at least one of:
    tunnel information related to the third device connected with the second device,
    one or more differentiated services code points associated with the at least one traffic flow,
    address information related to a transmitter and/or a receiver of the at least one traffic flow,
    a flow label for the at least one traffic flow, or
    one or more parameters of a quality of service associated with the at least one traffic flow.
  33. The method of claim 30, further comprising:
    determining a channel configuration of at least one backhaul channel based on the received information, and
    transmitting a second message including the channel configuration to the second device for one of:
    establishing the at least one backhaul channel, or
    modifying the at least one backhaul channel.
  34. The method of claim 30, further comprising:
    determining a channel configuration of at least one backhaul channel based on the received information; and
    transmitting the channel configuration to the second device via the first message.
  35. The method of claim 30, wherein the mapping configuration comprises at least one of:
    routing information for the at least one traffic flow,
    mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or
    mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows.
  36. The method of claim 30 or 34, wherein the first message is at least one of:
    a radio resource control message;
    an application protocol message, or
    a response message in response to the service request.
  37. The method of claim 30, wherein the second message is transmitted to the second device via a radio resource control signaling or in an application protocol procedure.
  38. The method of claim 30, further comprising:
    transmitting, to the third device, an indication that the at least one traffic flow is allowed in an application protocol procedure.
  39. The method of claim 30, further comprising:
    receiving, from the third device, a X2 message from the third device, the X2 message being indicative of a second device used for a connectivity with the third device; and
    transmitting, to the third device, a X2 response message to the X2 message.
  40. The method of any of claims 30-39, wherein the first device comprises an integrated access and backhaul donor centralized unit, the second device comprises an integrated access and backhaul donor distributed unit or an integrated access backhaul node, the third device comprises a long term evolution network device.
  41. A method comprising:
    transmitting, from a second device and to a first device, a service request including information related to at least one traffic flow associated with a third device; and
    receive, from the first device, a first message including a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
  42. The method of claim 41, wherein transmitting the service request comprises:
    transmitting the service request to the first device via a radio resource control signaling or in an application protocol procedure.
  43. The method of claim 41, wherein the information comprises at least one of:
    tunnel information related to the third device connected with the second device,
    one or more differentiated services code points associated with the at least one traffic flow,
    address information related to a transmitter and/or a receiver of the at least one traffic flow,
    a flow label for the at least one traffic flow, or
    one or more parameters of a quality of service associated with the at least one traffic flow.
  44. The method of claim 41, wherein transmitting the service request comprises:
    in accordance with a determination that the at least one traffic flow associated with the third device or a quality of service change is detected, transmitting the service request to the first device.
  45. The method of claim 41, further comprising:
    receiving, from the first device, a second message including the channel  configuration of at least one backhaul channel for one of:
    establishing the at least one backhaul channel, or
    modifying the at least one backhaul channel.
  46. The method of claim 41, further comprising:
    receiving, from the first device, a channel configuration of at least one backhaul channel via the first message.
  47. The method of claim 41, wherein the mapping configuration comprises at least one of:
    routing information for the at least one traffic flow, or
    mapping information indicative of mapping relationship between the at least one backhaul channel and one or more uplink traffic flows, or
    mapping information indicative of mapping relationship between the at least one backhaul channel and one or more downlink traffic flows.
  48. The method of claim 41 or 46, wherein the first message is at least one of:
    a radio resource control message;
    an application protocol message, or
    a response message in response to the service request.
  49. The method of claim 45, wherein the second message is received from the first device via a radio resource control signaling or in an application protocol procedure.
  50. The method of any of claims 41-49, wherein the first device comprises an integrated access and backhaul donor centralized unit, the second device comprises an integrated access and backhaul donor distributed unit or an integrated access backhaul node, the third device comprises a long term evolution network device.
  51. A method comprising:
    transmitting, to a first device, a service request including information related to at least one traffic flow associated with the third device.
  52. The method of claim 51, wherein the service request is transmitted to the first  device in an application protocol procedure.
  53. The method of claim 51, wherein the information comprises one or more parameters of a quality of service associated with the at least one traffic flow.
  54. The method of claim 51, further comprising:
    receiving, from the first device, an indication that the at least one traffic flow is allowed in an application protocol procedure.
  55. The method of claim 51, further comprising:
    transmitting, to the first device, a X2 message from the third device, the X2 message being indicative of a second device used for a connectivity with the third device; and
    receiving, from the first device, a X2 response message to the X2 message.
  56. The method of claim 51, further comprising:
    in accordance with a determination that at least one backhaul channel associated with the at least one traffic flow has been established or modified by a second device, or at least one traffic flow is allowed, performing a communication for the at least one traffic flow associated with third device.
  57. The method of any of claims 51-56, wherein the first device comprises an integrated access and backhaul donor centralized unit and the third device comprises a long term evolution network device.
  58. The method of claim 55 or 56, wherein the second device comprises an integrated access and backhaul donor distributed unit or an integrated access backhaul node.
  59. An apparatus comprising:
    means for receiving, from a second device or a third device, a service request including information related to at least one traffic flow associated with the third device;
    means for determining, based on the received information, a mapping configuration for a mapping between at least one backhaul channel and the at least one  traffic flow; and
    means for transmitting, to the second device, a first message including the mapping configuration.
  60. An apparatus comprising:
    means for transmitting, to a first device, a service request including information related to at least one traffic flow associated with a third device; and
    means for receiving, from the first device, a first message including a mapping configuration for a mapping between at least one backhaul channel and the at least one traffic flow.
  61. An apparatus comprising:
    means for transmitting, to a first device, a service request including information related to at least one traffic flow associated with the third device.
  62. A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any of claims 30-40, the method of any of claims 41-50, or the method of any of claims 51-58.
PCT/CN2022/076251 2022-02-14 2022-02-14 Service request in an integrated access and backhaul network WO2023151096A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/076251 WO2023151096A1 (en) 2022-02-14 2022-02-14 Service request in an integrated access and backhaul network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/076251 WO2023151096A1 (en) 2022-02-14 2022-02-14 Service request in an integrated access and backhaul network

Publications (1)

Publication Number Publication Date
WO2023151096A1 true WO2023151096A1 (en) 2023-08-17

Family

ID=87563456

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/076251 WO2023151096A1 (en) 2022-02-14 2022-02-14 Service request in an integrated access and backhaul network

Country Status (1)

Country Link
WO (1) WO2023151096A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102742338A (en) * 2010-02-02 2012-10-17 诺基亚公司 Methods and apparatuses for resource mapping for multiple transport blocks over wireless backhaul link
US20200252847A1 (en) * 2019-02-06 2020-08-06 Kyungmin Park Base Station Backhaul Link Information
US20210127319A1 (en) * 2018-04-05 2021-04-29 Zte Corporation Method for performing relay forwarding on integrated access and backhaul links, information acquisition method, node, and storage medium

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102742338A (en) * 2010-02-02 2012-10-17 诺基亚公司 Methods and apparatuses for resource mapping for multiple transport blocks over wireless backhaul link
US20210127319A1 (en) * 2018-04-05 2021-04-29 Zte Corporation Method for performing relay forwarding on integrated access and backhaul links, information acquisition method, node, and storage medium
US20200252847A1 (en) * 2019-02-06 2020-08-06 Kyungmin Park Base Station Backhaul Link Information

Similar Documents

Publication Publication Date Title
US20220166498A1 (en) Resource coordination for integrated access and backhaul
US9794816B2 (en) User equipment reallocation between nodes
US9119154B2 (en) Opportunistic carrier aggregation for dynamic flow switching between radio access technologies
US8958809B2 (en) Hybrid coordinated scheduling scheme for use in a radio access network
US11470665B2 (en) Negotiation on bearer type configurations
EP3691166A1 (en) Communication method and communication apparatus
WO2022067542A1 (en) Configuration of small data transmission
WO2022082671A1 (en) Transferring traffic in integrated access and backhaul communication
WO2023151096A1 (en) Service request in an integrated access and backhaul network
US20230284246A1 (en) Devices, methods, apparatuses and computer readable media for topology redundancy
US20230292191A1 (en) Mechanism for cell identity management
WO2017114218A1 (en) Method and device for dividing resource
US20220312287A1 (en) Device, method, apparatus and computer readable medium for inter-cu topology adaptation
US20220256434A1 (en) Method, device and computer readable medium for controlling d2d routing
WO2022094818A1 (en) Routing in integrated access and backhaul communication
WO2024055172A1 (en) Traffic transferring in user equipment-to-network relay scenario
WO2022226838A1 (en) Packets re-routing
WO2023230882A1 (en) Traffic offloading
WO2023236065A1 (en) Configuration of time sensitive networking
WO2023283878A1 (en) Tsn fully distributed model enhancement
US20230300685A1 (en) Device, method, apparatus and computer readable medium for iab communication
WO2021217424A1 (en) Backup traffic handling
WO2022056686A1 (en) Device, method, apparatus and computer readable medium for iab communication
WO2020227906A1 (en) Mapping of bearer identification into ipv6 architecture
WO2023004697A1 (en) User plane forwarding between user plane function and application function

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: 22925458

Country of ref document: EP

Kind code of ref document: A1