WO2024092657A1

WO2024092657A1 - Method, device and computer storage medium of communication

Info

Publication number: WO2024092657A1
Application number: PCT/CN2022/129664
Authority: WO
Inventors: You Li; Gang Wang
Original assignee: Nec Corporation
Priority date: 2022-11-03
Filing date: 2022-11-03
Publication date: 2024-05-10

Abstract

Example embodiments of the present disclosure relate to a method of communication, comprising: determining, at a source network device that serves a remote terminal device via a relay terminal device, a path switching of the remote terminal device is triggered; and transmitting, to a target network device, at least one packet data convergence protocol (PDCP) data unit for the remote terminal device, the at least one PDCP data unit being one of the following: at least one PDCP data unit buffered at the source network device for the remote terminal device, or at least one PDCP data unit without acknowledgement information confirmed by a PDCP layer of the remote terminal device.

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 inter-gNB path switching.

BACKGROUND

In wireless communication network device, a terminal device may communicate with the network device via a direct path or an indirect path. Specifically, in case of the direct path, the terminal device may communicate with the network device directly, while in case of the indirect path, the terminal device may communicate with the network device via at least one relay terminal device. Further, the location of the terminal device and the communication condition may change over time. In order to maintain a continuous communication with the network, the terminal device may be switched to a new path or connected to a new network device sometimes, i.e., performing a path switch.

Generally speaking, during a path switch, the source network device needs to forward the related data which has not been successfully transmitted to the UE to the target network device. However, as for the scenario of inter-gNB path switching, in case that the source path is an indirect path, the source network device does not communicate with the remote terminal device directly, which causes that the source network device cannot well understand the actual transmission status of the data units at the remote terminal device. However, if the source network device does not forward the proper data units to the target network device, the communication at the remote terminal device would be disturbed. Thus, it is needed to propose a solution, where the source network device may forward proper data unit to the target network device, such that the continuous communication is guaranteed.

SUMMARY

In general, embodiments of the present disclosure provide methods, devices and computer storage media of path switching.

In a first aspect, there is provided a communication method. The method comprises: determining, at a source network device that serves a remote terminal device via a relay terminal device, a path switching of the remote terminal device is triggered; and transmitting, to a target network device, at least one packet data convergence protocol (PDCP) data unit for the remote terminal device, the at least one PDCP data unit being one of the following: at least one PDCP data unit buffered at the source network device for the remote terminal device, or at least one PDCP data unit without acknowledgement information confirmed by a PDCP layer of the remote terminal device.

In a second aspect, there is provided a communication method. The method comprises: detecting, at a remote terminal device connected with a source network device via a relay terminal device, a pre-configured event for reporting a packet data convergence protocol (PDCP) status report for path switching; and transmitting, the PDCP status report for path switching to at least one of the following: the source network device via the relay terminal device, or a target network device directly or indirectly.

In a third aspect, there is provided a communication method. The method comprises: receiving, at a target network device and from a source network device that serves a remote terminal device via a relay terminal device, at least one PDCP data unit for the remote terminal device, the at least one PDCP data unit being one of the following: at least one PDCP data unit buffered at the source network device for the remote terminal device, or at least one PDCP data unit without acknowledgement information confirmed by a PDCP layer of the remote terminal device, wherein the remote terminal device is performing a path switching.

In a fourth aspect, there is provided a source network device. The source network device 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 source network device to perform the method according to the first aspect.

In a fifth aspect, there is provided a remote terminal device. The remote terminal device 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 remote terminal device to perform the method according to the second aspect.

In a sixth aspect, there is provided a target network device. The target network device 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 target network device to perform the method according to the third aspect.

In a seventh 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, or third 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. 1A illustrates a signaling chart illustrating a process for handover in some embodiments;

FIG. 1B illustrates a signaling chart illustrating another process for inter-gNB path switching in some embodiments, where the source path is an indirect path;

FIG. 1C illustrates an example block diagram for data transmission on a source indirect path;

FIG. 2A illustrates a block diagram of a communication environment in which embodiments of the present disclosure can be implemented;

FIG. 2B illustrates anther block diagram of a communication environment in which embodiments of the present disclosure can be implemented;

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

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

FIG. 5 illustrates a signaling chart illustrating a further process for communication according to some embodiments of the present disclosure;

FIG. 6 illustrates a signaling chart illustrating a further process for communication according to some embodiments of the present disclosure;

FIG. 7 illustrates a signaling chart illustrating a further process for communication according to some embodiments of the present disclosure;

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

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

FIG. 10 illustrates a further example method of communication implemented at a CN 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 has ‘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’ and ‘the’ are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term ‘includes’ and 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’ and ‘an embodiment’ are 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, ’ and 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.

In the wireless communication network, a terminal device may communicate with the network via a direct network connection or an indirect network connection. Further, in case of path switch, the communication path of the terminal device may be switched from a source network device to a target network device. In some embodiments, the source network device and the target network device are located in a same physical device (referred to as intra-gNB) . Alternatively, in some other embodiments, the source network device and the target network device are located in different physical devices (referred to as inter-gNB) .

In view of the above, a path switching maybe associated with any of: indirect-to-direct (I2D) path switching for intra-gNB, indirect-to-indirect (I2I) path switching for intra-gNB, direct-to-direct (D2D) path switching for intra-gNB, direct-to-indirect (D2I) path switching for intra-gNB, I2D for inter-gNB, I2I for inter-gNB, D2D for inter-gNB and D2I for inter-gNB.

In case of inter-gNB path switching, the remote terminal device would be switched from a source path (corresponding to the source network device) to a target path (corresponding to the target network device) .

Reference is now made to FIG. 1A, which illustrates a signaling chart illustrating process 100 for handover according to some embodiments.

As illustrated in FIG. 1A, the source gNB issues a Handover Request message to the target gNB passing a transparent RRC container with necessary information to prepare the handover at the target side. The information includes at least the target cell ID, KgNB*, the cell-radio network temporary identity (C-RNTI) of the UE in the source gNB, radio resource management (RRM) -configuration including UE inactive time, basic AS-configuration including antenna information and downlink (DL) carrier frequency, the current quality of service (QoS) flow to DRB mapping rules applied to the UE, the signaling radio bearer 1 (SRB1) from source gNB, the UE capabilities for different RATs, protocol data unit (PDU) session related information, and can include the UE reported measurement information including beam-related information if available. The PDU session related information includes the slice information and QoS flow level QoS profile (s) . The source gNB may also request a dual active protocol stack (DAPS) handover for one or more data radio bearers (DRBs) .

In some embodiments, an admission control may be performed by the target gNB. Slice-aware admission control shall be performed if the slice information is sent to the target gNB. If the PDU sessions are associated with non-supported slices the target gNB shall reject such PDU Sessions.

In some embodiments, the target gNB prepares the handover with layer 1 (L1) /L2 and sends the HANDOVER REQUEST ACKNOWLEDGE to the source gNB, which includes a transparent container to be sent to the UE as an RRC message to perform the handover. The target gNB also indicates if a DAPS handover is accepted.

