WO2024168738A1

WO2024168738A1 - Method, device and computer storage medium of communication

Info

Publication number: WO2024168738A1
Application number: PCT/CN2023/076591
Authority: WO
Inventors: You Li; Gang Wang
Original assignee: Nec Corporation
Priority date: 2023-02-16
Filing date: 2023-02-16
Publication date: 2024-08-22

Abstract

Embodiments of the present disclosure provide a solution for transmission and configuration on indirect path. In a solution, a remote terminal device determines, at least one radio bearer (RB) of the remote terminal device capable of communicating with a network device via an indirect path, the at least one RB being associated with the indirect path, the indirect path comprising a first hop between the remote terminal device and a relay terminal device and a second hop between the relay terminal device and the network device, the first hop being a non-PC5 connection; and performs, based at least in part on the at least one RB, a communication with the network device via the indirect path.

Description

METHOD, DEVICE AND COMPUTER STORAGE MEDIUM OF COMMUNICATION

TECHNICAL FIELD

Embodiments of the present disclosure generally relate to the field of telecommunication, and in particular, to methods, devices and computer storage media for transmission and configuration on indirect path.

BACKGROUND

Recently, a technology of multi-path is proposed to be supported to enhance reliability and throughput. Specifically, a user equipment (UE) is allowed to communicate with the network via both a direct path and an indirect path, and the UE may switch among or utilize the multiple paths simultaneously. In addition, in case of the indirect path, the UE may connect to the network device via a layer-2 UE-to-network relay, or via another UE.

Further, the indirect path comprises a first hop between the UE and a relay UE and a second hop between the relay UE and the network device. According to current agreements, the first hop may be either a PC5 connection or a non-PC5 connection. Generally speaking, in case that the first hop is a PC5 connection, the protocol stack of the remote UE and the relay UE may reuse conventional wireless communication protocol stack and the communication processes may refer to conventional wireless communication processes (such as, processes for a dual connection, DC) . However, in case that the first hop is a non-PC5 connection, the lower communication entity is multifarious, such as, Bluetooth, WiFi or even a wired communication. Therefore, details about how to configure the indirect path and further enable a multi-path transmission are still pending, and thus are desirable to be further discussed.

SUMMARY

In general, embodiments of the present disclosure provide methods, devices and computer storage media for transmission and configuration on indirect path.

In a first aspect, there is provided a remote terminal device comprising: a processor configured to cause the remote terminal device to: determine at least one radio bearer (RB) of the remote terminal device capable of communicating with a network device via an indirect path, the at least one RB being associated with the indirect path, the indirect path comprising a first hop between the remote terminal device and a relay terminal device and a second hop between the relay terminal device and the network device, the first hop being a non-PC5 connection; and perform, based at least in part on the at least one RB, a communication with the network device via the indirect path.

In a second aspect, there is provided a relay terminal device comprising: a processor configured to cause the relay terminal device to: determine at least one channel between the relay terminal device and the network device, the at least one channel being associated with at least one radio bearer (RB) of a remote terminal device, the remote terminal device capable of communicating with the network device via an indirect path, the indirect path comprising a first hop between the remote terminal device and the relay terminal device and a second hop between the relay terminal device and the network device, the first hop being a non-PC5 connection; and perform, based at least in part on the at least one channel, a communication with the network device and the remote terminal device.

In a third aspect, there is provided a remote terminal device comprising: a processor configured to cause the remote terminal device to: determine total pending data volume for a radio bearer (RB) of the remote terminal device, the remote terminal device capable of communicating with a network device via an indirect path and a direct path, the RB being associated with the indirect path and the direct path; and perform a communication with the network device via one of the indirect and direct path or both of the indirect and direct paths based on at least one of the following: a comparison result between the total pending data volume and data volume threshold, information about channel usage state of the direct path and/or the indirect path, information about transmission capability of the direct path and/or the indirect path.

In a fourth aspect, there is provided a remote terminal device comprising: a processor configured to cause the remote terminal device to: associate a radio bearer (RB) ora plurality of RBs of the remote terminal device with an indirect path and a direct path, the remote terminal device capable of communicating with a network device via the indirect path and a direct path; and perform a multi-path transmission of the RB with the network device based on the association.

In a fifth aspect, there is provided a network device comprising: a processor configured to cause the network device to: determine at least one radio bearer (RB) of a remote terminal device capable of communicating with the network device via an indirect path, the at least one RB being associated with the indirect path, the indirect path comprising a first hop between the remote terminal device and a relay terminal device and a second hop between the relay terminal device and the network device, the first hop being a non-PC5 connection; and indicate the at least one RB to the remote terminal device.

In a sixth aspect, there is provided a network device comprising: a processor configured to cause the network device to: determine at least one channel between the relay terminal device and the network device, the at least one channel being associated with an indirect path, the indirect path comprising a first hop between a remote terminal device and the relay terminal device and a second hop between the relay terminal device and the network device, the first hop being a non-PC5 connection, the remote terminal device capable of communicating with the network device via the indirect path; and indicate the at least one channel to the relay terminal device.

In a seventh aspect, there is provided a communication method performed by a remote terminal device. The method comprises: determining at least one radio bearer (RB) of the remote terminal device capable of communicating with a network device via an indirect path, the at least one RB being associated with the indirect path, the indirect path comprising a first hop between the remote terminal device and a relay terminal device and a second hop between the relay terminal device and the network device, the first hop being a non-PC5 connection; and performing, based at least in part on the at least one RB, a communication with the network device via the indirect path.

In an eighth aspect, there is provided a communication method performed by a relay terminal device. The method comprises: determining at least one channel between the relay terminal device and the network device, the at least one channel being associated with at least one radio bearer (RB) of a remote terminal device, the remote terminal device capable of communicating with the network device via an indirect path, the indirect path comprising a first hop between the remote terminal device and the relay terminal device and a second hop between the relay terminal device and the network device, the first hop being a non-PC5 connection; and performing, based at least in part on the at least one channel, a communication with the network device and the remote terminal device.

In a ninth aspect, there is provided a communication method performed by a remote terminal device. The method comprises: determining total pending data volume for a radio bearer (RB) of the remote terminal device, the remote terminal device capable of communicating with a network device via an indirect path and a direct path, the RB being associated with the indirect path and the direct path; and performing a communication with the network device via one of the indirect and direct path or both of the indirect and direct paths based on at least one of the following: a comparison result between the total pending data volume and data volume threshold, information about channel usage state of the direct path and/or the indirect path, information about transmission capability of the direct path and/or the indirect path.

In a tenth aspect, there is provided a communication method performed by a remote terminal device. The method comprises: associating a radio bearer (RB) of a plurality of RBs of the remote terminal device with an indirect path and a direct path, the remote terminal device capable of communicating with a network device via the indirect path and a direct path; and performing a multi-path transmission of the RB with the network device based on the association.

In an eleventh aspect, there is provided a communication method performed by a network device. The method comprises: determining at least one radio bearer (RB) of a remote terminal device capable of communicating with the network device via an indirect path, the at least one RB being associated with the indirect path, the indirect path comprising a first hop between the remote terminal device and a relay terminal device and a second hop between the relay terminal device and the network device, the first hop being a non-PC5 connection; and indicating the at least one RB to the remote terminal device.

In a twelfth aspect, there is provided a communication method performed by a network device. The method comprises: determining at least one channel between the relay terminal device and the network device, the at least one channel being associated with an indirect path, the indirect path comprising a first hop between a remote terminal device and the relay terminal device and a second hop between the relay terminal device and the network device, the first hop being a non-PC5 connection, the remote terminal device capable of communicating with the network device via the indirect path; and indicating the at least one channel to the relay terminal device.

In a thirteenth aspect, there is provided a computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to carry out the method according to the first, second, third, fourth, fifth, or sixth aspect.

Other features of the present disclosure will become easily comprehensible through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Through the more detailed description of some embodiments of the present disclosure in the accompanying drawings, the above and other objects, features and advantages of the present disclosure will become more apparent, wherein:

FIG. lA is a block diagrams of an example communication environment in which embodiments of the present disclosure can be implemented;

FIG. 1B is an example protocol structure of a direct path according to some embodiments of the present disclosure;

FIG. 1C is an example protocol structure of a standardized indirect path according to some embodiments of the present disclosure;

FIG. 1D is an example protocol structure of a non-standardized indirect path according to some embodiments of the present disclosure;

FIG. 2 illustrates an example structure for SRAP SDU;

FIG. 3 illustrates a signaling chart illustrating processes for communication according to some embodiments of the present disclosure;

FIG. 4 illustrates another signaling chart illustrating processes for communication according to some embodiments of the present disclosure;

FIG. 5 illustrates another example method of communication implemented at a remote terminal device in accordance with some embodiments of the present disclosure;

FIG. 6 illustrates another example method of communication implemented at a relay terminal device in accordance with some embodiments of the present disclosure;

FIG. 7 illustrates another example method of communication implemented at a remote terminal device in accordance with some embodiments of the present disclosure;

FIG. 8 illustrates another example method of communication implemented at a remote terminal device in accordance with some embodiments of the present disclosure;

FIG. 9 illustrates another example method of communication implemented at a network device in accordance with some embodiments of the present disclosure;

FIG. 10 illustrates another example method of communication implemented at a network device in accordance with some embodiments of the present disclosure; and

FIG. 11 is a simplified block diagram of a device that is suitable for implementing 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 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.

As used herein, the term ‘terminal device’ refers to any device having wireless or wired communication capabilities. Examples of the terminal device include, but not limited to, user equipment (UE) , personal computers, desktops, mobile phones, cellular phones, smart phones, personal digital assistants (PDAs) , portable computers, tablets, wearable devices, internet of things (IoT) devices, Ultra-reliable and Low Latency Communications (URLLC) devices, Internet of Everything (IoE) devices, machine type communication (MTC) devices, device on vehicle for V2X communication where X means pedestrian, vehicle, or infrastructure/network, devices for Integrated Access and Backhaul (IAB) , Space borne vehicles or Air borne vehicles in Non-terrestrial networks (NTN) including Satellites and High Altitude Platforms (HAPs) encompassing Unmanned Aircraft Systems (UAS) , eXtended Reality (XR) devices including different types of realities such as Augmented Reality (AR) , Mixed Reality (MR) and Virtual Reality (VR) , the unmanned aerial vehicle (UAV) commonly known as a drone which is an aircraft without any human pilot, devices on high speed train (HST) , or image capture devices such as digital cameras, sensors, gaming devices, music storage and playback appliances, or Internet appliances enabling wireless or wired Internet access and browsing and the like. The ‘terminal device’ can further have ‘multicast/broadcast’ feature, to support public safety and mission critical, V2X applications, transparent IPv4/Ipv6 multicast delivery, IPTV, smart TV, radio services, software delivery over wireless, group communications and IoT applications. It may also incorporate one or multiple Subscriber Identity Module (SIM) as known as Multi-SIM. The term “terminal device” can be used interchangeably with a UE, a mobile station, a subscriber station, a mobile terminal, a user terminal or a wireless device.

The term “network device” refers to a device which is capable of providing or hosting a cell or coverage where terminal devices can communicate. Examples of a network device include, but not limited to, a Node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a next generation NodeB (gNB) , a transmission reception point (TRP) , a remote radio unit (RRU) , a radio head (RH) , a remote radio head (RRH) , an IAB node, a low power node such as a femto node, a pico node, a reconfigurable intelligent surface (RIS) , and the like.

The terminal device or the network device may have Artificial intelligence (AI) or Machine learning capability. It generally includes a model which has been trained from numerous collected data for a specific function, and can be used to predict some information.