In some embodiments, the source gNB triggers the Uu handover by sending an RRCReconfiguration message to the UE, containing the information required to access the target cell: at least the target cell ID, the new C-RNTI, the target gNB security algorithm identifiers for the selected security algorithms. It can also include a set of dedicated RACH resources, the association between random access channel (RACH) resources and synchronization signal and PBCH block, SSB (s) , the association between RACH resources and UE-specific channel state information (CSI) -reference signal (RS) configuration (s) , common RACH resources, and system information of the target cell, etc.

In some embodiments, for DRBs not configured with DAPS, the source gNB sends the SN STATUS TRANSFER message to the target gNB to convey the uplink PDCP sequence number (SN) receiver status and the downlink PDCP SN transmitter status of DRBs for which PDCP status preservation applies, i.e., radio link control (RLC) , acknowledge mode (AM) . The uplink PDCP SN receiver status includes at least the PDCP SN of the first missing UL PDCP service data unit (SDU) and may include a bit map of the receive status of the out of sequence UL PDCP SDUs that the UE needs to retransmit in the target cell, if any. The downlink PDCP SN transmitter status indicates the next PDCP SN that the target gNB shall assign to new PDCP SDUs, not having a PDCP SN yet.

In some embodiments, the UE synchronizes to the target cell and completes the RRC handover procedure by sending RRCReconfigurationComplete message to target gNB.

In case of DAPS handover, the UE does not detach from the source cell upon receiving the RRCReconfiguration message. The UE releases the source resources and configurations and stops DL/UL reception/transmission with the source upon receiving an explicit release from the target node.

In some embodiments, in case of DAPS handover, the target gNB sends the HANDOVER SUCCESS message to the source gNB to inform that the UE has successfully accessed the target cell. In return, the source gNB sends the SN STATUS TRANSFER message for DRBs configured with DAPS.

In some embodiments, 5GC (such as, access and mobility management function, AMF, or user plane function, UPF) switches the downlink data path towards the target gNB. The UPF sends one or more "end marker" packets on the old path to the source gNB per PDU session/tunnel and then can release any U-plane/TNL resources towards the source gNB.

In some embodiments, upon reception of the PATH SWITCHING REQUEST ACKNOWLEDGE message from the AMF, the target gNB sends the UE CONTEXT RELEASE to inform the source gNB about the success of the handover. The source gNB can then release radio and C-plane related resources associated to the UE context. Any ongoing data forwarding may continue.

In some embodiments, during the handover preparation, the user-plane tunnels can be established between the source gNB and the target gNB, and during the handover execution, user data can be forwarded from the source gNB to the target gNB. Additionally, in some embodiments, data forwarding should take place in order as long as packets are received at the source gNB from the UPF or the source gNB buffer has not been emptied.

In some embodiments, during HO completion, the target gNB sends a path switching request message to the AMF to inform that the UE has gained access and the AMF then triggers path switching related 5GC internal signalling and actual path switching of the source gNB to the target gNB in UPF. Then, the source gNB should continue forwarding data as long as packets are received at the source gNB from the UPF or the source gNB buffer has not been emptied.

In some embodiments, for RLC-AM bearers (i.e., for bearer/PDCP entity configured with RLC AM entity) , the occurrence of duplicates over the air interface in the target gNB is minimized by means of PDCP SN based reporting at the target gNB by the UE. In uplink, the reporting is optionally configured on a per DRB basis by the gNB and the UE should first start by transmitting those reports when granted resources are in the target gNB. In downlink, the gNB is free to decide when and for which bearers a report is sent and the UE does not wait for the report to resume uplink transmission.

In some embodiments, the target gNB re-transmits and prioritizes all downlink data forwarded by the source gNB (i.e., the target gNB should first send all forwarded PDCP SDUs with PDCP SNs, then all forwarded downlink PDCP SDUs without SNs before sending new data from 5GC) , excluding PDCP SDUs for which the reception was acknowledged through PDCP SN based reporting by the UE.

In some embodiments, as long as data forwarding of downlink user data packets takes place, the source next generation radio access network (NG-RAN) node shall forward user data in the same forwarding tunnel. That is, for any QoS flow accepted for data forwarding by the target NG-RAN node and for which a DRB downlink forwarding tunnel was established for a DRB to which this QoS flow was mapped at the source NG-RAN node, any fresh packets of this QoS flow shall be forwarded as PDCP SDUs via the mapped DRB downlink forwarding tunnel.

In some embodiments, for DRBs for which preservation of SN status applies, the source NG-RAN node may forward in order to the target NG-RAN node via the DRB downlink forwarding tunnel all downlink PDCP SDUs with their SN corresponding to PDCP PDUs which have not been acknowledged by the UE.

In some embodiments, the SN of forwarded PDCP SDUs is carried in the "PDCP PDU number" field of the GPRS Tunnelling Protocol for the user plane (GTP-U) extension header.

In some embodiments, for any QoS flow accepted for data forwarding by the target NG-RAN node for which a downlink PDU session forwarding tunnel was established, the source NG-RAN node forwards SDAP SDUs as received on NG-U from the UPF.

In the specific embodiment of FIG. 1A, the UE connects to the source gNB directly, thus the source gNB may obtain a relative reliable information about the transmission status of the data unit at the UE. However, this solution cannot be adaptable for the scenario where the source path is indirect path as discussed below.

Reference is now made to FIG. 1B, which illustrates a signaling chart illustrating process 120 for communication according to some embodiments.

As illustrated in FIG. 1B, after receiving the handover request acknowledge from target gNB, the source gNB may send the SN status transfer to the target gNB (i.e., step 9 can be performed after step 3) . During the handover execution, user data can be forwarded from the source gNB to the target gNB, in which the data forwarding should take place in order as long as packets are received at the source gNB from the UPF or the source gNB buffer has not been emptied. Specifically, for downlink data forwarding, the source gNB may forward in order to the target gNB via the DRB downlink forwarding tunnel all downlink PDCP SDUs with their SN corresponding to PDCP PDUs which have not been acknowledged by the UE.

However, in the specific embodiment of FIG. 1B, the source gNB does not communicate with the remote terminal device directly, which causes that the source network device cannot well understand the actual transmission status of the packet units at the remote terminal device.

Reference is now made to FIG. 1C, illustrates an example block diagram for data transmission 150 on a source indirect path.

In the specific embodiment of FIG. 1C, the source gNB knows that the next SN of the data unit to be transmitted is ‘9’ . Further, the transmission of data units of SNs #2, #4 and #7 are failed during the transmission between the source gNB and the relay UE. In other words, data units with SNs of {0, 1, 3, 5, 6, 8} are acknowledged by the relay UE with RLC ACK. Thus, when performing data forwarding via Xn interface during the path switching, the source gNB will forward data units with SNs of {2, 4, 7} to the target gNB.

However, in the specific embodiment of FIG. 1C, the transmission of data units #1, #3, #5, #6 and #8 are failed during the transmission between the remote UE and the relay UE, due to such as radio link failure or have not been transmitted when perform the path switching. In other words, as for the remote UE, data units of SNs from #1 to #8 are needed to be re-transmitted. In can be seen, in the specific embodiment of FIG. 1C, data units with SNs of {1, 3, 5, 6, 8} will be lost at the remote UE, because these data units are failed during the transmission between the remote UE and the relay UE while not forwarded by the source gNB to the target gNB.

In summary, the source gNB forwards downlink data units to target gNB based on the receiving status of relay UE instead of remote UE. In other words, those data units confirmed at Uu hop but lost at PC5 hop (e.g., due to path switching or PC5 RLF) may not be sent to the target gNB, which leads a data loss for downlink transmission at the remote UE.

Thus, it is needed to propose a solution for inter-gNB I2D/I2I path switching, where the solution may enable that the source network device may forward proper data units to the target network device, such that the continuous communication of the remote terminal device is guaranteed.

Embodiments of the present disclosure provide a solution for path switch. In the present disclosure, during an inter-gNB path switching where the source network device serves the remote terminal device via a relay terminal device, the source network device may transmit at least one PDCP data unit for the remote terminal device to the target network device. In particular, the at least one PDCP data unit is one of the following: at least one PDCP data unit buffered at the source network device for the remote terminal device, or at least one PDCP data unit without acknowledgement information confirmed by a PDCP layer of the remote terminal device. In other words, according to some embodiments of the present disclosure, the PDCP data unit (s) forwarded by the source network device on the Xn interface is not dependent on the acknowledgement (for example, RLC acknowledgement at Uu hop) in perspective of the relay terminal device. In this way, as for the data unit which is failed during the transmission between the remote terminal device and the relay terminal device, even if the data unit is confirmed by the relay terminal device, the data unit would still be forwarded from the source network device to the target network device. Thus, the continuous communication of the remote terminal device is guaranteed.

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; also referred to as a direct path sometime.

● An indirect network connection: refers to one mode of network connection, where there is a relay terminal device/relay UE between a terminal device and the network device; also referred to as a relaying path or indirect path sometimes.

● PDCP data unit: refers to a processing unit being identifiable for the PDCP entity/layer. One example of the PDCP data unit is PDCP PDU (e.g., PDCP data PDU) . Another example of the PDCP data unit is PDCP SDU.

● PDCP data unit without acknowledgement information: refers to an unsuccessfully transmission of the PDCP data unit. Moreover, the acknowledgement information may be either explicit or implicit.

In the present discourse, terms of “PDCP status report” and “PDCP SN based reporting” may be used interchangeably.

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

EXAMPLE OF COMMUNICATION NETWORK

FIG. 2A shows an example communication environment 200 in which example embodiments of the present disclosure can be implemented. The communication environment 200 comprises a plurality of terminal devices and network devices. As shown in the FIG. 2A, the communication environment 200 comprises a network device 210, a network device 215. For purpose of discussion, the

network devices

210 and 215 are individually refers to as the source network device 210 and the target network device 215, respectively.

In the specific example embodiment of FIG. 2A, the source network device 210 and the target network device 215 are located in different physical devices, and thus the inter-gNB network structure is supported in the communication environment 200.

The communication environment 200 further comprises

terminal devices

220, 230 and 235. At time point T0, the terminal device 220 communicates with the source network device 210 via the terminal device 230, i.e., via an indirect path/relaying path. In the following, the terminal device 220 may move over time or the channel condition of the terminal device 220 may become worse, which causes that the connection between the terminal device 220 and the network device 210 needs to be changed, for example, the terminal device 220 needs to be switched to another path (also referred to as a target path) .

In the specific example embodiment of FIG. 2A, at time point T1, the terminal device 220 may be switched to a target path with the target network device 215. In some embodiments, the target path is a direct path, i.e., the terminal device 210 communicates with the target network device 215 directly. Alternatively, in some other embodiments, the target path is an indirect path, i.e., the terminal device 210 communicates with the target network device 215 via the terminal device 235.

In view of the above, for purpose of discussion, the

terminal devices

220, 230 and 235 are individually refers to as the remote terminal device 220, the relay terminal device 230 and the further relay terminal device 235.

Reference is now made to FIG. 2B, which illustrates another example communication environment 250. As illustrated in FIG. 2B, a path switching may be performed between the direct and indirect paths, i.e., I2D and D2I, and also may be performed between the indirect and indirect paths, i.e. I2I.

It is to be understood that the number of devices and cells in FIG. 2A and FIG. 2B are given for the purpose of illustration without suggesting any limitations to the present disclosure. The communication network may include any suitable number of network devices and/or terminal devices adapted for implementing implementations of the present disclosure.

In some embodiments, the terminal device and the network device 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 networks

200 and 250 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 PROCESSED FOR PATH SWITCH

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.

In addition, in the following description, some interactions are performed among the terminal device and the network device (such as, exchanging configuration (s) and so on) . It is to be understood that the interactions may be implemented either in one single signaling/message or multiple signaling/messages, including system information, radio resource control (RRC) message, downlink control information (DCI) message, uplink control information (UCI) message, media access control (MAC) control element (CE) , sidelink relay adaptation protocol (SRAP) and so on. The present disclosure is not limited in this regard.

In the following, some example embodiments will be discussed for the scenario of I2D. It is be understood that the scenario of I2D is merely for the purpose of illustration without suggesting any limitations. That is, the example embodiments discussed for I2D are also suitable for the scenario of I2I. Merely for brevity, the same or similar contents are omitted.

It is to be clarified that the below discussed processes may be performed per-RB/per-DRB/per PDCP entity. Specifically, the PDCP transmission may be performed by a specific PDCP entity. Alternatively, the PDCP transmission may be specific to an RB or DRB.

Principle and implementations of the present disclosure will be described in detail below with reference to FIGS. 3 to 7, which show signaling charts illustrating processes 300 to 700 of communication according to some example embodiments of the present disclosure. For the purpose of discussion, the processes 300 to 700 will be described with reference to FIGS. 2A and 2B.

The processes 300 to 700 may involve the source network device 210, the target network device 215, the remote terminal device 220, the relay terminal device 230. Further, in the specific embodiments of FIGS. 3 to 7, the remote terminal device 220 is originally connected with the source network device 210 via the relay terminal device 230.

Reference is now made to FIG. 3. In operation, the remote terminal device 220 transmits 360 at least one PDCP data unit for the remote terminal device 220 to the target network device 215. In some embodiments, the at least one PDCP data unit is at least one PDCP data unit buffered at the source network device 210 for the remote terminal device 220. Alternatively, the at least one PDCP data unit is at least one PDCP data unit without acknowledgement information confirmed by the remote terminal device 220 (such as, a PDCP layer of the remote terminal device 220) .

In one specific embodiment, the source network device 220 forwards all (buffered/received) downlink PDCP SDUs/all PDCP SDUs unacknowledged by PDCP layer of the remote terminal device 220 (i.e., confirmed by PDCP status report/PDCP SN based reporting transmitted by the remote terminal device 220) to the target network device 215.

In this way, the PDCP data unit (s) forwarded on the Xn interface is not dependent on the acknowledgement in perspective of the relay terminal device 230. In this way, as for the data unit which is failed during the transmission between the remote terminal device 220 and the relay terminal device 230, even if the data unit is confirmed by the relay terminal device 230, the data unit would still be forwarded from the source network device 210 to the target network device 215. Thus, the continuous communication of the remote terminal device 220 is guaranteed and the data loss is avoided thereby.