The terminal or the network device may work on several frequency ranges, e.g. FR1 (410 MHz to 7125 MHz) , FR2 (24.25GHz to 71GHz) , frequency band larger than 100GHz as well as Tera Hertz (THz) . It can further work on licensed/unlicensed/shared spectrum. The terminal device may have more than one connection with the network devices under Multi-Radio Dual Connectivity (MR-DC) application scenario. The terminal device or the network device can work on full duplex, flexible duplex and cross division duplex modes.

The embodiments of the present disclosure may be performed in test equipment, e.g. signal generator, signal analyzer, spectrum analyzer, network analyzer, test terminal device, test network device, channel emulator.

In some embodiments, the terminal device may be connected with a first network device and a second network device. One of the first network device and the second network device may be a master node and the other one may be a secondary node. The first network device and the second network device may use different radio access technologies (RATs) . In some embodiments, the first network device may be a first RAT device and the second network device may be a second RAT device. In some embodiments, the first RAT device is eNB and the second RAT device is gNB. Information related with different RATs may be transmitted to the terminal device from at least one of the first network device or the second network device. In some embodiments, first information may be transmitted to the terminal device from the first network device and second information may be transmitted to the terminal device from the second network device directly or via the first network device. In some embodiments, information related with configuration for the terminal device configured by the second network device may be transmitted from the second network device via the first network device. Information related with reconfiguration for the terminal device configured by the second network device may be transmitted to the terminal device from the second network device directly or via the first network device.

As used herein, the singular forms ‘a’ , ‘an’a nd ‘the’a re intended to include the plural forms as well, unless the context clearly indicates otherwise. The term ‘includes’a nd its variants are to be read as open terms that mean ‘includes, but is not limited to. ’ The term ‘based on’ is to be read as ‘at least in part based on. ’ The term ‘one embodiment’a nd ‘an embodiment’a re to be read as ‘at least one embodiment. ’ The term ‘another embodiment’ is to be read as ‘at least one other embodiment. ’ The terms ‘first, ’ ‘second, ’a nd the like may refer to different or same objects. Other definitions, explicit and implicit, may be included below.

In some examples, values, procedures, or apparatus are referred to as ‘best, ’ ‘lowest, ’ ‘highest, ’ ‘minimum, ’ ‘maximum, ’ or the like. It will be appreciated that such descriptions are intended to indicate that a selection among many used functional alternatives can be made, and such selections need not be better, smaller, higher, or otherwise preferable to other selections.

As discussed above, the technology of multi-path is proposed to enhance reliability and throughput. Further, the UE is allowed to communicate with the network via both a direct path and an indirect path, and the UE may switch among or utilize the multiple paths simultaneously.

Further, the indirect path comprises a first hop between the UE and a relay UE and a second hop between the relay UE and the network device. According to current agreements, the first hop may be either a PC5 connection or a non-PC5 connection. Generally speaking, in case that the first hop is PC5 connection, the protocol stack of the UE and the relay UE may reuse conventional wireless communication protocol stack and the communication processes may refer to conventional wireless communication processes. However, in case that the first hop is a non-PC5 connection, the lower communication entity is multifarious, such as, Bluetooth, WiFi or even a wired communication. Therefore, details about how to configure the indirect path and further enable a multi-path transmission is still pending, and thus is desirable to be further discussed.

Embodiments of the present disclosure provide a solution for transmission management and configuration on indirect path. With the present disclosure, even the first hop is a non-PC5 connection, the mapping between the RB (s) of the remote terminal device and the indirect path still may be determined by the remote terminal device while the mapping between the RB (s) of the remote terminal device and the Uu RLC channel (s) of a relay terminal device also still may be determined by the relay terminal device. As a result, the communication between the remote terminal device and the network device via the indirect path/relay terminal device (also referred to as relay transmission) is enabled.

In addition, on the basis that the relay transmission is enabled, a multi-path transmission may be further enabled according to some example embodiments of the present discourse.

Finally, according to some example embodiments of the present discourse, if both the direct path and indirect path are available, the remote terminal device may switch among the direct and indirect paths flexibly. In other words, the remote terminal device may send protocol data units (PDUs) via only one of the direct and indirect paths or either one of the direct and indirect paths.

For ease of discussion, some terms used in the following description are listed as below:

● A direct network connection: refers to one mode of network connection, where there is no relay terminal device/relay UE between a terminal device and the network device. ● An indirect network connection: refers to one mode of network connection, where there is a relay terminal device/relay UE between a remote terminal device and the network devices.

● An indirect path/link/connection: refers to a path between a network device and a remote terminal device via a relay terminal device or multiple relay terminal devices, also referred to as a relay/relaying path sometimes.

Further, the indirect path comprises a first hop between a remote terminal device and a relay terminal device and a second hop between a relay terminal device and a network device. In view of this, the indirect path also may be identified by the first hop or the second hop.

● A first hop/link: refers to a hop between a remote terminal device and a relay terminal device, also referred to as a UE-UE hop.

● A second hop/link: refers to a hop between a relay terminal device and a network device. ● An upper layer: refers to an upper layer of 3GPP, which may be a packet data convergence protocol (PDCP) layer, a sidelink relay adaptation protocol (SRAP) , or a radio resource control (RRC) layer.

● A lower layer: refers to a layer below the upper layer, which may be, a non-PC5 layer, a Wi-Fi layer, a Bluetooth layer, a Zigbee layer, a layer for wired communication, an RLC layer.

● A non-PC5 entity/path/link/connection/interface: refers to an entity/path/link/connection/interface which is not stipulated by the standard documents (such as, 3GPP specification) or is an ideal path/link/connection. Also may be referred to as non-3GPP entity/path/link/connection/interface. Further, a non-standardized/path/link/connection/interface also may be referred to as ideal/path/link/connection. It may be wired or wireless entity/path/link/connection/interface. Examples of non-PC5 entity/path/link/connection, include but are not limited to, Wi-Fi entity/path/link, bluetooth entity/path/link, zigbee entity/path/link, Ethernet entity/path/link.

● A PC5 entity/path/link/connection/interface: refers to an entity/path/link/connection which is stipulated by the standard documents (such as, 3GPP specification) .

In the present discourse, terms of layer and entity may be used interchangeably. Terms of RB ID, bearer ID may be used interchangeably.

Terms “hop” , “link” , “path” and “connection” may be used interchangeably.

Terms “primary” and “anchor” may be used interchangeably.

Terms “entity” , “layer” , “sub-layer” and “channel” may be used interchangeably.

Terms “non-standardized” , “non-3GPP” and “non-PC5” may be used interchangeably.

Terms “PC5” , “sidelink” , “3GPP” and “standardized” may be used interchangeably.

Terms “primary path” , “primary entity” may be used interchangeably.

In the following, an intra-gNB will be used as an example of application scenario for describing some specific example embodiments of the present disclosure. It is noted that example embodiments described with regard to the intra-gNB are equally applicable to scenario of inter-gNB.

In the following, some examples of information element (IE) are illustrated. It should be understood that these examples are illustrated only for the purpose of illustration without suggesting any limitations. In other examples, related IE may include more or less parameters and the name of the parameters in the IE may be changed.

Further, as these IEs or fields discussed herein correspond to one or more new feature of related device. Considering the compatibility, as for the device that supports the new feature (s) , the device may interpret these IEs or fields, while as for the device that does not support the new feature (s) , the device may ignore these IEs or fields. For example, if these new features are stipulated in release 18 of 3GPP, the devices of release 17 may ignore these IEs.

Principles and implementations of the present disclosure will be described in detail below with reference to the figures.

EXAMPLE OF COMMUNICATION NETWORK

FIG. 1A shows an example communication environment 100 in which example embodiments of the present disclosure can be implemented. The communication environment 100 comprises a plurality of terminal devices and a network device. As shown in the FIG. 1A, the communication environment 100 comprises a network device 130, which providing a serving area, called as a cell 102.

Further, the communication environment 100 also comprises terminal devices 110 and 120.

Further, as illustrated in FIG. lA, the terminal device 110 may communicate with the network device 130 via a plurality of paths (also referred to as multi-path) , where each of the plurality of paths may be either a direct path 150 or an indirect path (including a first hop 140-1 and a second hop 140-2) . As shown in FIG. lA, the terminal device 110 may communicate with the network device 130 via the terminal device 120, while the terminal device 110 may communicate with the network device 130 directly. In view of this, the terminal device 110 also may be referred to as a remote terminal device 110, and the terminal device 120 also may be referred to as a relay terminal device 120.

In some embodiments, the remote terminal device 110 may be connected to the network device 130 by using one direct path and one indirect path via layer-2 UE-to-network relay, referred to as scenario #1 sometimes. Alternately, in some embodiments, the remote terminal device 110 may be connected to the network device 130 by using one direct path and one indirect path via the relay terminal device 120 (where the UE-UE inter-connection is assumed to be ideal, referred to as scenario #2 sometimes) .

In some embodiments, it is expected to benefit from multi-path in the following aspects:

Relay and direct multi-path operation (including both scenarios #1 and #2) can provide efficient path switching between direct path and indirect path;

The remote terminal device 110 in multi-path operation can provide enhanced user data throughput and reliability compared to a single link; and

the network device 130 can offioad the direct connection of the remote terminal device 110 in congestion to indirect path via the relay terminal device 120 (for example, at different intra/inter-frequency cells) .

In some embodiments, as for the remote terminal device 110, at least part of the following entities may be configured for the direct path: the SDAP entity, the PDCP entity, the RLC entity, the MAC entity and the PHY entity.

In some embodiments, as for the remote terminal device 110, at least part of the following entities may be configured for a standardized indirect path (i.e., the first hop is a PC5 hop) : the SDAP entity, the PDCP entity, the SRAP entity, the RLC entity, the MAC entity and the PHY entity.

In some embodiments, as for the remote terminal device 110, at least part of the following entities may be configured for a non-standardized indirect path (i.e., the first hop is a non-PC5 connection) : the non-PC5 entity and optional upper entity (ies) .

In summary, the remote terminal device 110 may communicate with the network device 130 via any of the following paths:

A direct path, where the remote terminal device 110 is connected to the network device 130 directly. An example protocol structure 150 of the direct path is illustrated in FIG. lB.

A standardized indirect path, where the remote terminal device 110 is connected to the network device 130 via the relay terminal device 120, and the path between the remote terminal device 110 and the relay terminal device 120 is PC5/sidelink (SL) path. An example protocol structure 160 of the standardized indirect path is illustrated in FIG. 1C.

A non-standardized indirect path, where the remote terminal device 110 is connected to the network device 130 via the relay terminal device 120, and the path between the remote terminal device 110 and the relay terminal device 120 is a non-standardized path. An example protocol structure 170 of the non-standardized indirect path is illustrated in FIG. 1D, where the SRAP entity is not used.

As illustrated in FIG. 1C, in some embodiments, as for scenario #1, an SRAP entity is optionally introduced for the indirect path. In some embodiments, user plane (UP) protocol stacks for U2N RLC channels use the SRAP layer which may provide bearer mapping and/or remote UE identification.

As illustrated in FIG. 1 D, in some embodiments, as for scenario #2, the SRAP entity is absent, which causes that there is no entity in the remote terminal device 110 and the relay terminal device 120 which can provide bearer mapping and/or remote UE identification.

In some embodiments, in case of the standardized indirect path, the network device 130 may configure the indirect path for the remote terminal device 110 and the relay terminal device120, such as, by using RRC reconfiguration signalling. Specifically, the RRC reconfiguration message may indicate at least one of the following parameters to the remote terminal device 110: an RB, an RLC channel, a sidelink RLC channel, a relay UE for the indirect path and a mapping information of RB and RLC channel (such as, egress RLC channel on PC5/UE-UE hop for the remote terminal device 110) .

In addition, the RRC reconfiguration message also may indicate parameters to be used by the relay terminal device 120, such that the relay terminal device 120 may map the RB (s) of the remote terminal device 110 to related RLC channel (s) and relay the packets (for example, PDCP PDUs or SRAP PDUs) between the remote terminal device 110 and the network device 130. In other words, the relay terminal device 120 may map the PC5 (relay) RLC channels to the Uu (relay) RLC channels, or vice versa, with the indicated parameters to relay the packets between the remote terminal device 110 and the network device 130. One example of the parameters may be a local ID of the remote terminal device 110 (i.e., remote terminal device) . Another example of the parameters may be a mapping information of RB and RLC channel (such as, both egress RLC channel on PC5/UE-UE hop and egress RLC channel on Uu hop for the relay terminal device 120) . A further example of the parameters may be a type of an Uu RB and an ID of Uu RB. As one example, IEs of sl-SRAP-config, sl-MappingToAddMod and sl-RemoteUE-RB-Identity may be used for indicating the parameters.

Reference is made to FIG. 2, which illustrates an example structure 200 for SRAP SDU. As illustrated in FIG. 2, the SRAP SDU may include the following fields:

UE ID: This field carries local IF of U2N Remote UE (i.e., the remote terminal device 110) . Length of this field may be 8 bits.

BEARER ID: This field carries Uu radio bearer identity for U2N Remote UE. Length of this field may be 5 bits.

Data: This field carries the SRAP SDU (i.e. PDCP PDU or RRC PDU) . Length of this field may be Variable.

D/C: This field indicates whether the corresponding SRAP PDU is an SRAP data PDU or an SRAP Control PDU. For example, value ‘0’ is used for indicating SRAP data PDU and value ‘1’ is used for indicating SRAP control PDU.

It should be appreciated that the numbers and types of devices/entities in FIGS. 1A to 1D are given for the purpose of illustration without suggesting any limitations to the present disclosure. The communication environment 100 may include any suitable number of network devices and/or terminal devices adapted for implementing implementations of the present disclosure. Further, the communication environment 100 may include any other devices than the network devices and the terminal devices, such as a core network element, but they are omitted here so as to avoid obscuring the present invention.

In some embodiments, the terminal device 110, 120 and the network device 130 may communicate with each other via a channel such as a wireless communication channel on an air interface (e.g., Uu interface) . The wireless communication channel may comprise a physical uplink control channel (PUCCH) , a physical uplink shared channel (PUSCH) , a physical random-access channel (PRACH) , a physical downlink control channel (PDCCH) , a physical downlink shared channel (PDSCH) and a physical broadcast channel (PBCH) . Of course, any other suitable channels are also feasible.

The communications in the communication network 100 may conform to any suitable standards including, but not limited to, Global System for Mobile Communications (GSM) , Long Term Evolution (LTE) , LTE-Evolution, LTE-Advanced (LTE-A) , New Radio (NR) , Wideband Code Division Multiple Access (WCDMA) , Code Division Multiple Access (CDMA) , GSM EDGE Radio Access Network (GERAN) , Machine Type Communication (MTC) and the like. The embodiments of the present disclosure may be performed according to any generation communication protocols either currently known or to be developed in the future. Examples of the communication protocols include, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) communication protocols, 5.5G, 5G-Advanced networks, or the sixth generation (6G) networks.

EXAMPLE PROCESSES

It should be understood that although feature (s) /operation (s) are discussed in specific example embodiments separately, unless clearly indicated to the contrary, these feature (s) /operation (s) described in different example embodiments may be used in any suitable combination.

Further, it is to be understood that the operations among the remote terminal device 110, the relay terminal device 120 and the network device 130 should be coordinated. In other words, the remote terminal device 110, the relay terminal device 120 and the network device 130 should have common understanding about configuration, parameter, operations and so on. Such common understanding may be implemented by any suitable interactions among the related devices or applying the same rule/policy among the related devices. In the following, although some operations are described from a perspective of the remote terminal device 110/the relay terminal device 120/the network device 130, it is to be understood that the corresponding operations should be performed by the coordinated device. Merely for brevity, some of the same or similar contents are omitted here.

Principle and implementations of the present disclosure will be described in detail below with reference to FIGS. 3 to 4. For the purpose of discussion, FIGS. 3 and 4 will be described with reference to FIGS. 1Ato 1D.

Example Processes for configuring RB (s) of the remote terminal device for scenario #2

As discussed above, the indirect path comprises a first hop between the remote terminal device 110 and the relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130. According to the current agreements, as for scenarios #2, the first hop is a non-PC5 hop. Thus, the lower communication entity at the remote terminal device 110/the relay terminal device 120 is multifarious, such as, Bluetooth, WiFi or even a wired communication.

According to the following example embodiments, both the remote terminal device 110 and the relay terminal device 120 may understand which RB (s) of the remote terminal device 110 (and/or which Uu RLC channel (s) between the relay terminal device 120 and the network device 130) is associated with the indirect path.

Principle and implementations of the present disclosure will be described in detail below with reference to FIG. 3, which show a signaling chart illustrating process 300 of communication according to some example embodiments of the present disclosure. For the purpose of discussion, the process 300 will be described with reference to FIGS. 1A to 1D. As illustrated in FIG. 3, the process 300 may involve the remote terminal device 110, the relay terminal device 120 and the network device 130.

In the specific example embodiment, the remote terminal device 110 capable of communicating with the network device 130 via an indirect path, where the first hop being a non-PC5 connection.

The operations of the remote terminal device 110 will be described first. As illustrated in FIG. 3, the remote terminal device 110 determines 320-1 at least one RB of the remote terminal device 110, where the at least one RB is associated with the indirect path. After determining the at least one RB, ifthere is pending data from the above at least one RB, the remote terminal device will forward the pending data to the lower layer (i.e., non-PC5 layer of the remote terminal device 110) . As a result, the remote terminal device 110 perform 330-1 and 330-2 a communication with the network device 130 via the indirect path.

In some embodiments, the number of the at least one RB is smaller than or equal to a maximum number (such as, the number of allowed lower layer channels) .

Additionally, the maximum number is a default value. For example, the maximum number is pre-defined by the communication organization (such as 3GPP) , or pre-defined by the network operator or service provider. In this way, no additional signaling exchanging between the terminal device and the network device 130 is needed.

Alternatively, in some embodiments, the maximum number may be dynamically or semi-statically configured. For example, either the terminal device (either the remote terminal device 110 or the relay terminal device 120) or the network device 130 may determine the maximum number and then inform the maximum number to the other devices, via signallings SIB or RRC or PC5-Signalling (PC5-S) or PC5 RRC.

In some embodiments, the above at least one RB may be configured (statically, semi-statically, or dynamically) configured by the network device 130. As illustrated in FIG. 3, the network device 130 may transmit 310-1 at least one first configuration to the remote terminal device 110, where each of the first configuration is specific to a respective RB. In particular, the first configuration may indicate a mapping between the RB and the indirect path. In one specific embodiment, in addition to the identity of the RB, the first configuration further indicates one of the following:

an identity of the indirect path,

for example, path ID,

a path type of the indirect path,

for example, indirect of ENUMERATED [direct, indirect] ,

an identity of the relay terminal device 120 of the indirect path,

for example, UE ID, such as, temporary mobile subscriber identity (TMSI) , radio network temporary identity (RNTI) ; which may be a bit string with a bit-size of 8, 16, 24 or 32; That is, the bit-size may be a multiple of the number 8,

an identity of channel corresponding to the non-PC5 connection,

for example, a lower channel ID of the non-PC5 connection.

In some embodiments, the above first configuration may be comprised in IE of RadioBearerConfig (additionally, IE PDCP-Config of IE RadioBearerConfig) . That is, the mapping between the RB (s) and in indirect may be indicated by reusing an existing IE. Below is an example IE of data radio bearer (DRB) .

In the above example IE for DRB, the parameter of indirect-path-info is used to indicate the indirect path information. In this way, this DRB is configured for indirect transmission. Below is an example IE of signal radio bearer (SRB) .

In the above example IE for SRB, the parameter of indirect-path-info is used to indicate the indirect path information. In this way, this SRB is configured for indirect transmission.

Instead of reusing existing IE, a new IE may be used to indicate the mapping between the RB and the indirect path. Specifically, the remote terminal device may receive at least one second configuration that indicates the at least one RB, such as, per RB or per UE. In some embodiments, the second configuration may only comprise information about the RB ID (s) . Optionally, in some embodiments, the second configuration (s) also may comprise a lower channel ID of the non-PC5 connection.

Additionally, in case of the per RB configuration, the RB ID may be indicated in IE RadioBearerConfig. Below is an example IE.

In the above example IE, the parameter of Remote UE-RB-Identity is used to indicate the RB of the remote terminal device 110 for the remote terminal device 110, such that the terminal device 110 will understand which RB (s) is configured for relay transmission.

Alternatively, in case of the per UE, all the RBs may be indicated in a single IE (such as, a new-defined IE, which may be called as IndirectPath-ConfigDedicatedNR to distinguish the existing IE SL-ConfigDedicatedNR) . Below is another example IE.

Alternatively, in some embodiments, the at least one RB is pre-reserved for a relay transmission or a multi-path transmission. In one example embodiment, the at least one RB is pre-reserved by default configuration/definition. Alternatively, the at least one RB is pre-reserved by the network device 130. Ifso, the network device 130 may reserve the at least one RB first and then inform the reservation to the remote terminal device 110 via SIB or RRC. Then, once a reserved RB is configured to the remote terminal device 110, the remote terminal device 110 may determine that this RB is used for a relay transmission or a multi-path transmission, and thus the data/packets of this RB will be transmitted via the indirect path.

In the following, the operations of the relay terminal device 120 will be described. As illustrated in FIG. 3, the relay terminal device 120 determines 310-2 at least one channel between the relay terminal device 120 and the network device 130 (i.e., Uu RLC channel) , where the at least one channel is associated with at least one RB of a remote terminal device 110.

That is, the relay terminal device 120 understand the mapping of RB (s) and the Uu RLC channel (s) . In this event, after receiving data on the indirect path (i.e., the data of the related RB from the remote terminal device 110) , the relay terminal device 120 may forward this data to the network device 130. Accordingly, after receiving data from the indicated Uu RLC channel (s) , the relay terminal device 120 also may forward this data to the remote terminal device 110. As a result, the relay terminal device 120 may perform 330-1 and 330-2 the relay transmission with remote terminal device 120 and the network device 130.

In some embodiments, the number of the at least one channel or the number of the at least one RB is smaller than or equal to a maximum number (such as, the number of allowed lower layer channels) .

In some embodiments, the above mapping may be configured (statically, semi-statically, or dynamically) configured by the network device 130.

As illustrated in FIG. 3, the network device 130 may transmit 310-2 at least one third configuration to the rely terminal device 120.

In some embodiments, the third configuration may indicate at least one RB of the remote terminal device 110 associated with the indirect path. In other words, this configuration may indicate at least one RB of the remote terminal device 110 associated with one Uu (relay) RLC channel of the indirect path or the second hop of the indirect path. Additionally, the third configuration may be comprised in an existing IE Uu-RelayRLC-ChannelConfig. Below is an example IE of Uu-RelayRLC-ChannelConfig.

In the above example IE of Uu-RelayRLC-ChannelConfig, the parameter of Remote UE-RB-Identity is used to indicate the mapping between the RB and the Uu RLC channel, for example, the Uu (relay) RLC channel of the indirect path or the second hop of the indirect path.

Instead of reusing existing IE, a new IE may be used to indicating the mapping between the RB and the Uu RLC channel. Specifically, the relay terminal device 120 may receive at least one second configuration that indicates the at least one RB of the remote terminal device 110 associated with the indirect path, and the at least one identity of the at least one channel. Additionally, the identity of the channel may be an identity of a logical channel, an identity of a RLC channel or any suitable parameter.

Additionally, the above mapping information may be comprised in a single newly-defined IE or a plurality of newly-defined IEs.

Below is an example IE.

In the above IE, more than one RB may be indicated, which reduced the signalling overhead accordingly.

As discussed above, as for scenario #2, the SRAP layer is absent at the remote terminal device 110 and the relay terminal device 120. In this event, the layer used for determining the above mapping is needed to be further stipulated. In some embodiments, PDCP layer, a virtual PDCP layer, a virtual adaptation layer, or a radio link control (RLC) layer may be defined to determine the above mapping. For example, the PDCP layer or the RLC layer at the remote terminal device 110 may determine the above mapping. As another example, the virtual PDCP layer, or the virtual adaptation layer, or the RLC layer at the relay terminal device 120 may determine the above mapping.

According to the present discourse, in case of scenario #2, the network device 130 supports to configure one or more remote terminal devices for relay terminal device 120. Specifically, the relay terminal device 120 may receive a fourth configuration from the network device 130, where the fourth configuration may indicate a plurality of identities of a plurality of respective remote terminal device 110.

Moreover, each of the plurality of identities is used for identifying a respective remote terminal device 110 when performing a relay transmission with the network device 130.

Examples of the identity of the remote terminal device 110, include but not limited to, a pre-configured ID for the remote terminal device 110 rather than a Layer 2 destination ID, or a Non-3GPP lower layer ID (request by upper layer, or reported by lower layer) , or an ID assigned by the gNB (for example, the RNTI, such as C-RNTI) .

The identity (ies) of the remote terminal device may be indicated by reusing an existing IE or a newly-defined IE. Below is an example IE, where more than one identity of more than one remote terminal device is indicated.

Below is another example IE, where the configuration for only one remote terminal device 110 is indicated. In the above IE, both the identity (ies) of the remote terminal device (s) and the bearer mapping are indicated.

Additionally, the identity (ies) of the remote terminal device (s) may be not indicated in some certain scenarios. In one example, the relationship between the remote terminal device 110 and the relay terminal device 120 (e.g., 1 to 1 mapping) may be pre-defined or pre-configured by the network or by the vender of these devices, and thus the IE may not indicate the identity of the remote terminal device 110. In another example, the identity (ies) of the remote terminal device (s) is indicated by another IE different from the IE indicating the bearer mapping. Below are further examples of IE.

According to the above example embodiments, even the first hop between the remote terminal device 11 and the relay terminal device 120 is non-PC5 connection and even the SRAP layer is absent at the remote terminal device 110, the relay terminal device 120 and the network device 130, both the remote terminal device 110 and the relay terminal device 120 may understand which RB (s) of the remote terminal device 110 (and/or which Uu RLC channel between the relay terminal device 120 and the network device 130) is associated with the indirect path and the mapping between the RB (s) of the remote terminal device 110 and the Uu RLC channel (s) of the indirect path.

Example Processes for configuring a multi-path transmission

According to below example embodiments, a multi-path transmission is supported.

Principle and implementations of the present disclosure will be described in detail below with reference to FIG. 4, which show a signaling chart illustrating process 400 of communication according to some example embodiments of the present disclosure. For the purpose of discussion, the process 400 will be described with reference to FIGS. lA to ID. As illustrated in FIG. 4, the process 400 may involve the remote terminal device 110, the relay terminal device 120 and the network device 130.

In operation, the remote terminal device 110 associates an RB of the remote terminal device 110 with both an indirect path and a direct path. By establishing this association, the terminal device 110 may perform 440-1, 440-2 and 450 a multi-path transmission of the RB with the network device 130 accordingly.

In the present discourse, each RB may be configured with an identity which is unique with respect to the direct path and indirect path.

Merely for better understanding, some specific embodiments will be discussed as below. As for scenario #1, split bearer may be enabled by indicating the served RB for each PC5 RLC channel of the remote terminal device 110.

In one example, at least one RB may be configured for the indirect path. The network device 130 may send an indication together with the configuration of PC5 RLC channel, which may indicate at least one of RB ID and/or RB type. Below is an example IE for configuring the split bearer.

Alternatively, a SRAP configuration may be used to link the PC5 RLC channel to one RB.

In some embodiments, if one Uu RLC channel is associated to a specific RB, and one PC5 RLC channel is associated to the same RB by one of the above mentioned methods, the remote terminal device can determine that this RB is configured as split bearer (for multipath relaying) .

As for scenario #2, split bearer may be enabled by mapping RB (s) to the indirect path via an existing or newly-defined IE for the remote terminal device as discussed above.

In some embodiments, if one Uu RLC channel is associated to a specific RB, and the same RB is associated to an indirect path, the remote terminal device 110 may determine that this RB is configured as split bearer (i.e., multipath relaying) .

According to some embodiments of the present disclosure, the configuration may be further defined, especially for the serving cell of direct link and the serving cell of the indirect path belong to one same cell group, or the serving cell of direct link and the serving cell of the indirect path is the same cell.

In some embodiments, in case of multipath relaying, as for the DRB (or SRB) , the DRB(or SRB) identity is unique within the scope of the UE, e.g., a direct path DRB (or SRB) cannot use the same value as a split DRB (or SRB) , and a direct path DRB (or SRB) cannot use the same value as an indirect path DRB (or SRB) .

In some embodiments, as for a split DRB (or SRB) , the same identity is used for the indirect path and the direct path of the configuration.

In this way, the multi-path transmission is enabled in both scenario #1 and scenario #2.

Example Processes for determining transmitting path

In the following text, how to flexibly switch among the indirect and the direct will be discussed in detail.

Still refer to FIG. 4. In operation, the terminal device 110 determines 430 a total pending data volume for an RB of the remote terminal device 110, where the RB is associated with the indirect path and the direct path. In other words, this RB is configured as a split bearer (for multipath relaying) , by above mentioned methods or other methods. The following examples are not limited with regard to how to configure the split bearer.

In some embodiments, the terminal device 110 performs a communication with the network device 130 via one of the indirect and direct path or both of the indirect and direct paths based on a comparison result between the total pending data volume and data volume threshold.

In some embodiments, the first hop is a PC5 connection, and the total pending data volume is a sum of at least one of the following:

pending data volume of packet data convergence protocol (PDCP) ,

pending data volume of Uu radio link control (RLC) , or

pending data volume of PC5 RLC, or

pending data volume of sidelink relay adaptation protocol (SRAP) .

In some embodiments, the first hop is a non-PC5 connection, and the total pending data volume is an addition of at least one of the following:

pending data volume of packet data convergence protocol (PDCP) ,

pending data volume of radio link control (RLC) over the direct path, or

pending data volume over the indirect path.

In some embodiments, ifthe total pending data volume is equal to or larger than (or larger than) the data volume threshold, performing the communication with the network device 130 via either of the direct path and the indirect path (that is, both of the direct path and the indirect path are available or allowed for data transmission) . Alternatively, if the total pending data volume is smaller than the data volume threshold, performing the communication with the network device 130 via one of the direct path and the indirect path.

In some embodiments, the data volume threshold is a default value. As one example, the data volume threshold is pre-defined by the communication organization (such as 3GPP) , or pre-defmed by the network operator or service provider. In this way, no additional signaling exchanging between the terminal device and the network device 210 is needed.

Alternatively, in some embodiments, the data volume threshold may be dynamically or semi-statically configured. For example, either the terminal device or the network device 130 may determine the data volume threshold and then inform the data volume threshold to the other device (s) .

In some embodiments, the data volume threshold may be comprised in a newly-introduced IE/field or an existing IE (for example, IE PDCP-Config, per RB/PDCP) . As for scenarios #1 and #2, this new IE/field is introduced to configure the threshold for data split for sidelink relay multipath.

In some embodiments this new IE/field configures UL data transmission for sidelink relay multipath/when at least one Uu RLC entity and one PC5 RLC entity are associated with the PDCP entity. Optionally, this field may also provide a flag for duplication ofmultipath sidelink relay. Below is an example of IE for configuring the data volume threshold.

slmp-DataSplitThreshold SLMP-DataSplitThreshold OPTIONAL, --Cond SplitBearer for SLMultipathRelaying.

Below is another example ofIE in PDCP-config.

In the above IE, the existing IE PDCP-config is used for indicating the data volume threshold by introducing new field slmp-DataSplitThreshold. Additionally, the existing IE moreThanOneRLC may also include the legacy field ul-DataSplitThreshold. However, the terminal device capable of the new features may ignore the field ul-DataSplitThreshold.

Additionally, in some embodiments, one of the direct path and the indirect path is configured to be a primary/anchor path, optionally the other one of the direct path and the indirect path is configured to be a secondary path.

Additionally, the primary may be configured per RB. In this event, different RBs may be configured with different primary paths. Alternatively or in addition, one of the RLC channels/lower layer channels of the direct path and the indirect path is configured to be a primary/anchor RLC channel/lower layer channel. In this event, the secondary path is selected to be activated only when the total pending data amount is equal to or larger than (or larger than) the data volume threshold or other condition is met. As another example, the secondary path is selected to be activated only when the total pending data amount is larger than or equal to (or larger than) the data volume threshold or other condition is met.

Additionally, in some embodiments, the primary path is configured by the network device 130. Specifically, the remote terminal device 110 receives a fifth configuration indicating the primary path.

In some embodiments, the primary path and the data volume threshold may be comprised in a newly-introduced IE/field or an existing IE (for example, IE PDCP-Config) . Further, in some embodiments, either Uu RLC entity of direct path or PC5 RLC entity of indirect path as primary RLC entity may be configured as primary entity. Optionally, this field may also provide a threshold for data split of multipath sidelink relay. Alternatively, the threshold for data split of multipath sidelink relay may be configured in another field/IE. Optionally, this field may also provide a flag for PDCP duplication ofmultipath sidelink relay. Therefore, above mentioned embodiments for data split of multipath sidelink relay is enabled when the flag for PDCP duplication is absence/not configured or the flag is set to false. In other words, ifthe PDCP duplicating ofmultipath sidelink relay is activated, such as the flag is set to tree, the data split will not be activated. Below is an example IE for configuring the primary path and the data volume threshold. Alternatively, or in addition, the RB ID may be indicated in the newly-introduced IE/field to link the configuration of primary path to an PDCP entity of this RB.

In the above IE, a new IE is introduced. Below is another example of a new IE.

As indicated in the above IE, new parameters/fields, such as, slmp-RlcChannel, Uu-RlcChannel and PC5-RlcChannel are introduced. In one example, the remote terminal device 110 may determine that the indirect path is set as the primary path if PC5-RlcChannel is configured. In another example, the remote terminal device 110 may determine that the direct path is set as the primary path if Uu-RlcChannel is configured. These new parameters/fields are necessary especially when the serving cell of direct link and the serving cell of the indirect path belong to one same cell group, or the serving cell of direct link and the serving cell of the indirect path is the same cell. That is, in conventional DC scenario, different paths may be better distinguished by different cell groups. However, in intra-gNB scenario, the indirect path and the direct path may be configured with/served by the same cell group ID or even same cell ID, and thus conventional solution does not suitable for these scenarios. By using the above new parameters/fields, even the serving cell of direct link and the serving cell of the indirect path belong to one same cell group, or the serving cell of direct link and the serving cell of the indirect path is the same cell, the primary path also may be configured.