In some embodiments, the source network device 210 transmits the at least one PDCP data unit conditionally on the path switching scenario, rather than (normal) handover.. Further, in some embodiments, the source network device 210 may transmit the at least one PDCP data unit conditionally on the path switching being an I2D path switching or an I2I path switching. In this way, the transmission on the Xn interface is performed under specific scenarios on demand.

In some embodiments, prior to transmitting the above related PDCP data unit (s) , the source network device 210 may determine 350 the at least one PDCP data unit without acknowledgement information. As illustrated in FIG. 3, in some embodiments, the source network device 210 receives 310 a PDCP status report for path switching generated by the remote terminal device 220, and determines the at least one PDCP data unit without acknowledgement information based on the PDCP status report.

Alternatively, or in addition, in some embodiments, the source network device 210 receives 320 feedback information indicating PC5 transmission information (such as, PC5 RLC transmission information) from the relay terminal device 230, and determines the at least one PDCP data unit without acknowledgement information based on the feedback information.

In some embodiments, the feedback information is about the unacknowledged RLC SDUs over the PC5 hop of the indirect path (i.e., the source path) , for example, RLC SDUs with negative acknowledgement.

In some other embodiments, the feedback information is about the acknowledged RLC SDUs over the PC5 hop of the indirect path, for example, RLC SDUs with positive acknowledgement. In this event, the RLC SDUs without positive acknowledgement is considered as without RLC SDUs acknowledgement information. Alternative or in addition, the RLC SDUs with negative acknowledgement is considered as without RLC SDUs acknowledgement information.

In some embodiments, the feedback information is transmitted via an L2 signalling, such as, an RRC signalling (for example, UAI, SUI) or a newly-defined RLC control PDU.

In this way, by communicating with the remote terminal device 220 and/or the relay terminal device 230, the source network device 210 may obtain the actual transmission status of data units at the remote terminal device 220.

In some embodiments, the source network device 210 treats these unacknowledged RLC SDUs over the PC5 hop of the indirect path as unacknowledged PDCP SDUs, even if they are confirmed by RLC ACK over the Uu hop of the indirect path, then the source network device 210 forwards the related unacknowledged PDCP SDUs to the target network device 215. In some other embodiments, the source network device 210 treats these unacknowledged RLC SDUs over the PC5 hop of the indirect path as unacknowledged PDCP PDUs, even if they are confirmed by RLC ACK over the Uu hop of the indirect path, then the source network device 210 forwards the PDCP SDUs corresponding to the related unacknowledged PDCP SDUs to the target network device 215.

Alternatively, the source network device 210 forwards the PDCP SDUs corresponding to the unacknowledged RLC SDUs over the PC5 hop of the indirect path.

Except for the source network device 210, the target network device 215 also may determine 330 the at least one PDCP data unit without acknowledgement information by the remote terminal device 220. As illustrated in FIG. 3, in some embodiments, the target network device 215 may determine the at least one PDCP data unit based on one or more factors. Examples of the factors, include but are not limited to:

a PDCP status report generated by the remote terminal device 220 (such as, at least one PDCP SDU with SN corresponding to at least one PDCP PDU not indicated/acknowledged by the PDCP status report) ,

at least one PDCP data unit transferred by the source network device 210 (such as, at least one PDCP SDU with SN corresponding to at least one PDCP SDU not forwarded by the source network device) ,

an SN status transfer message received from the source network device 210 (such as, SN indicated by SN STATUS TRANSFER message, where the downlink PDCP SN transmitter status indicates the next PDCP SN that the target network device 215 shall assign to new PDCP SDUs, not having a PDCP SN yet) ,

a total number of PDCP SNs,

a size of a PDCP transmission window (e.g., which may be 2 ^{[PDCP-SN-size] -1}, wherein the PDCP-SN-size is a bit size of the PDCP SN, 12 or 18 bits) ,

a first PDCP SN corresponding to a PDCP data unit in a lower boundary of the PDCP transmission window, or

a second PDCP SN corresponding to a PDCP PDU in an upper boundary of the PDCP transmission window.

In order to obtain the above factors, the target network device also may communicate 315 with the remote terminal device 220 and/or communicate 325 with the source network device 210 (such as, receiving the SN status transfer message from the source network device 210) . As one specific embodiment, the target network device 215 may receive PDCP status report from the remote terminal device 220, and determines the at least one PDCP date unit based on the PDCP status report (such as, at least one PDCP SDU not confirmed by the PDCP SN based reporting) .

After determining the at least one PDCP date unit, the target network device 215 may transmit 340 a request for the at least one PDCP data unit to the source network device 210. In some embodiments, the request may indicate the information on the at least PDCP data unit. In some embodiments, the information on the at least one PDCP data unit is a SN list or a bitmap corresponding to at least one SN of the at least one PDCP data unit. Additionally, the request may be a newly introduced Xn message.

In some embodiments, the target network device 215 transmits the request (or determines the at least PDCP data unit) conditionally on the path switching scenario. Further, in some embodiments, the target network device 215 transmits the request (or determines the at least PDCP data unit) conditionally on the path switching being an I2D path switching or an I2I path switching. In this way, the transmission on the Xn interface is performed under specific scenarios on demand.

Alternatively, in some embodiments, the target network device 215 may request the source network device 210 to transmit all buffered PDCP SDUs in case of path switching (including inter-gNB I2I path switching and inter-gNB I2D path switching) . In this way, the target network device 215 may transmit the request to the source network device 210 without determining the at least one PDCP data unit previously.

In the following, some more details will be discussed with reference to FIGS. 4 to 7. In the FIGS. 4 to 7, same reference numbers refer to the same or similar physical meanings.

As illustrated in FIG. 4, the remote terminal device 220 may be configured 410 to measure and report the measurement results. Based on the measurement results, the source network device 210 may determine 420 to perform a path switch. In the following, the source network device 210 transmits 430 a handover (HO) request to the target network device 215 and receives 440 an HO acknowledge (ACK) from the target network device 215.

In some embodiment, the target path during the path switching is either a direct path or an indirect path.

In some embodiment, the source network device 210 transmits 450 a path switching configuration (for example, an RRC reconfiguration for path switching) to the remote terminal device 220. In some embodiment, the path switching configuration is associated with an inter-gNB path switching.

In some embodiments, the source network device 210 may transmit 460 an RRC reconfiguration for the remote terminal device 220 to release the relay RLC channel. As a result, the PC5 connection between the remote terminal device 220 and the relay terminal device 230 may be released 465.

Next, the source network device 210 may transmits 470 the SN STATUS TRANSFER message to the target network device 210.

In the specific embodiment of FIG. 4, the source network device 210 may determine 350 the at least one PDCP data unit without acknowledgement information, and transmit 360 the at least PDCP data unit to the target network device 215.

In some embodiments, for DRBs for which preservation of SN status applies, the source NG-RAN node may forward in order to the target NG-RAN node via the DRB downlink forwarding tunnel:

all downlink PDCP SDUs with their SN corresponding to PDCP PDUs which have not been acknowledged by the remote terminal device 220 for normal handover, or

all (buffered/received) downlink PDCP SDUs in case of path switching (such as, inter-gNB I2I, or inter-gNB I2D) ,

■ Alternatively, all downlink PDCP SDUs with their SN corresponding to PDCP PDUs irrespective of whether they were acknowledged by the RLC entity.