Instead of introducing a new IE, the primary path also may be indicated by reusing the existing IE (for example, moreThanOneRLC) as below by introducing new parameters /fields.

As indicated in the above IE, new parameters/fields, such as, slmp-RlcChannel, Uu-RlcChannel and PCS-RlcChannel are introduced. In one example, the remote terminal device 110 may determine that the indirect path is set as the primary path ifPC5-RlcChannel is configured. In another example, the remote terminal device 110 may determine that the direct path is set as the primary path if Uu-RlcChannel is configured. These new parameters/fields are necessary especially when the serving cell of direct link and the serving cell of the indirect path belong to one same cell group, or the serving cell of direct link and the serving cell of the indirect path is the same cell. That is, in conventional DC scenario, different paths may be better distinguished by different cell groups. However, in intra-gNB scenario, the indirect path and the direct path may be configured with/served by the same cell group ID or even same cell ID, and thus conventional solution does not suitable for these scenarios. By using the above new parameters/fields, even the serving cell of direct link and the serving cell of the indirect path belong to one same cell group, or the serving cell of direct link and the serving cell of the indirect path is the same cell, the primary path also may be configured.

Alternatively, or in addition, in some embodiments, the existing IE (for example, moreThanOneRLC) may be reused (and without introducing new parameters/fields) . And LCIDs may be divided into at last two groups, one group for the indirect path and another for the direct path. In other words, some LCIDs may be reserved for the indirect path or the direct path. In one example, the remote terminal device 110 may determine that the indirect path is set as the primary path if the LCID reserved for the indirect path is indicated in the existing IE or ifthe LCID indicated in the existing IE belonging to the group for the indirect path, or vice versa.

Alternatively, or in addition, in some embodiments, the terminal device 110 performs a communication with the network device 130 via one of the indirect and direct path or both of the indirect and direct paths based on information about channel usage state of the direct path and/or the indirect path.

In one specific embodiments, the traffic load/ (non-) PC5 congestion may be take into consideration. In this event, ifthe traffic load/ (non-) PC5 congestion is lower than (or lower than or equal to) a first pre-defined threshold, PDCP PDU may be submitted to indirect path/PC5 RLC channel. Alternatively, if the traffic load/ (non-) PC5 congestion is lower than (or lower than or equal to) the first pre-defined threshold, the PDCP PDU may be submitted to either RLC entity (i.e., Uu RLC entity or PC5 RLC entity) or either the direct path or the indirect path.

In some embodiments, metric for traffic load of sidelink/ (non-) PC5 includes: sidelink channel busy ratio (SL CBR) /CBR and channel occupancy ratio (CR) . Additionally, if the CBR/CR of at least one sub-channel is lower than (or lower than or equal to) the first pre-defined threshold, PDCP PDU can be submitted to the indirect path/PC5 RLC channel/non-PC5 channel. Alternatively, ifthe traffic load/ (non-) PC5 congestion is lower than (or lower than or equal to) the first pre-defined threshold, the PDCP PDU may be submitted to either RLC entity (i.e., Uu RLC entity or PC5 RLC entity) or either the direct path or the indirect path.

In some embodiments, the first pre-defined threshold may be configured in a newly- defined IE or in an existing IE (such as, IE SidelinkRelayMultipath) .

In some embodiments, the traffic load/ (non-) PC5 congestion may be used separately from the data volume threshold. In case of scenario #1, taking the traffic load as one example, if the traffic load is larger than or equal to (or larger than) the first pre-defined threshold, submit the data (i.e. PDCP PDU) to either RLC entity (i.e. Uu RLC entity or PC5 RLC entity) , else, submit the data (i.e. PDCP PDU) via the primary path, e.g., direct path or indirect path.

Alternatively, in case of scenario #2, taking the traffic load as one example, if the traffic load is larger than or equal to (or larger than) the first pre-defined threshold, submit the data (i.e. PDCP PDU) to either the Uu RLC entity or non-PC5 entity) , else, submit the data (i.e. PDCP PDU) via the primary path, e.g., direct path or indirect path.

In some embodiments, the traffic load/ (non-) PC5 congestion may be used jointly with the data volume threshold. In case of scenario #1, taking the traffic load as one example, ifthe total amount of data volume is equal to or larger than (or larger than) the data volume threshold and the traffic load is larger than or equal to (or larger than) the first pre-defined threshold, submit the data (i.e. PDCP PDU) to either RLC entity (i.e. Uu RLC entity or PC5 RLC entity) , else, submit the data (i.e. PDCP PDU) via the primary path, e.g., direct path or indirect path.

In case of scenario #2, taking the traffic load as one example, ifthe total amount of data volume is equal to or larger than (or larger than) the data volume threshold and the traffic load is larger than or equal to (or larger than) the first pre-defined threshold, submit the data (i.e. PDCP PDU) to either the Uu RLC entity or non-PC5 entity) , else, submit the data (i.e. PDCP PDU) via the primary path, e.g., direct path or indirect path.

Alternatively, or in addition, in some embodiments, the terminal device 110 performs a communication with the network device 130 via one of the indirect and direct path or both of the indirect and direct paths based on information about transmission capability of the direct path and/or the indirect path.

Especially for scenario #2, there are different types of non-3GPP lower layer (e.g. wired, WiFi, Bluetooth or other wireless type) which may have different capabilities for data transmission. Thus, their transmission capabilities are key factors when selecting the transmitting path.

In some embodiments, the transmission capability may be used jointly with the data volume threshold. In some embodiments, the percentage of total amount of data volume for data submitted via non-3GPP technology. As for this specific embodiment, specific percentage (x%) corresponding to the specific type of lower layer is selected. Then, if the total amount of data volume is equal to or larger than (or larger than) the data volume threshold, submit the data (i.e. PDCP PDU) to either entity (i.e. Uu RLC entity or non-3GPP lower layer ) and the amount of data volume submitted to the non-3GPP lower layer will not exceed x%*the total amount of data volume, else, submit the data (i.e. PDCP PDU) to the primary lower layer entity (i.e. Uu RLC entity or non-3GPP lower layer ) /primary path (i.e. direct path or indirect path) .

In some embodiments, different percentages may be configured flexible via RRC/system information/short message. In one example, a first percentages x₁%is configured for the wired, a second percentages x₂%is configured for wireless.

In another example, a first percentages x₁%is configured for the WiFi, a second percentages x₂%is configured for Bluetooth, a third percentages x₃%is configured for the Zigbee and so on.

In a further example, the remote terminal device or the relay terminal device reports the transmission capability of lower layer or the type of lower layer to the network device 130, and the network device 130 configures only one percentage for data split to the remote terminal device 110.

In another example, different the data volume thresholds are defined for different communication types. As for this specific embodiment, specific data volume threshold corresponding to the specific type of lower layer is selected. For example, the first data volume threshold is corresponding to the specific type of lower layer (such as, wired, Bluetooth, WiFi and so on) .

In one example, a first data volume threshold is configured for the wired, a second the data volume threshold is configured for wireless.

In another example, a first the data volume threshold is configured for the WiFi, a second the data volume threshold is configured for Bluetooth, a third the data volume threshold is configured for the Zigbee and so on.

In this event, ifthe total amount of data volume is equal to or larger than (or larger than) the first data volume threshold, submit the data (i.e. PDCP PDU) to either entity (i.e. Uu RLC entity or non-3GPP lower layer) , else submit the data (i.e. PDCP PDU) to the primary lower layer entity (i.e. Uu RLC entity or non-3GPP lower layer) /primary path (i.e. direct path or indirect path) .

In another example, the remote terminal device 110 or relay terminal device 120 reports the capability of lower layer or the type of lower layer to the network device 130, and the network device 130 configures a specific data volume threshold for data split to the remote terminal device 110.

Merely for better understanding, some specific example embodiments are described as below.

Example processes for scenario #1 are discussed first. In scenario #1, the data may be split to at least one Uu RLC channel and one PC5 RLC channel. As the general role, the remote terminal device 110 compares the total date volume of both Uu RLC channel and PC5 RLC channel with the data volume threshold, and selects the transmitting path according to the comparison result. In some embodiments, the data volume threshold is a newly-introduced threshold. Alternatively, ul-DataSplitThreshold may be reused as the data volume threshold.

As one specific embodiment, the remote terminal device 110 compares the total amount of PDCP data volume and RLC data volume (include Uu RLC data volume and PC5 RLC data volume, and may also include SRAP data volume) pending for initial transmission in the RLC entity of the direct path and the (split/PC5) RLC entity of indirect path with the data volume threshold.

In some embodiments, when selecting the transmitting path, both the data volume threshold and the path priority (primary path or secondary path, the primary path corresponding to an anchor RLC entity) are considered. Specifically, if the total pending data volume is equal to or larger than (or larger than) the data volume threshold, performs the communication with the network device 130 via either of the direct path and the indirect path (i.e., submit the data (i.e. PDCP PDU) to either RLC entity (i.e. Uu RLC entity or PC5 RLC entity) ) . Alternatively, ifthe total pending data volume is smaller than the data volume threshold, performs the communication with the network device 130 via the primary path/anchor RLC entity.

Alternatively, when selecting the transmitting path, only the data volume threshold is considered. Specifically, if the total pending data volume is equal to or larger than (or larger than) the data volume threshold, performs the communication with the network device via either of the direct path and the indirect path (i.e., submit the data (i.e. PDCP PDU) to either RLC entity (i.e. Uu RLC entity or PC5 RLC entity) ) . Alternatively, if the total pending data volume is smaller than the data volume threshold, performs the communication with the network device 130 via a pre-defined path (indirect path or direct path) , i.e., submit the data (i.e. PDCP PDU) via the default path/pre-defined path, e.g., direct path or indirect path.

Alternatively, in some embodiments, ifthe total amount of data volume is below the data volume threshold, submit the data (i.e. PDCP PDU) via the default path/pre-defined path, e.g., direct path or indirect path, else, submit the data (i.e. PDCP PDU) to either RLC entity (i.e. Uu RLC entity or PC5 RLC entity) .

Example processes for scenario #2 are discussed as below.

In some embodiments, the remote terminal device 110 compares date volume of Uu RLC channel with the data volume threshold to select transmitting path in scenario #2, where the data is split to at least one Uu RLC channel and one non-3GPP lower layer.

In some embodiments, the data volume threshold may be a newly-defined threshold. Alternatively, ul-DataSplitThreshold may be reused as the data volume threshold.

In some embodiments, the total pending amount of data volume is determined based on Uu RLC channel. Alternatively, the total pending amount of data volume is determined based on a sum ofUu RLC channel and non-3GPP lower layer ifthere is an interface to report or acquire data volume of non-3GPP lower layer.

In some embodiments, the remote terminal device 110 selects the transmitting path by comparing the total pending data volume and the data volume threshold. Further, the direct path may always be set as the primary path by implementation.

In one specific embodiment, the remote terminal device 110 compares the total amount of PDCP data volume and RLC data volume pending for initial transmission in the RLC entity of the direct path with the data volume threshold.

In one specific embodiment, the remote terminal device 110 compares the total amount of PDCP data volume and RLC data volume pending for initial transmission in the RLC entity of the direct path and the non-3GPP lower layer of indirect path with the data volume threshold if there is an interface to acquire the data volume of the non-3GPP lower layer. The data volume in the non-3GPP lower layer may be request by PDCP layer, or reported by the non-3GPP lower layer.