all downlink PDCP SDUs with their SN corresponding to PDCP PDUs which have not been acknowledged (i.e. unacknowledged by lower layer, such as an RLC layer) by the remote terminal device 220 for normal handover, or

all downlink PDCP SDUs with their SN corresponding to PDCP PDUs which have not been acknowledged (i.e. unacknowledged by the PDCP layer) by the remote terminal device 220 in case of path switching (such as, inter-gNB I2I, or inter-gNB I2D) .

In addition, the remote terminal device 220 performs 480 a random access (RA) procedure with the target network device 215. Then, the target network device 215 receives 490 an RRC reconfiguration complete message from the remote terminal device 220, where the RRC reconfiguration complete message is transmitted in response to a successful random access (RA) procedure. Then the target network device 215 may transmit 495 a UE context release message to the source network device 210.

Reference is now made to FIG. 5. In the specific embodiment of FIG. 5, the transmitting of PDCP status report at the remote terminal device 220 may be an event-based/event-triggered procedure. Specifically, as illustrated in FIG. 5, the remote terminal device 220 detects 510 a pre-configured event for reporting the PDCP status report for path switching, and then transmits 520 the PDCP status report to the source network device 210.

In some embodiments, the pre-configured event may be one of the following:

receiving a first indication that indicates the remote terminal device 220 to report the PDCP status report for path switching,

receiving a fifth indication from an RRC layer that indicates the remote terminal device 220 to report the PDCP status report for path switching,

transmitting a measurement result for path switching,

triggering a transmission of the measurement result for path switching, or

an expiry of a first timer for report the PDCP status report for path switching.

In one specific embodiment, an upper layer (e.g., RRC layer) of the remote terminal device 220 triggers the PDCP status report upon/after reporting the measurement result for path switching. In other words, in case that the remote terminal device 220 determines to report the measurement result (i.e., the remote terminal device 220 determines/wishes to initiate a path switching) , the remote terminal device 220 may trigger the PDCP status report. The transmission of PDCP status report may be performed in parallel with the transmission of measurement result, or be performed after the transmission of measurement result.

In one specific embodiment, the remote terminal device 220 may determine whether to transmit the PDCP status report by itself, such as, detecting the pre-defined event. In some embodiments, the pre-defined event (s) 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 is needed. Alternatively, the network (e.g., the network device) may define the pre-defined event and configure the pre-defined event (s) to the remote terminal device 220, for example, receiving a configuration indicating at least one pre-defined event from the source network device 210.

In some embodiments, the remote terminal device 220 transmits the PDCP status report conditionally on the path switching scenario. Further, in some embodiments, the remote terminal device 220 transmits the PDCP status report conditionally on the path switching being an I2D path switching or an I2I path switching.

In some embodiments, the feature of transmitting the PDCP status report may be enabled or disabled by the network (such as, by the serving network device, i.e., the source network device 210) . In one specific embodiment, the remote terminal device 210 revives a second indication to enable the remote terminal device 220 to report the PDCP status report.

In some embodiments, the second indication is comprised in SI. Alternatively, in some other embodiments, the second indication is comprised in an RRC signalling. Alternatively, in the other embodiments, the second indication is comprised in any suitable signalling/message.

Reference is now made to FIG. 6. In the specific embodiment of FIG. 6, the target network device 215 may transmits 340 a request for the at least PDCP data unit to the source network device 210, such as, request for PDCP SDUs. As discussed above, the target network device 215 also may determine the at least PDCP data unit prior to transmitting the request.

In some embodiments, the target network device 215 transmits 340 the request (or determines the at least PDCP data unit) after receiving 315 a PDCP status report generated by the remote terminal device 220. In this way, the target network device 215 may well understand the actual transmission status of data units at the remote terminal device 220.

In one specific embodiment, after receiving a PDCP status report from remote terminal device 220, the target network device 215 transmits the request (or determines the at least PDCP data unit) conditionally, for example, in case of path switching, inter-gNB I2I path switching, or inter-gNB I2D path switching.

Alternatively, in some embodiments, the target network device 215 transmits the request (or determines the at least PDCP data unit) after receiving a PDCP unit with an ender marker from the source network device 210 (such as, during the data transmission performed after step7/8 as illustrated in FIG. 1A) . In this way, the target network device 215 also may obtain sufficient information for the determining the proper PDCP data units that need to be forwarded by the source network device 210 to the target network device 215.

As discussed above, in some embodiments, the target network device 215 may determine the at least one PDCP data unit based on one or more factors and further may communicate with the remote terminal device 220 and/or communicate with the source network device 210.

In some embodiments, the target network device 215 may receive PDCP status report from the remote terminal device 220. In some embodiments, the transmitting of PDCP status report from the remote terminal device 220 to the target network device 215 also may be an event-based procedure. Specifically, the remote terminal device 220 detects a pre-configured event for reporting a PDCP status report for path switching to the target network device 215, and then transmits the PDCP status report to the source network device 210.

In some embodiments, the pre-configured event may be one of the following:

transmitting an RRC complete message (e.g., for path switching) to the target network device 215,

a completion of a random access (RA) procedure to the target network device 215, or

an expiry of a second timer for report the PDCP status report for path switching.

In some embodiments, the remote terminal device 220 transmits the PDCP status report during a data transmission with the target network device 215. As one specific embodiments, in uplink, the PDCP SN based reporting (i.e., PDCP status report) is optionally configured on a per DRB basis and the remote terminal device 220 should first start by transmitting those reports when granted resources are in the target network device 215. Further, the transmission of the PDCP status report may be specific to path switching.

Further, as discussed above, the source network device 210 also may communicate with the relay terminal device 230 to obtain information, where the information may be used for determining the actual transmission status of the packet units at the remote terminal device 220. Reference is now made to FIG. 7. In the specific embodiment of FIG. 7, the source network device 210 may transmit 720 a third indication (such as a layer 2 indication) that indicates the relay terminal device 230 to report feedback information, where the feedback information indicates the PC5 transmission information for the remote terminal device 220. In response to receiving the third indication, the relay terminal device 230 may transmit 730 the feedback information to the source network device 210.

Alternatively, in some embodiments, the feedback information may be transmitted from the relay terminal device 230 to the source network device 210 periodically.

In some embodiments, the third indication is comprised in an RRC re-configuration for releasing RLC channel between the remote terminal device 220 and the relay terminal device 230. In this way, there is no needs to introducing any additional signallings.

In some embodiments, if an explicit indication (i.e., the third indication) is comprised in the RRC reconfiguration message, the relay terminal device 230 does not trigger the PC5 link release until a completion of transmitting the feedback information to the source network device 210, for example, the relay terminal device 230 does not initiate the PC5 link release as indicated by the path switching command, or the relay terminal device 230 does not release the PC5 connection release even required by the remote termina device 220.

In some embodiments, if an explicit indication (i.e., the third indication) is comprised in the RRC reconfiguration message, the relay terminal device 230 does not release the configuration of RLC relay channel (e.g. PC5, Uu) until a completion of transmitting the feedback information to the source network device 210.

In some embodiments, the third indication is sent before the path switching command for the remote terminal device 210 or the relay terminal device 230, such that there is no need to control the release of RLC relay channel and PC5 connection at the relay terminal device 230.