In one specific embodiment, the remote terminal device 110 compares the total amount of PDCP data volume and RLC data volume pending for initial transmission in the non-3GPP lower layer of indirect path with the data volume threshold if there is an interface to acquire the data volume of the non-3GPP lower layer. The data volume in the non-3GPP lower layer may be request by the PDCP layer, or reported by the non-3GPP lower layer.

In some embodiments, if the total amount of data volume is equal to or larger than (or larger than) the data volume threshold, submit the data (i.e. PDCP PDU) to either entity (i.e. Uu RLC entity or non-3GPP lower layer ) , else submit the data (i.e. PDCP PDU) to the primary lower layer entity (i.e. Uu RLC entity or non-3GPP lower layer) /primary path (i.e. direct path or indirect path) .

In some embodiments, the data volume threshold may be comprised in a newly-introduced IE/field or an existing IE (PDCP-Config) . As for scenario #1, this IE/field is introduced to configure the threshold for data split for sidelink relay multipath.

In some embodiments, a new field to configure either direct path or indirect path as primary path is introduced. Additionally, configure either Uu RLC entity of direct path or non-3GPP lower layer entity of indirect path as the primary lower layer entity.

In some embodiments, this field configures UL data transmission for multipath sidelink relay. Alternatively, this field configures UL data transmission when at least one Uu RLC entity and one PC5 RLC entity are associated with the PDCP entity/one RB.

In some embodiments, this field indicates the lower layer channel ID by RLC channel ID/LCH ID if direct path is set as the primary path, or a pre-defined value or specific/reserved RLC channel ID/LCH ID if the indirect path is set as the primary path (or it can be omitted) . Alternatively, the lower layer channel ID of the indirect path may be request by the PDCP layer, or report by the non-3GPP lower layer.

Optionally, in some embodiments, this field may also provide a threshold for data split of multipath sidelink relay. Alternatively, the threshold for data split of multipath sidelink relay may be configured in another field/IE.

Optionally, in some embodiments, this field may also provide a flag for duplication of multipath sidelink relay. Further, non-3GPP lower layer ID may be predefined, for example, default value.

Below is an example IE for configuring the primary path and the data volume threshold.

In some embodiments, in scenario #2, the remote terminal device 110 selects the transmitting path with considering the path priority (i.e., the primary path) . In some embodiments, the direct path may be configured as the pre-defined path.

In some embodiments, the remote terminal device 110 compares the total amount of PDCP data volume and RLC data volume (for example, only Uu RLC data volume) pending for initial transmission in the RLC entity of the direct path with the data volume threshold.

In some embodiments, the remote terminal device 110 compares the total amount of PDCP data volume and data volume pending for initial transmission in the RLC entity of the direct path and the non-3GPP lower layer of indirect path with the data volume threshold. The data volume in the non-3GPP lower layer may be request by PDCP layer, or reported by the non-3GPP lower layer.

In some embodiments, the remote terminal device 110 compares the total amount of PDCP data volume and data volume pending for initial transmission in the non-3GPP lower layer of indirect path with the data volume threshold. The data volume in the non-3GPP lower layer may be request by PDCP layer, or reported by the non-3GPP lower layer.

In some embodiments, if the total amount of data volume is equal to or larger than (or larger than) the data volume threshold, submit the data (i.e. PDCP PDU) to either lower layer entity (i.e. Uu RLC entity or non-3GPP lower layer) /either path (i.e. direct path or indirect path) , else submit the data (i.e. PDCP PDU) via the default path/pre-defined path, e.g., direct path or indirect path. In another embodiments, if the total amount of data volume is larger than or equal to (or larger than) the data volume threshold, submit the data (i.e. PDCP PDU) to either lower layer entity (i.e. Uu RLC entity or non-3GPP lower layer) /either path (i.e. direct path or indirect path) , else submit the data (i.e. PDCP PDU) via the default path/pre-defined path, e.g., direct path or indirect path.

In some embodiments, the data volume threshold may be comprised in a newly-introduced IE/field or an existing IE (for example, IE PDCP-Config, per RB/PDCP) . As for scenario #1, this IE/field is introduced to configure the threshold for data split for sidelink relay multipath.

In some embodiments this IE/field configures UL data transmission for sidelink relay multipath/when at least one Uu RLC entity and one PC5 RLC entity are associated with the PDCP entity. Optionally, this field may also provide a flag for duplication ofmultipath sidelink relay. Below is an example of IE for configuring the data volume threshold.

In some of the above discussed examples, primary path and/or threshold (including the data volume threshold, the first pre-defined threshold and so on) . It is noted that the above parameters may be configured jointly or separately. For example, the primary path may be configured separately from or jointly with the data volume threshold.

In this way, when more than one path is available, the remote terminal device 110 may select proper path.

EXAMPLE OF METHODS

FIG. 5 illustrates a flowchart of a communication method 500 implemented at a remote terminal device in accordance with some embodiments of the present disclosure. For the purpose of discussion, the method 500 will be described from the perspective of the remote terminal device in FIG. 1A.

At block 510, the remote terminal device 110 determines at least one radio bearer (RB) of the remote terminal device 110 capable of communicating with a network device 130 via an indirect path. The at least one RB are associated with the indirect path. The indirect path comprises a first hop between the remote terminal device 110 and a relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130. The first hop is a non-PC5 connection.

At block 520, the remote terminal device 110 performs a communication with the network device 130 via the indirect path based at least in part on the at least one RB.

In some example embodiments, the remote terminal device 110 may receive at least one first configuration from the network device 130. Each of the first configuration may be specific to a respective RB of the at least one RB and may indicate an identity of the RB and at least one of the following: an identity of the indirect path, a path type of the indirect path, an identity of the relay terminal device 120 of the indirect path, or an identity of channel corresponding to the non-PC5 connection. Moreover, the remote terminal device 110 may determine the at least one RB based on the at least one first configuration.

In some example embodiments, the remote terminal device 110 may receive, from the network device 130, a second configuration of a multi-path transmission indicating the at least one RB. Furthermore, the remote terminal device 110 may determine the at least one RB based on the second configuration.

In some example embodiments, the number of the at least one RB may be smaller than or equal to a maximum number.

In some example embodiments, the maximum number may be a default value or pre-configured by the network device 130.

In some example embodiments, the at least one RB may be pre-reserved for a relay transmission or a multi-path transmission.

In some example embodiments, an RB of the at least one RB may be further associated with a direct path between the remote terminal device 110 and the network device 130.

FIG. 6 illustrates a flowchart of a communication method 600 implemented at a relay terminal device 120 in accordance with some embodiments of the present disclosure. For the purpose of discussion, the method 600 will be described from the perspective of the relay terminal device 120 in FIG. lA.

At block 610, the relay terminal device 120 determines at least one channel between the relay terminal device 120 and the network device 130. The at least one channel is associated with at least one radio bearer (RB) of a remote terminal device 110. The remote terminal device 110 is capable of communicating with the network device 130 via an indirect path. The indirect path comprises a first hop between the remote terminal device 110 and the relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130. The first hop is a non-PC5 connection.

At block 620, the relay terminal device 120 performs a communication with the network device 130 and the remote terminal device 110 based at least in part on the at least one channel.

In some example embodiments, the relay terminal device 120 may receive a third configuration from the network device 130. The third configuration may indicate at least one of the following: at least one radio bearer (RB) of the remote terminal device 110 associated with the indirect path, or at least one identity of the at least one channel. Moreover, the relay terminal device 120 may determine the at least one channel based on the third configuration.

In some example embodiments, the identity of the channel may be one of the following: an identity of a logical channel, or an identity of a radio link control (RLC) channel.

In some example embodiments, the number of the at least one channel may be smaller than or equal to a maximum number.

In some example embodiments, maximum number may be a default value or pre-configured by the network device 130.

In some example embodiments, determining at least one channel may be performed by one of the following: a virtual packet data convergence protocol (PDCP) layer, a virtual adaptation layer, or a radio link control (RLC) layer.

In some example embodiments, the relay terminal device 120 may further receive a fourth configuration from the network device 130. The fourth configuration may indicate: a plurality of identities of a plurality of respective remote terminal device 1 10s comprising the remote terminal device 110. Each of the plurality of identities may be used for identifying a respective remote terminal device 110 when performing a relay transmission with the network device 130.

FIG. 7 illustrates a flowchart of a communication method 700 implemented at a remote terminal device 110 in accordance with some embodiments of the present disclosure. For the purpose of discussion, the method 700 will be described from the perspective of the remote terminal device 110 in FIG. 1A.

At block 710, the remote terminal device 110 determines total pending data volume for a radio bearer (RB) of the remote terminal device 110. The remote terminal device 110 is capable of communicating with a network device 130 via an indirect path and a direct path. The RB is associated with the indirect path and the direct path.

At block 720, the remote terminal device 110 performs a communication with the network device 130 via one of the indirect and direct path or both of the indirect and direct paths based on at least one of the following: a comparison result between the total pending data volume and data volume threshold, information about channel usage state of the direct path and/or the indirect path, information about transmission capability of the direct path and/or the indirect path.

In some example embodiments, the indirect path may comprise a first hop between the remote terminal device 110 and a relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130. The first hop may be a PC5 connection. Moreover, the total pending data volume may be a sum of at least one of the following: pending data volume of packet data convergence protocol (PDCP) , pending data volume of Uu radio link control (RLC) , or pending data volume of PC5 RLC, or pending data volume of sidelink relay adaptation protocol (SRAP) .

In some example embodiments, the indirect path may comprise a first hop between the remote terminal device 110 and a relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130. The first hop may be a non-PC5 connection. Furthermore, the total pending data volume may be an addition of at least one of the following: pending data volume of packet data convergence protocol (PDCP) , pending data volume of radio link control (RLC) over the direct path, or pending data volume over the indirect path.

In some example embodiments, the data volume threshold may be a default value or pre-configured by the network device 130.

In some example embodiments, at block 720, if the total pending data volume is equal to or larger than (or larger than) the data volume threshold, the remote terminal device 110 may perform the communication with the network device 130 via both of the direct path and the indirect path. If the total pending data volume is smaller than the data volume threshold, the remote terminal device 110 may perform the communication with the network device 130 via one of the direct path and the indirect path.

In some example embodiments, one of the direct path and the indirect path may be configured to be a primary path. Performing the communication with the network device 130 via one of the direct path or the indirect path may comprise: performing the communication with the network device 130 via the primary path.

In some example embodiments, the processor may be further configured to cause the relay terminal device 120 to: receive, from the network device 130, a fifth configuration indicating the primary path.

FIG. 8 illustrates a flowchart of a communication method 800 implemented at a remote terminal device 110 in accordance with some embodiments of the present disclosure. For the purpose of discussion, the method 800 will be described from the perspective of the remote terminal device 110 in FIG. 1A.

At block 810, the remote terminal device 110 associates a radio bearer (RB) of a plurality of RBs of the remote terminal device 110 with an indirect path and a direct path. The remote terminal device 110 is capable of communicating with a network device 130 via the indirect path and a direct path.

At block 820, the remote terminal device 110 performs a multi-path transmission of the RB with the network device 130 based on the association.

In some example embodiments, each of the plurality of RBs may be configured with an identity which is unique with respect to the direct path and indirect path.

FIG. 9 illustrates a flowchart of a communication method 900 implemented at a network device 130 in accordance with some embodiments of the present disclosure. For the purpose of discussion, the method 900 will be described from the perspective of the network device 130 in FIG. 1A.

At block 910, the network device 130 determines at least one radio bearer (RB) of a remote terminal device 110 capable of communicating with the network device 130 via an indirect path. The at least one RB is associated with the indirect path. The indirect path comprises a first hop between the remote terminal device 110 and a relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130. The first hop is a non-PC5 connection.