In some embodiments, the third indication is comprised in a newly-defined PDCP/RLC control PDU, or newly-defined MAC CE/DCI.

Further, the operation-timing for transmitting the third indication also may be ruled. In some embodiments, the transmitting the third indication is performed by the source network device 210 after receiving a handover acknowledgement for a path switching from the target network device 215. In one specific embodiment, the source network device 210 transmits the third indication when the source network device 210 decides to perform the inter gNB path switch. Alternatively, in another specific embodiment, the source network device 210 transmits the third indication after receiving an HO ACK via Xn interface.

Alternatively, in some embodiments, the transmitting the third indication is performed by the source network device 210 after transmitting an RRC re-configuration message for the path switching to the relay terminal device 230.

Alternatively, in some embodiments, the transmitting the third indication is performed by the source network device 210 after transmitting an RRC re-configuration message for the path switching to the remote terminal device 220.

Alternatively, in some embodiments, the transmitting the third indication is performed by the source network device 210 after determining that the path switching of the remote terminal device 220 is triggered.

In some embodiments, the source network device 210 transmits the third indication conditionally on the path switching scenario. Further, in some embodiments, the source network device 210 transmits the third indication conditionally on the path switching being an I2D path switching or an I2I path switching. For example, the source network device 210 determines 710 that the remote terminal device 220 is performing path switching (or, an I2I path switching or an I2D path switching) , and transmits the third indication accordingly.

In addition, in some embodiments, the feature of transmitting the feedback information may be enabled or disabled by the network (such as, by the serving network device, i.e., the source network device 210) . In one specific embodiment, the relay terminal device 230 revives a fourth indication to enable the remote terminal device 220 to report the PDCP status report.

In some embodiments, the fourth indication is comprised in SI. Alternatively, in some other embodiments, the fourth indication is comprised in an RRC signalling. Alternatively, in the other embodiments, the fourth indication is comprised in any suitable signalling/message.

According to the above processes, under a scenario of inter-gNB I2I/I2D path switching, as for the data unit which is failed during the transmission between the remote terminal device 220 and the relay terminal device 230 , even if the data unit is confirmed by the relay terminal device 230, the data unit would still be forwarded from the source network device 210 to the target network device 215. Thus, the continuous communication of the remote terminal device 220 is guaranteed.

EXAMPLE OF METHODS

FIG. 8 illustrates a flowchart of a communication method 800 implemented at a source network device 210 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 source network device 210 210 in FIG. 2A.

At block 810, the source network device 210 determines a path switching of the remote terminal device 220 is triggered, where the source network device 210 serves a remote terminal device 220 via a relay terminal device 230.

At block 820, the source network device 210 transmits, to a target network device 215, at least one PDCP data unit for the remote terminal device 220, the at least one PDCP data unit being one of the following: at least one PDCP data unit buffered at the source network device 210 for the remote terminal device 220, or at least one PDCP data unit without acknowledgement information confirmed by a PDCP layer of the remote terminal device 220.

In some example embodiments, transmitting the at least one PDCP data unit comprises: transmitting the at least one PDCP data unit is conditional on the path switching being an indirect-to-direct (I2D) path switching or an indirect-to-indirect (I2I) path switching.

In some example embodiments, the method further comprises: receiving, at least one of the following: from the relay terminal device 230, a PDCP status report for path switching generated by the remote terminal device 220; or from the relay terminal device 230, feedback information indicating PC5 transmission information for the remote terminal device 220; and determining, based on at least one of the PDCP status report for path switching or the feedback information, the at least one PDCP data unit without acknowledgement information.

In some example embodiments, either or both of the PDCP status report for path switching and feedback information are transmitted periodically.

In some example embodiments, the method further comprises: transmitting, to the remote terminal device 220 via the relay terminal device 230, at least one of the following: a first indication that indicates the remote terminal device 220 to report the PDCP status report for path switch, or a second indication to enable the remote terminal device 220 to report the PDCP status report for path switch.

In some example embodiments, either of the first and second indications is comprised in system information (SI) or a radio resource control (RRC) signalling.

In some example embodiments, the method further comprises: transmitting, to the relay terminal device 230, at least one of the following: a third indication that indicates the relay terminal device 230 to report the feedback information, or a fourth indication to enable the relay terminal device 230 to report the feedback information.

In some example embodiments, transmitting the third indication comprises: transmitting the third indication is performed after one of the following: receiving a handover acknowledgement for a path switching from the target network device 215; or transmitting a radio resource control (RRC) re-configuration message for the path switching to the relay terminal device 230; or transmitting an RRC re-configuration message for the path switching to the remote terminal device 220; or determining that the path switching of the remote terminal device 220 is triggered.

In some example embodiments, the third indication is comprised in a resource control (RRC) re-configuration for releasing radio link control (RLC) channel between the remote terminal device 220 and the relay terminal device 230.

In some example embodiments, transmitting the third indication comprises: transmitting third indication is conditional on a determination that the path switching is an indirect-to-direct (I2D) path switching or an indirect-to-indirect (I2I) path switching.

In some example embodiments, transmitting the at least PDCP data unit comprises: transmitting at least PDCP data unit for the remote terminal device 220 to the target network device 215 in response to receiving a request for the at least PDCP data unit from the target network device 215.

In some example embodiments, the request indicating the information on the at least PDCP data unit.

FIG. 9 illustrates a flowchart of a communication method 900 implemented at a remote terminal device 220 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 remote terminal device 220 in FIG. 2A.

At block 910, the remote terminal device 220 detects, at a remote terminal device 220 connected with a source network device 210 via a relay terminal device 230, a pre-configured event for reporting a packet data convergence protocol (PDCP) status report for path switching.

At block 920, the remote terminal device 220 transmits, the PDCP status report for path switching to at least one of the following: the source network device 210 via the relay terminal device 230, or a target network device 215 directly or indirectly.

In some example embodiments, transmitting the PDCP status report for path switching to the source network device 210 comprises: transmitting the PDCP status report for path switching to the source network device 210 in response to detecting a pre-configured event being one of the following: receiving a first indication that indicates the remote terminal device 220 to report the PDCP status report for path switching, receiving a fifth indication from a radio resource control (RRC) layer that indicates the remote terminal device 220 to report the PDCP status report for path switching, transmitting a measurement result for path switching, triggering a transmission of the measurement result for path switching, or an expiry of a first timer for report the PDCP status report for path switching.

In some example embodiments, transmitting the PDCP status report for path switching to the target network device 215 comprises: transmitting the PDCP status report for path switching to the target network device 215 in response to detecting a pre-configured event being one of the following: transmitting a radio resource control (RRC) complete message to the target network device 215, a completion of a random access (RA) procedure to the target network device 215, or an expiry of a second timer for report the PDCP status report for path switching.

In some example embodiments, transmitting the PDCP status report for path switching to the target network device 215 comprises: transmitting the PDCP status report during a data transmission with the target network device 215.

In some example embodiments, transmitting the PDCP status report comprises: transmitting the PDCP status report is conditional on a determination that the remote terminal device 220 is performing an indirect-to-direct (I2D) path switching or an indirect-to-indirect (I2I) path switching.

In some example embodiments, the method further comprises: reviving, a second indication to enable the remote terminal device 220 to report the PDCP status report.