At block 920, the network device 130 indicates the at least one RB to the remote terminal device 110.

In some example embodiments, the at least one RB may be indicated to the remote terminal device 110 via at least one first configuration. Each of the first configuration may be specific to a respective RB of the at least one RB and may indicate an identity of the RB and at least one of the following: an identity of the indirect path, a path type of the indirect path, an identity of the relay terminal device 120 of the indirect path, or an identity of channel corresponding to the non-PC5 connection.

In some example embodiments, the at least one RB may be indicated to the remote terminal device 110 via a second configuration indicating the at least one RB.

FIG. 10 illustrates a flowchart of a communication method 1000 implemented at a network device 130 in accordance with some embodiments of the present disclosure. For the purpose of discussion, the method 1000 will be described from the perspective of the network device 130 in FIG. 1A.

At block 1010, the network device 130 determines at least one channel between the relay terminal device 120 and the network device 130. The at least one channel is associated with an indirect path. The indirect path comprises a first hop between a remote terminal device 110 and the relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130. The first hop is a non-PC5 connection. The remote terminal device 110 is capable of communicating with the network device 130 via the indirect path.

At block 1020, the network device 130 indicates the at least one channel to the relay terminal device 120.

In some example embodiments, the at least one channel may be indicated via at least one third configuration. Each of the third configuration may be specific to a channel of the at least one channel and may indicate an identity of the channel and at least one of the following: an identity of the indirect path, a path type of the indirect path, an identity of the relay terminal device 120 of the indirect path, or an identity of channel corresponding to the non-PC5 connection.

In some example embodiments, the at least one channel may be indicated via a third configuration indicating at least one of the following: at least one radio bearer of the remote terminal device 110 associated with the indirect path, or at least one identity of the at least one channel.

In some example embodiments, the network device 130 may transmit a fourth configuration to the relay terminal device 120. The fourth configuration may indicate: a plurality of identities of a plurality of respective remote terminal device 11 0s comprising the remote terminal device 110. Each of the plurality of identities may be used for identifying a respective remote terminal device 110 when performing a relay transmission with the network device 130.

FIG. 11 is a simplified block diagram of a device 1100 that is suitable for implementing embodiments of the present disclosure. The device 1100 can be considered as a further example implementation of any of the devices as shown in FIG. lA. Accordingly, the device 1100 can be implemented at or as at least a part of the remote terminal device 110, relay terminal device 120, or the network device 120.

As shown, the device 1100 includes a processor 1110, a memory 1120 coupled to the processor 1110, a suitable transmitter (TX) /receiver (RX) 1140 coupled to the processor 1110, and a communication interface coupled to the TX/RX 1140. The memory 1110 stores at least a part of a program 1130. The TX/RX 1140 is for bidirectional communications. The TX/RX 1140 has at least one antenna to facilitate communication, though in practice an Access Node mentioned in this application may have several ones. The communication interface may represent any interface that is necessary for communication with other network elements, such as X2/Xn interface for bidirectional communications between eNBs/gNBs, S 1/NG interface for communication between a Mobility Management Entity (MME) /Access and Mobility Management Function (AMF) /SGW/UPF and the eNB/gNB, Un interface for communication between the eNB/gNB and a relay node (RN) , or Uu interface for communication between the eNB/gNB and a terminal device.

The program 1130 is assumed to include program instructions that, when executed by the associated processor 1110, enable the device 1100 to operate in accordance with the embodiments of the present disclosure, as discussed herein with reference to FIGS. 1 to 10. The embodiments herein may be implemented by computer software executable by the processor 1110 of the device 1100, or by hardware, or by a combination of software and hardware. The processor 1110 may be configured to implement various embodiments of the present disclosure. Furthermore, a combination of the processor 1110 and memory 1120 may form processing means 1150 adapted to implement various embodiments of the present disclosure.

The memory 1120 may be of any type suitable to the local technical network and may be implemented using any suitable data storage technology, such as a non-transitory computer readable storage medium, semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, as non-limiting examples. While only one memory 1120 is shown in the device 1100, there may be several physically distinct memory modules in the device 1100. The processor 1110 may be of any type suitable to the local technical network, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1100 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.

According to embodiments of the present disclosure, a remote terminal device 110 comprising a circuitry is provided. The circuitry is configured to: determine, at least one radio bearer (RB) of the remote terminal device 110 capable of communicating with a network device 130 via an indirect path, the at least one RB being associated with the indirect path, the indirect path comprising a first hop between the remote terminal device 110 and a relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130, the first hop being a non-PC5 connection; and perform, based at least in part on the at least one RB, a communication with the network device 130 via the indirect path. According to embodiments of the present disclosure, the circuitry may be configured to perform any method implemented by the remote terminal device 110 as discussed above.

According to embodiments of the present disclosure, a relay terminal device 120 comprising a circuitry is provided. The circuitry is configured to: determine, at least one channel between the relay terminal device 120 and the network device 130, the at least one channel being associated with at least one radio bearer (RB) of a remote terminal device 110, the remote terminal device 110 capable of communicating with the network device 130 via an indirect path, the indirect path comprising a first hop between the remote terminal device 110 and the relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130, the first hop being a non-PC5 connection; and perform, based at least in part on the at least one channel, a communication with the network device 130 and the remote terminal device 110. According to embodiments of the present disclosure, the circuitry may be configured to perform any method implemented by the relay terminal device 120 as discussed above.

According to embodiments of the present disclosure, a remote terminal device 110 comprising a circuitry is provided. The circuitry is configured to: determine, total pending data volume for a radio bearer (RB) of the remote terminal device 110, the remote terminal device 110 capable of communicating with a network device 130 via an indirect path and a direct path, the RB being associated with the indirect path and the direct path; and perform a communication with the network device 130 via one of the indirect and direct path or both of the indirect and direct paths based on at least one of the following: a comparison result between the total pending data volume and data volume threshold, information about channel usage state of the direct path and/or the indirect path, information about transmission capability of the direct path and/or the indirect path. According to embodiments of the present disclosure, the circuitry may be configured to perform any method implemented by the remote terminal device 110 as discussed above.

According to embodiments of the present disclosure, a remote terminal device 110 comprising a circuitry is provided. The circuitry is configured to: associate, a radio bearer (RB) of a plurality of RBs of the remote terminal device 110 with an indirect path and a direct path, the remote terminal device 110 capable of communicating with a network device 130 via the indirect path and a direct path; and perform a multi-path transmission of the RB with the network device 130 based on the association. According to embodiments of the present disclosure, the circuitry may be configured to perform any method implemented by the remote terminal device 110 as discussed above.

According to embodiments of the present disclosure, a network device 130 comprising a circuitry is provided. The circuitry is configured to: determine, at least one radio bearer (RB) of a remote terminal device 110 capable of communicating with the network device 130 via an indirect path, the at least one RB being associated with the indirect path, the indirect path comprising a first hop between the remote terminal device 110 and a relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130, the first hop being a non-PC5 connection; and indicate the at least one RB to the remote terminal device 110. According to embodiments of the present disclosure, the circuitry may be configured to perform any method implemented by the network device 130 as discussed above.

According to embodiments of the present disclosure, a network device 130 comprising a circuitry is provided. The circuitry is configured to: determine, at least one channel between the relay terminal device 120 and the network device 130, the at least one channel being associated with an indirect path, the indirect path comprising a first hop between a remote terminal device 110 and the relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130, the first hop being a non-PC5 connection, the remote terminal device 110 capable of communicating with the network device 130 via the indirect path; and indicate the at least one channel to the relay terminal device 120. According to embodiments of the present disclosure, the circuitry may be configured to perform any method implemented by the network device 130 as discussed above.

The term “circuitry” used herein may refer to hardware circuits and/or combinations of hardware circuits and software. For example, the circuitry may be a combination of analog and/or digital hardware circuits with software/firmware. As a further example, the circuitry may be any portions of hardware processors with software including digital signal processor (s) , software, and memory (ies) that work together to cause an apparatus, such as a terminal device or a network device 130, to perform various functions. In a still further example, the circuitry may be hardware circuits and or processors, such as a microprocessor or a portion of a microprocessor, that requires software/firmware for operation, but the software may not be present when it is not needed for operation. As used herein, the term circuitry also covers an implementation of merely a hardware circuit or processor (s) or a portion of a hardware circuit or processor (s) and its (or their) accompanying software and/or firmware.

In summary, embodiments of the present disclosure provide the following aspects.

In an aspect, it is proposed a remote terminal device 110 comprising: a processor configured to cause the remote terminal device 110 to: determine, at least one radio bearer (RB) of the remote terminal device 110 capable of communicating with a network device 130 via an indirect path, the at least one RB being associated with the indirect path, the indirect path comprising a first hop between the remote terminal device 110 and a relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130, the first hop being a non-PC5 connection; and perform, based at least in part on the at least one RB, a communication with the network device 130 via the indirect path.

In some embodiments, determining the at least one RB comprises: receiving, from the network device 130, at least one first configuration, each of the first configuration being specific to a respective RB of the at least one RB and indicating an identity of the RB and at least one of the following: an identity of the indirect path, a path type of the indirect path, an identity of the relay terminal device 120 of the indirect path, or an identity of channel corresponding to the non-PC5 connection; and determining the at least one RB based on the at least one first configuration.

In some embodiments, the determining the at least one RB comprises: receiving, from the network device 130, a second configuration of a multi-path transmission indicating the at least one RB; and determining the at least one RB based on the second configuration.

In some embodiments, the number of the at least one RB is smaller than or equal to a maximum number.

In some embodiments, the maximum number is a default value or pre-configured by the network device 130.

In some embodiments, the at least one RB is pre-reserved for a relay transmission or a multi-path transmission.

In some embodiments, an RB of the at least one RB is further associated with a direct path between the remote terminal device 110 and the network device 130.

In an aspect, it is proposed a relay terminal device 120 comprising: a processor configured to cause the relay terminal device 120 to: determine, at least one channel between the relay terminal device 120 and the network device 130, the at least one channel being associated with at least one radio bearer (RB) of a remote terminal device 110, the remote terminal device 110 capable of communicating with the network device 130 via an indirect path, the indirect path comprising a first hop between the remote terminal device 110 and the relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130, the first hop being a non-PC5 connection; and perform, based at least in part on the at least one channel, a communication with the network device 130 and the remote terminal device 110.

In some embodiments, determining the at least one channel comprises: receiving, from the network device 130, a third configuration indicating at least one of the following: at least one radio bearer (RB) of the remote terminal device 110 associated with the indirect path, or at least one identity of the at least one channel, determining the at least one channel based on the third configuration.

In some embodiments, the identity of the channel is one of the following: an identity of a logical channel, or an identity of a radio link control (RLC) channel.

In some embodiments, the number of the at least one channel is smaller than or equal to a maximum number.

In some embodiments, maximum number is a default value or pre-configured by the network device 130.

In some embodiments, determining at least one channel is performed by one of the following: a virtual packet data convergence protocol (PDCP) layer, a virtual adaptation layer, or a radio link control (RLC) layer.

In some embodiments, the processor is further configured to cause the relay terminal device 120 to: receive, from the network device 130, a fourth configuration indicating: a plurality of identities of a plurality of respective remote terminal device 11 0s comprising the remote terminal device 110, each of the plurality of identities used for identifying a respective remote terminal device 110 when performing a relay transmission with the network device 130.