In some example embodiments, the second indication is comprised in system information (SI) or a radio resource control (RRC) signalling.

FIG. 10 illustrates a flowchart of a communication method 1000 implemented at a target network device 215 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 target network device 215 in FIG. 2A.

At block 1010, the target network device 215 receives, at a target network device 215 and from a source network device 210 that serves a remote terminal device 220 via a relay terminal device 230, at least one PDCP data unit for the remote terminal device 220, the at least one PDCP data unit being one of the following: at least one PDCP data unit buffered at the source network device 210 for the remote terminal device 220, or at least one PDCP data unit without acknowledgement information confirmed by a PDCP layer of the remote terminal device 220, wherein the remote terminal device 220 is performing a path switching.

In some example embodiments, the method further comprises: transmitting, to the source network device 210, a request for the at least PDCP data unit.

In some example embodiments, the request indicates the information on the at least PDCP data unit.

In some example embodiments, the method further comprises: determining the at least PDCP data unit based on at least one of the following: a PDCP status report generated by the remote terminal device 220, at least one PDCP data unit transferred by the source network device 210, a sequence number (SN) status transfer message received from the source network device 210, a total number of PDCP SNs, a size of a PDCP transmission window, a first PDCP SN corresponding to a PDCP data unit in a lower boundary of the PDCP transmission window, or a second PDCP SN corresponding to a PDCP PDU in an upper boundary of the PDCP transmission window.

In some example embodiments, transmitting the request comprises: transmitting the request is performed after one of the following: receiving a PDCP status report generated by the remote terminal device 220, or receiving a PDCP unit with an ender marker from the source network device 210.

In some example embodiments, transmitting the request comprises: transmitting the request is conditional on the path switching being an indirect-to-direct (I2D) path switching or an indirect-to-indirect (I2I) path switching.

EXAMPLE OF APPARATUSES AND DEVICES

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 remote terminal device 220, the source network device 210 or the target network device 215 as shown in FIG. 2A. Accordingly, the device 1100 can be implemented at or as at least a part of the remote terminal device 220, the source network device 210 or the target network device 215.

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, S1/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 11. 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.

In some embodiments, a source network device comprises a circuitry configured to: determining, at a source network device that serves a remote terminal device via a relay terminal device, a path switching of the remote terminal device is triggered; and transmitting, to a target network device, at least one PDCP data unit for the remote terminal device, the at least one PDCP data unit being one of the following: at least one PDCP data unit buffered at the source network device for the remote terminal device, or at least one PDCP data unit without acknowledgement information confirmed by a PDCP layer of the remote terminal device.

In some embodiments, a remote terminal device comprises a circuitry configured to: detecting, at a remote terminal device connected with a source network device via a relay terminal device, a pre-configured event for reporting a packet data convergence protocol (PDCP) status report for path switching; and transmitting, the PDCP status report for path switching to at least one of the following: the source network device via the relay terminal device, or a target network device directly or indirectly.

In some embodiments, a target network device comprises a circuitry configured to: receiving, at a target network device and from a source network device that serves a remote terminal device via a relay terminal device, at least one PDCP data unit for the remote terminal device, the at least one PDCP data unit being one of the following: at least one PDCP data unit buffered at the source network device for the remote terminal device, or at least one PDCP data unit without acknowledgement information confirmed by a PDCP layer of the remote terminal device, wherein the remote terminal device is performing a path switching.

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, 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, a method of communication, comprising: determining, at a source network device that serves a remote terminal device via a relay terminal device, a path switching of the remote terminal device is triggered; and transmitting, to a target network device, at least one PDCP data unit for the remote terminal device, the at least one PDCP data unit being one of the following: at least one PDCP data unit buffered at the source network device for the remote terminal device, or at least one PDCP data unit without acknowledgement information confirmed by a PDCP layer of the remote terminal device.

In some embodiments, transmitting the at least one PDCP data unit comprises: transmitting the at least one PDCP data unit is conditional on the path switching being an indirect-to-direct (I2D) path switching or an indirect-to-indirect (I2I) path switching.

In some embodiments, the method further comprises: receiving, at least one of the following: from the relay terminal device, a PDCP status report for path switching generated by the remote terminal device; or from the relay terminal device, feedback information indicating PC5 transmission information for the remote terminal device; and determining, based on at least one of the PDCP status report for path switching or the feedback information, the at least one PDCP data unit without acknowledgement information.

In some embodiments, either or both of the PDCP status report for path switching and feedback information are transmitted periodically.

In some embodiments, the method further comprises: transmitting, to the remote terminal device via the relay terminal device, at least one of the following: a first indication that indicates the remote terminal device to report the PDCP status report for path switch, or a second indication to enable the remote terminal device to report the PDCP status report for path switch.

In some embodiments, either of the first and second indications is comprised in system information (SI) or a radio resource control (RRC) signalling.

In some embodiments, the method further comprises: transmitting, to the relay terminal device, at least one of the following: a third indication that indicates the relay terminal device to report the feedback information, or a fourth indication to enable the relay terminal device to report the feedback information.

In some embodiments, transmitting the third indication comprises: transmitting the third indication is performed after one of the following: receiving a handover acknowledgement for a path switching from the target network device; or transmitting a radio resource control (RRC) re-configuration message for the path switching to the relay terminal device; or transmitting an RRC re-configuration message for the path switching to the remote terminal device; or determining that the path switching of the remote terminal device is triggered.

In some embodiments, the third indication is comprised in a resource control (RRC) re-configuration for releasing radio link control (RLC) channel between the remote terminal device and the relay terminal device.

In some embodiments, transmitting the third indication comprises: transmitting third indication is conditional on a determination that the path switching is an indirect-to-direct (I2D) path switching or an indirect-to-indirect (I2I) path switching.

In some embodiments, transmitting the at least PDCP data unit comprises: transmitting at least PDCP data unit for the remote terminal device to the target network device in response to receiving a request for the at least PDCP data unit from the target network device.

In some embodiments, the request indicating the information on the at least PDCP data unit.

In an aspect, a method of communication, comprising: detecting, at a remote terminal device connected with a source network device via a relay terminal device, a pre-configured event for reporting a packet data convergence protocol (PDCP) status report for path switching; and transmitting, the PDCP status report for path switching to at least one of the following: the source network device via the relay terminal device, or a target network device directly or indirectly.

In some embodiments, transmitting the PDCP status report for path switching to the source network device comprises: transmitting the PDCP status report for path switching to the source network device in response to detecting a pre-configured event being one of the following: receiving a first indication that indicates the remote terminal device to report the PDCP status report for path switching, receiving a fifth indication from a radio resource control (RRC) layer that indicates the remote terminal device to report the PDCP status report for path switching, transmitting a measurement result for path switching, triggering a transmission of the measurement result for path switching, or an expiry of a first timer for report the PDCP status report for path switching.

In some embodiments, transmitting the PDCP status report for path switching to the target network device comprises: transmitting the PDCP status report for path switching to the target network device in response to detecting a pre-configured event being one of the following: transmitting a radio resource control (RRC) complete message to the target network device, a completion of a random access (RA) procedure to the target network device, or an expiry of a second timer for report the PDCP status report for path switching.

In some embodiments, transmitting the PDCP status report for path switching to the target network device comprises: transmitting the PDCP status report during a data transmission with the target network device.

In some embodiments, transmitting the PDCP status report comprises: transmitting the PDCP status report is conditional on a determination that the remote terminal device is performing an indirect-to-direct (I2D) path switching or an indirect-to-indirect (I2I) path switching.

In some embodiments, the method further comprises: reviving, a second indication to enable the remote terminal device to report the PDCP status report.

In some embodiments, the second indication is comprised in system information (SI) or a radio resource control (RRC) signalling.

In an aspect, a method of communication, comprising: receiving, at a target network device and from a source network device that serves a remote terminal device via a relay terminal device, at least one PDCP data unit for the remote terminal device, the at least one PDCP data unit being one of the following: at least one PDCP data unit buffered at the source network device for the remote terminal device, or at least one PDCP data unit without acknowledgement information confirmed by a PDCP layer of the remote terminal device, wherein the remote terminal device is performing a path switching.

In some embodiments, the method further comprises: transmitting, to the source network device, a request for the at least PDCP data unit.

In some embodiments, the request indicates the information on the at least PDCP data unit.

In some embodiments, the method further comprises: determining the at least PDCP data unit based on at least one of the following: a PDCP status report generated by the remote terminal device, at least one PDCP data unit transferred by the source network device, a sequence number (SN) status transfer message received from the source network device, a total number of PDCP SNs, a size of a PDCP transmission window, a first PDCP SN corresponding to a PDCP data unit in a lower boundary of the PDCP transmission window, or a second PDCP SN corresponding to a PDCP PDU in an upper boundary of the PDCP transmission window.

In some embodiments, transmitting the request comprises: transmitting the request is performed after one of the following: receiving a PDCP status report generated by the remote terminal device, or receiving a PDCP unit with an ender marker from the source network device.

In some embodiments, transmitting the request comprises: transmitting the request is conditional on the path switching being an indirect-to-direct (I2D) path switching or an indirect-to-indirect (I2I) path switching.

In an aspect, a source network device 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 source network device discussed above.

In an aspect, a remote terminal device 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 discussed above.

In an aspect, a target network device 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 target network device 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 source network device 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 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 target network device 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 source network device 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 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 target network device 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. 3 to 10. 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 method of communication, comprising:

determining, at a source network device that serves a remote terminal device via a relay terminal device, a path switching of the remote terminal device is triggered; and

transmitting, to a target network device, at least one PDCP data unit for the remote terminal device, the at least one PDCP data unit being one of the following:

at least one PDCP data unit buffered at the source network device for the remote terminal device, or

at least one PDCP data unit without acknowledgement information confirmed by a PDCP layer of the remote terminal device.
The method of claim 1, wherein transmitting the at least one PDCP data unit comprises:

transmitting the at least one PDCP data unit is conditional on the path switching being an indirect-to-direct (I2D) path switching or an indirect-to-indirect (I2I) path switching.
The method of claim 1, further comprising:

receiving, at least one of the following:

from the relay terminal device, a PDCP status report for path switching generated by the remote terminal device; or

from the relay terminal device, feedback information indicating PC5 transmission information for the remote terminal device; and

determining, based on at least one of the PDCP status report for path switching or the feedback information, the at least one PDCP data unit without acknowledgement information.
The method of claim 3, wherein either or both of the PDCP status report for path switching and feedback information are transmitted periodically.
The method of claim 3, further comprising:

transmitting, to the remote terminal device via the relay terminal device, at least one of the following:

a first indication that indicates the remote terminal device to report the PDCP status report for path switch, or

a second indication to enable the remote terminal device to report the PDCP status report for path switch.
The method of claim 5, wherein either of the first and second indications is comprised in system information (SI) or a radio resource control (RRC) signalling.
The method of claim 1, wherein transmitting the at least PDCP data unit comprises:

transmitting at least PDCP data unit for the remote terminal device to the target network device in response to receiving a request for the at least PDCP data unit from the target network device.
The method of claim 7, wherein the request indicating the information on the at least PDCP data unit.
A method of communication, comprising:

detecting, at a remote terminal device connected with a source network device via a relay terminal device, a pre-configured event for reporting a packet data convergence protocol (PDCP) status report for path switching; and

transmitting, the PDCP status report for path switching to at least one of the following:

the source network device via the relay terminal device, or

a target network device directly or indirectly.
The method of claim 9, wherein transmitting the PDCP status report for path switching to the source network device comprises:

transmitting the PDCP status report for path switching to the source network device in response to detecting a pre-configured event being one of the following:

receiving a first indication that indicates the remote terminal device to report the PDCP status report for path switching from the source network device,

receiving a fifth indication from a radio resource control (RRC) layer that indicates the remote terminal device to report the PDCP status report for path switching,

transmitting a measurement result for path switching,

triggering a transmission of the measurement result for path switching, or

an expiry of a first timer for report the PDCP status report for path switching.
The method of claim 9, wherein transmitting the PDCP status report for path switching to the target network device comprises:

transmitting the PDCP status report for path switching to the target network device in response to detecting a pre-configured event being one of the following:

transmitting a radio resource control (RRC) complete message to the target network device,

a completion of a random access (RA) procedure to the target network device, or

an expiry of a second timer for report the PDCP status report for path switching.
The method of claim 9, wherein transmitting the PDCP status report for path switching to the target network device comprises:

transmitting the PDCP status report during a data transmission with the target network device.
The method of claim 9, wherein transmitting the PDCP status report comprises:

transmitting the PDCP status report is conditional on a determination that the remote terminal device is performing an indirect-to-direct (I2D) path switching or an indirect-to-indirect (I2I) path switching.
The method of claim 9, further comprising:

reviving, a second indication to enable the remote terminal device to report the PDCP status report.
The method of claim 14, wherein the second indication is comprised in system information (SI) or a radio resource control (RRC) signalling.
A method of communication, comprising:

receiving, at a target network device and from a source network device that serves a remote terminal device via a relay terminal device, at least one packet data convergence protocol (PDCP) data unit for the remote terminal device, the at least one PDCP data unit being one of the following:

at least one PDCP data unit buffered at the source network device for the remote terminal device, or

at least one PDCP data unit without acknowledgement information confirmed by a PDCP layer of the remote terminal device,

wherein the remote terminal device is performing a path switching.
The method of claim 16, further comprising:

transmitting, to the source network device, a request for the at least PDCP data unit.
The method of claim 17, wherein the request indicates the information on the at least PDCP data unit.
The method of claim 18, further comprising:

determining the at least PDCP data unit based on at least one of the following:

a PDCP status report generated by the remote terminal device,

at least one PDCP data unit transferred by the source network device,

a sequence number (SN) status transfer message received from the source network device,

a total number of PDCP SNs,

a size of a PDCP transmission window,

a first PDCP SN corresponding to a PDCP data unit in a lower boundary of the PDCP transmission window, or

a second PDCP SN corresponding to a PDCP PDU in an upper boundary of the PDCP transmission window.
The method of claim 17, wherein transmitting the request comprises:

transmitting the request is conditional on the path switching being an indirect-to-direct (I2D) path switching or an indirect-to-indirect (I2I) path switching.