In an aspect, it is proposed a remote terminal device 110 comprising: a processor configured to cause the remote terminal device 110 to: determine, total pending data volume for a radio bearer (RB) of the remote terminal device 110, the remote terminal device 110 capable of communicating with a network device 130 via an indirect path and a direct path, the RB being associated with the indirect path and the direct path; and perform a communication with the network device 130 via one of the indirect and direct path or both of the indirect and direct paths based on at least one of the following: a comparison result between the total pending data volume and data volume threshold, information about channel usage state of the direct path and/or the indirect path, information about transmission capability of the direct path and/or the indirect path.

In some embodiments, the indirect path comprising a first hop between the remote terminal device 110 and a relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130, and the first hop is a PC5 connection, and the total pending data volume is a sum of at least one of the following: pending data volume of packet data convergence protocol (PDCP) , pending data volume of Uu radio link control (RLC) , or pending data volume of PC5 RLC, or pending data volume of sidelink relay adaptation protocol (SRAP) .

In some embodiments, the indirect path comprising a first hop between the remote terminal device 110 and a relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130, and the first hop is a non-PC5 connection, and the total pending data volume is an addition of at least one of the following: pending data volume of packet data convergence protocol (PDCP) , pending data volume of radio link control (RLC) over the direct path, or pending data volume over the indirect path.

In some embodiments, the data volume threshold is a default value or pre-configured by the network device 130.

In some embodiments, wherein performing the communication with the network device 130 comprises: if the total pending data volume is equal to or larger than (or larger than) the data volume threshold, performing the communication with the network device 130 via both of the direct path and the indirect path, or ifthe total pending data volume is smaller than the data volume threshold, performing the communication with the network device 130 via one of the direct path and the indirect path.

In some embodiments, one of the direct path and the indirect path is configured to be a primary path, and wherein performing the communication with the network device 130 via one of the direct path or the indirect path comprises: performing the communication with the network device 130 via the primary path.

In some embodiments, the processor is further configured to cause the relay terminal device 120 to: receive, from the network device 130, a fifth configuration indicating the primary path.

In an aspect, it is proposed a remote terminal device 110 comprising: a processor configured to cause the remote terminal device 110 to: associate, a radio bearer (RB) of a plurality of RBs of the remote terminal device 110 with an indirect path and a direct path, the remote terminal device 110 capable of communicating with a network device 130 via the indirect path and a direct path; and perform a multi-path transmission of the RB with the network device 130 based on the association.

In some embodiments, each of the plurality of RBs is configured with an identity which is unique with respect to the direct path and indirect path.

In an aspect, it is proposed a network device 130 comprising: a processor configured to cause the network device 130 to: determine, at least one radio bearer (RB) of a remote terminal device 110 capable of communicating with the network device 130 via an indirect path, the at least one RB being associated with the indirect path, the indirect path comprising a first hop between the remote terminal device 110 and a relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130, the first hop being a non-PC5 connection; and indicate the at least one RB to the remote terminal device 110.

In some embodiments, the at least one RB is indicated to the remote terminal device 110 via at least one first configuration, each of the first configuration being specific to a respective RB of the at least one RB and indicating an identity of the RB and at least one of the following: an identity of the indirect path, a path type of the indirect path, an identity of the relay terminal device 120 of the indirect path, or an identity of channel corresponding to the non-PC5 connection.

In some embodiments, the at least one RB is indicated to the remote terminal device 110 via a second configuration indicating the at least one RB.

In an aspect, it is proposed a network device 130 comprising: a processor configured to cause the network device 130 to: determine, at least one channel between the relay terminal device 120 and the network device 130, the at least one channel being associated with an indirect path, the indirect path comprising a first hop between a remote terminal device 110 and the relay terminal device 120 and a second hop between the relay terminal device 120 and the network device 130, the first hop being a non-PC5 connection, the remote terminal device 110 capable of communicating with the network device 130 via the indirect path; and indicate the at least one channel to the relay terminal device 120.

In some embodiments, the at least one channel is indicated via at least one third configuration, each of the third configuration being specific to a channel of the at least one channel and indicating an identity of the channel and at least one of the following: an identity of the indirect path, a path type of the indirect path, an identity of the relay terminal device 120 of the indirect path, or an identity of channel corresponding to the non-PC5 connection.

In some embodiments, the at least one channel is indicated via a third configuration indicating at least one of the following: at least one radio bearer of the remote terminal device 110 associated with the indirect path, or at least one identity of the at least one channel.

In some embodiments, the processor is further configured to cause the relay terminal device 120 to: transmit, to the relay terminal device 120, a fourth configuration indicating: a plurality of identities of a plurality of respective remote terminal device 11 0s comprising the remote terminal device 110, each of the plurality of identities used for identifying a respective remote terminal device 110 when performing a relay transmission with the network device 130.

In an aspect, a remote terminal device 110 comprises: at least one processor; and at least one memory coupled to the at least one processor and storing instructions thereon, the instructions, when executed by the at least one processor, causing the device to perform the method implemented by the remote terminal device 110 discussed above.

In an aspect, a relay terminal device 120 comprises: at least one processor; and at least one memory coupled to the at least one processor and storing instructions thereon, the instructions, when executed by the at least one processor, causing the device to perform the method implemented by the relay terminal device 120 discussed above.

In an aspect, a network device 130 comprises: at least one processor; and at least one memory coupled to the at least one processor and storing instructions thereon, the instructions, when executed by the at least one processor, causing the device to perform the method implemented by the network device 130 discussed above.

In an aspect, a computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to perform the method implemented by the remote terminal device 110 discussed above.

In an aspect, a computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to perform the method implemented by the relay terminal device 120 discussed above.

In an aspect, a computer readable medium having instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to perform the method implemented by the network device 130 discussed above.

In an aspect, a computer program comprising instructions, the instructions, when executed on at least one processor, causing the at least one processor to perform the method implemented by the remote terminal device 110 discussed above.

In an aspect, a computer program comprising instructions, the instructions, when executed on at least one processor, causing the at least one processor to perform the method implemented by the relay terminal device 120 discussed above.

In an aspect, a computer program comprising instructions, the instructions, when executed on at least one processor, causing the at least one processor to perform the method implemented by the network device 130 discussed above.

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 representation, it will be appreciated that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product 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 process or method as described above with reference to FIGS. 1 to 11. 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 apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

The above program code may be embodied on a machine readable medium, which may be any tangible medium that may contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine 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 language 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

A remote terminal device comprising:

a processor configured to cause the remote terminal device to:

determine, at least one radio bearer (RB) of the remote terminal device capable of communicating with a network device via an indirect path, the at least one RB being associated with the indirect path, the indirect path comprising a first hop between the remote terminal device and a relay terminal device and a second hop between the relay terminal device and the network device, the first hop being a non-PC5 connection; and

perform, based at least in part on the at least one RB, a communication with the network device via the indirect path.
The remote terminal device of claim 1, wherein determining the at least one RB comprises:

receiving, from the network device, at least one first configuration, each of the first configuration being specific to a respective RB of the at least one RB and indicating an identity of the RB and at least one of the following:

an identity of the indirect path,

a path type of the indirect path,

an identity of the relay terminal device of the indirect path, or

an identity of channel corresponding to the non-PC5 connection; and

determining the at least one RB based on the at least one first configuration.
The remote terminal device of claim 1, wherein the determining the at least one RB comprises:

receiving, from the network device, a second configuration of a multi-path transmission indicating the at least one RB; and

determining the at least one RB based on the second configuration.
The remote terminal device of claim 1, wherein the number of the at least one RB is smaller than or equal to a maximum number.
The remote terminal device of claim 1, wherein the at least one RB is pre-reserved for a relay transmission or a multi-path transmission.
The remote terminal device of claim 1, wherein an RB of the at least one RB is further associated with a direct path between the remote terminal device and the network device.
A relay terminal device comprising:

a processor configured to cause the relay terminal device to:

determine, at least one channel between the relay terminal device and the network device, the at least one channel being associated with at least one radio bearer (RB) of a remote terminal device, the remote terminal device capable of communicating with the network device via an indirect path, the indirect path comprising a first hop between the remote terminal device and the relay terminal device and a second hop between the relay terminal device and the network device, the first hop being a non-PC5 connection; and

perform, based at least in part on the at least one channel, a communication with the network device and the remote terminal device.
The relay terminal device of claim 7, wherein determining the at least one channel comprises:

receiving, from the network device, a third configuration indicating at least one of the following:

at least one radio bearer (RB) of the remote terminal device associated with the indirect path, or

at least one identity of the at least one channel.

determining the at least one channel based on the third configuration.
The relay terminal device of claim 8, wherein the identity of the channel is one of the following:

an identity of a logical channel, or

an identity of a radio link control (RLC) channel.
The relay terminal device of claim 7, wherein the number of the at least one channel or the number of the at least one RB is smaller than or equal to a maximum number.
The relay terminal device of claim 7, wherein determining at least one channel is performed by one of the following:

a virtual packet data convergence protocol (PDCP) layer,

a virtual adaptation layer, or

a radio link control (RLC) layer.
The relay terminal device of claim 7, wherein the processor is further configured to cause the relay terminal device to:

receive, from the network device, a fourth configuration indicating:

a plurality of identities of a plurality of respective remote terminal devices comprising the remote terminal device, each of the plurality of identities used for identifying a respective remote terminal device when performing a relay transmission with the network device.
A remote terminal device comprising:

a processor configured to cause the remote terminal device to:

determine, total pending data volume for a radio bearer (RB) of the remote terminal device, the remote terminal device capable of communicating with a network device via an indirect path and a direct path, the RB being associated with the indirect path and the direct path; and

perform a communication with the network device via one of the indirect and direct path or both of the indirect and direct paths based on at least one of the following:

a comparison result between the total pending data volume and data volume threshold,

information about channel usage state of the direct path and/or the indirect path,

information about transmission capability of the direct path and/or the indirect path.
The remote terminal device of claim 13, wherein the indirect path comprising a first hop between the remote terminal device and a relay terminal device and a second hop between the relay terminal device and the network device, and the first hop is a PC5 connection, and

the total pending data volume is a sum of at least one of the following:

pending data volume of packet data convergence protocol (PDCP) ,

pending data volume of Uu radio link control (RLC) , or

pending data volume of PC5 RLC, or

pending data volume of sidelink relay adaptation protocol (SRAP) .
The remote terminal device of claim 13, wherein the indirect path comprising a first hop between the remote terminal device and a relay terminal device and a second hop between the relay terminal device and the network device, and the first hop is a non-PC5 connection, and

the total pending data volume is an addition of at least one of the following:

pending data volume of packet data convergence protocol (PDCP) ,

pending data volume of radio link control (RLC) over the direct path, or

pending data volume over the indirect path.
The remote terminal device of claim 13, wherein performing the communication with the network device comprises:

if the total pending data volume is equal to or larger than the data volume threshold, performing the communication with the network device via both of the direct path and the indirect path, or

if the total pending data volume is smaller than the data volume threshold, performing the communication with the network device via one of the direct path and the indirect path.
The remote terminal device of claim 13, wherein one of the direct path and the indirect path is configured to be a primary path, and wherein performing the communication with the network device via one of the direct path or the indirect path comprises:

performing the communication with the network device via the primary path.
The remote terminal device of claim 17, wherein the processor is further configured to cause the relay terminal device to:

receive, from the network device, a fifth configuration indicating the primary path.
A remote terminal device comprising:

a processor configured to cause the remote terminal device to:

associate, a radio bearer (RB) of a plurality of RBs of the remote terminal device with an indirect path and a direct path, the remote terminal device capable of communicating with a network device via the indirect path and a direct path; and

perform a multi-path transmission of the RB with the network device based on the association.
The remote terminal device of claim 19, wherein each of the plurality of RBs is configured with an identity which is unique with respect to the direct path and indirect path.