WO2024060242A1 - Procédé, dispositif et support de stockage informatique de communication - Google Patents

Procédé, dispositif et support de stockage informatique de communication Download PDF

Info

Publication number
WO2024060242A1
WO2024060242A1 PCT/CN2022/121073 CN2022121073W WO2024060242A1 WO 2024060242 A1 WO2024060242 A1 WO 2024060242A1 CN 2022121073 W CN2022121073 W CN 2022121073W WO 2024060242 A1 WO2024060242 A1 WO 2024060242A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal device
entity
standardized
pdu
packet
Prior art date
Application number
PCT/CN2022/121073
Other languages
English (en)
Inventor
You Li
Gang Wang
Original Assignee
Nec Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nec Corporation filed Critical Nec Corporation
Priority to PCT/CN2022/121073 priority Critical patent/WO2024060242A1/fr
Publication of WO2024060242A1 publication Critical patent/WO2024060242A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user

Definitions

  • Embodiments of the present disclosure generally relate to the field of telecommunication, and in particular, to methods, devices and computer storage media for transmission and configuration on multi-path.
  • a technology of multi-path is proposed to be supported to enhance reliability and throughput.
  • a user equipment UE is allowed to communicate with the network via both a direct path and an indirect path, and the UE may switch among or utilize the multiple paths simultaneously.
  • the UE may connect to the network device via a layer-2 UE-to-network relay, or via another UE (where the UE-UE inter-connection is assumed to be ideal) .
  • SRAP sidelink relay adaptation protocol
  • RLC radio link control
  • the RLC entity, or even the SRAP entity may be not configured.
  • the upper layer data such as, packet data convergence protocol (PDCP) packet data unit (PDU)
  • PDCP packet data convergence protocol
  • PDU packet data unit
  • embodiments of the present disclosure provide methods, devices and computer storage media for transmission and configuration on multi-path.
  • a method of communication comprises: generating, at a first terminal device, a first packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a media access control (MAC) PDU, the first packet indicating first information of at least one of the following: a first radio bearer (RB) identity (ID) of a first RB, an ID of the first terminal device, or a first indication indicating a type of the first RB; and transmitting, the first packet to a second terminal device via a non-standardized indirect path.
  • RB radio bearer
  • ID identity
  • a method of communication comprises: receiving, at a second terminal device and from a first terminal device, a first packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU via a non-standardized indirect path, the first packet indicating first information of at least one of the following: an RB ID of a first RB, an ID of the first terminal device, or an indication indicating a type of the first RB; and generating, a second packet based on the first packet; and transmitting, the second packet to a network device.
  • a method of communication comprises: determining, at a non-standardized entity of a terminal device involved in a non-standardized indirect path, status-related information of the non-standardized indirect path; and transmitting a fifth indication indicating the status of the non-standardized indirect path to one of the following: a radio resource control (RRC) entity, a PDCP entity, or an SRAP entity.
  • RRC radio resource control
  • a terminal device in a fourth aspect, includes a processing unit; and a memory coupled to the processing unit and storing instructions thereon, the instructions, when executed by the processing unit, causing the device to perform the method according to the first aspect.
  • a terminal device in a fifth aspect, includes a processing unit; and a memory coupled to the processing unit and storing instructions thereon, the instructions, when executed by the processing unit, causing the device to perform the method according to the second aspect.
  • a terminal device in a sixth aspect, includes a processing unit; and a memory coupled to the processing unit and storing instructions thereon, the instructions, when executed by the processing unit, causing the device to perform the method according to the third 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 carry out the method according to the first to any of the fourth aspect.
  • FIG. 1A is a block diagrams of an example communication environment in which embodiments of the present disclosure can be implemented
  • FIG. 1B is an example protocol structure of a direct path according to some embodiments of the present disclosure
  • FIG. 1C is an example protocol structure of a standardized indirect path according to some embodiments of the present disclosure.
  • FIG. 1D is an example protocol structure of a non-standardized indirect path according to some embodiments of the present disclosure
  • FIG. 2 illustrates an example structure for SRAP SDU
  • FIG. 3 illustrates a signaling chart illustrating processes for communication according to some embodiments of the present disclosure
  • FIG. 4 illustrates the interactions among the PDCP/SRAP entity/layer and the lower entity/layer
  • FIG. 5 illustrates the interactions among the PDCP/SRAP entity/layer and the lower entity/layer
  • FIG. 6 illustrates the interactions among the PDCP/SRAP entity/layer and the lower entity/layer
  • FIG. 7 illustrates another example method of communication implemented at a terminal device in accordance with some embodiments of the present disclosure
  • FIG. 8 illustrates another example method of communication implemented at a terminal device in accordance with some embodiments of the present disclosure
  • FIG. 9 illustrates another example method of communication implemented at a terminal device in accordance with some embodiments of the present disclosure.
  • FIG. 10 is a simplified block diagram of a device that is suitable for implementing embodiments of the present disclosure.
  • terminal device refers to any device having wireless or wired communication capabilities.
  • 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)
  • UE user equipment
  • the ‘terminal device’ can further have ‘multicast/broadcast’ feature, to support public safety and mission critical, V2X applications, transparent IPv4/Ipv6 multicast delivery, IPTV, smart TV, radio services, software delivery over wireless, group communications and IoT applications. It may also incorporate one or multiple Subscriber Identity Module (SIM) as known as Multi-SIM.
  • SIM Subscriber Identity Module
  • 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.
  • network device refers to a device which is capable of providing or hosting a cell or coverage where terminal devices can communicate.
  • 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.
  • NodeB Node B
  • eNodeB or eNB evolved NodeB
  • gNB next generation NodeB
  • TRP transmission reception point
  • RRU remote radio unit
  • RH radio head
  • RRH remote radio head
  • IAB node a low power node such as a fe
  • 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.
  • AI Artificial intelligence
  • 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.
  • MR-DC Multi-Radio Dual Connectivity
  • the terminal device or the network device can work on full duplex, flexible duplex and cross division duplex modes.
  • test equipment e.g. signal generator, signal analyzer, spectrum analyzer, network analyzer, test terminal device, test network device, channel emulator.
  • 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) .
  • the first network device may be a first RAT device and the second network device may be a second RAT device.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the UE is allowed to communicate with the network via both a direct path and an indirect path, and the UE may switch among or utilize the multiple paths simultaneously.
  • an SRAP entity is proposed to be configured for mapping the packet to suitable RLC channel.
  • the RCL entity, or even the SRAP entity may be not configured. In this event, the upper layer data may be unable to be properly mapped to the RLC channel (s) and unable to be transmitted to the network device.
  • Embodiments of the present disclosure provide a solution for transmission management and configuration on multi-path.
  • a first terminal device such as, a remote terminal device
  • a second terminal device such as, a relay terminal device
  • the layer 2 PDU may be exchanged among the remote terminal device, the relay terminal device and the network device.
  • a direct network connection refers to one mode of network connection, where there is no relay terminal device/relay UE between a terminal device and the network device;
  • An indirect network connection refers to one mode of network connection, where there is a relay terminal device/relay UE between a terminal device and the network device; also referred to as a relaying path sometimes;
  • An indirect path/link/connection refer to any of the following: a path between a network device and a remote terminal device via a relay terminal device or multiple relay terminal devices, a path between a remote terminal device and a relay terminal device (i.e., a PC5 path/link/connection, or a sidelink path/link/connection, or a D2D path/link/connection, or , a non-standardized path/link/connection, or a non-3GPP path/link/connection) , or a path/link/connection between a relay terminal device and a network device.
  • a path between a network device and a remote terminal device via a relay terminal device or multiple relay terminal devices i.e., a PC5 path/link/connection, or a sidelink path/link/connection, or a D2D path/link/connection, or , a non-standardized path/link/connection, or a non-3GPP path/link/connection
  • a non-standardized entity/path/link/connection/interface refers to an entity/path/link/connection/interface which is not stipulated by the standard documents (such as, 3GPP specification) or is an ideal path/link/connection. Also may be referred to as non-3GPP entity/path/link/connection/interface. Further, a non-standardized/path/link/connection/interface also may be referred to as ideal/path/link/connection. Examples of non-standardized entity/path/link/connection, include but are not limited to, Wi-Fi entity/path/link, bluetooth entity/path/link, zigbee entity/path/link.
  • a standardized entity/path/link/connection/interface refers to an entity/path/link/connection which is stipulated by the standard documents (such as, 3GPP specification) .
  • a UE-UE hop refer to the path/link/connection between the remote terminal device and the relay terminal device. It may also be referred to as UE-UE connection or UE-UE inter-connection. It may be a non-standardized path/link/connection or a standardized path/link/connection. In some embodiments, the UE-UE hop is a part of an indirect path. Additionally, in some embodiments, the UE-UE hop is a part of an indirect path non-standardized path/link/connection.
  • ⁇ A Uu hop refer to the path/link/connection between the relay terminal device and the network device.
  • terms of layer and entity may be used interchangeably.
  • Terms of RB ID, bearer ID may be used interchangeably.
  • Terms “non-standardized layer/entity” , “non-3GPP layer/entity” and “lower layer/entity” may be used interchangeably.
  • Terms “upper layer/entity” and “PDCP/SRAP/RRC layer/entity” may be used interchangeably.
  • entity (ies) corresponding to a (direct/indirect) path entity (ies) on a (direct/indirect) path, entity (ies) associated with a (direct/indirect) path may be used interchangeably.
  • same data may be represented in different data formats, such as, same data may be represented as, PDCP PDU, SRAP SDU, SRAP PDU, RLC SDU, RLC PDU, a non-standardized data unit/SDU/PDU, a non-3GPP data unit/SDU/PDU.
  • terms of PDCP PDU, SRAP SDU, SRAP PDU, RLC SUC, RLC PDU, a non-standardized data unit/SDU/PDU, a non-3GPP data unit/SDU/PDU may be used interchangeably.
  • FIG. 1A shows an example communication environment 100 in which example embodiments of the present disclosure can be implemented.
  • the communication environment 100 comprises a plurality of terminal devices and a network device.
  • the communication environment 100 comprises a network device 110, which providing a serving area, called as a cell 110-2.
  • the communication environment 100 also comprises terminal devices 120-1 and 120-2.
  • the terminal devices 120-1 and 120-2 are collectively referred to as terminal device 120, or referred to as the first terminal device 120-1 and the second terminal device 120-2, respectively.
  • the first terminal device 120-1 may communicate with the network device 110 via a plurality of paths (also referred to as multi-path) , where each of the plurality of paths may be either a direct path or an indirect path.
  • the first terminal device 120-1 (also referred to as remote UE or remote terminal device) may communicate with the network device 110 via the second terminal device 120-2 (also referred to as relay UE or relay terminal device) , while the first terminal device 120-1 may communicate with the network device 110 directly.
  • the following entities are configured for a direct path: a PDCP entity, an RLC entity, and a MAC entity.
  • the following entities are configured for a standardized indirect path: a PDCP entity, an SRAP entity, an RLC entity, and a MAC entity.
  • the following entities are configured for a standardized indirect path: a PDCP entity, an SRAP entity, an RLC entity, and a MAC entity.
  • the network device 110 may configure the indirect path for the terminal devices 120-1 and 120-2 by using RRC reconfiguration signalling.
  • the RRC reconfiguration message may indicate at least one of the following parameters to the first terminal device 120-1: an RB, an RLC channel, a sidelink RLC channel, a relay UE for the indirect path and a mapping information of RB and RLC channel (such as, egress RLC channel on PC5/UE-UE hop for the first terminal device 120-1) .
  • IEs of sl-PathSwitchConfig and SL-SourceIdentity may be used for indicating the parameters.
  • the RRC reconfiguration message also may indicate parameters to be used by the second terminal device 120-2, such that the second terminal device 120-2 may map the RB (s) to related RLC channel (s) and relay the packets between the first terminal device 120-1 and the network device 110.
  • the parameters may be a local ID of the first terminal device 120-1 (i.e., remote terminal device) .
  • Another example of the parameters may be a mapping information of RB and RLC channel (such as, both egress RLC channel on PC5/UE-UE hop and egress RLC channel on Uu hop for the second terminal device 120-2) .
  • a further example of the parameters may be a type of an Uu RB and an ID of Uu RB.
  • IEs of sl-SRAP-config, sl-MappingToAddMod and sl-RemoteUE-RB-Identity may be used for indicating the parameters.
  • an SRAP entity and a non-standardized entity may be configured for a non-standardized indirect path.
  • the SRAP entity may be absent for the non-standardized indirect path.
  • the first terminal device 120-1 may communicate with the network device 110 via any of the following paths:
  • a direct path where the first terminal device 120-1 is connected to the network device 110 directly.
  • An example protocol structure 150 of the direct path is illustrated in FIG. 1B.
  • a standardized indirect path where the first terminal device 120-1 is connected to the network device 110 via the second terminal device 120-2, and the path between the first terminal device 120-1 and the second terminal device 120-2 is PC5/sidelink (SL) path.
  • An example protocol structure 160 of the standardized indirect path is illustrated in FIG. 1C.
  • a non-standardized indirect path where the first terminal device 120-1 is connected to the network device 110 via the second terminal device 120-2, and the path between the first terminal device 120-1 and the second terminal device 120-2 is a non-standardized path.
  • An example protocol structure 170 of the non-standardized indirect path is illustrated in FIG. 1D, where the SRAP entity is optional.
  • an SRAP entity is optionally introduced for the non-standardized indirect path.
  • user plane (UP) protocol stacks for U2N RLC channels use the SRAP layer which may provide bearer mapping and remote UE identification.
  • FIG. 2 illustrates an example structure 200 for SRAP SDU.
  • the SRAP SDU may include the following fields:
  • This field carries local IF of U2N Remote UE (i.e., the first terminal device 120-1) . Length of this field may be 8 bits.
  • BEARER ID This field carries Uu radio bearer identity for U2N Remote UE. Length of this field may be 5 bits.
  • This field carries the SRAP SDU (i.e. PDCP PDU or RRC PDU) . Length of this field may be Variable.
  • This field indicates whether the corresponding SRAP PDU is an SRAP data PDU or an SRAP Control PDU. For example, value ‘0’ is used for indicating SRAP data PDU and value ‘1’ is used for indicating SRAP control PDU.
  • bearer ID for SRB may be set to any of ⁇ 0, 1, 2, 3 ⁇
  • bearer ID for DRB may be set as any of ⁇ 0, 1, 2, ..., 31 ⁇ .
  • DRB and SRB are not allowed to be multiplexed to the same PC5 RLC channel.
  • the first terminal device 120-1/the second terminal device 120-2 may distinguish whether the received PDCP PDU is data/DRB or signalling/SRB.
  • DRB and SRB are not allowed to be multiplexed to the same non-standardized channel/indirect path.
  • 5G quality of service (QoS) identifier which is a scalar is used as a reference to 5G QoS characteristics, for example, access node-specific parameters that control QoS forwarding treatment for the QoS flow (such as, scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration and so on) .
  • each 5QI value may be mapped to a standardized combination of 5G QoS characteristics, where the 5G QoS characteristics include but are not limited to default priority level, packet error rate, packet delay budget, default maximum data bust volume, default averaging window, example services and so on.
  • the first terminal device 120-1 may be connected to the network device 110 by using one direct path and one indirect path via layer-2 UE-to-network relay, referred to as scenario #1 sometimes.
  • the first terminal device 120-1 may be connected to the network device 110 by using one direct path and one indirect path via the second terminal device 120-2 (where the UE-UE inter-connection is assumed to be ideal, referred to as scenario #2 sometimes) .
  • Relay and direct multi-path operation can provide efficient path switching between direct path and indirect path;
  • the remote terminal device 120-1 in multi-path operation can provide enhanced user data throughput and reliability compared to a single link
  • the network device 110 can offload the direct connection of the remote terminal device 120-1 in congestion to indirect path via the second terminal device 120-2 (for example, at different intra/inter-frequency cells) .
  • the first terminal device 120-1 supports direct bearer (i.e., bearer mapped to direct path on Uu) , indirect bearer (i.e., bearer mapped to indirect path via the second terminal device 120-2) , and multi-path (MP) split bearer (i.e., bearer mapped to both paths, based on the existing split bearer framework) .
  • direct bearer i.e., bearer mapped to direct path on Uu
  • indirect bearer i.e., bearer mapped to indirect path via the second terminal device 120-2
  • MP multi-path
  • the relation between the first terminal device 120-1 and the second terminal device 120-2 involved in a non-standardized indirect path is pre-configured or static.
  • the mapping between the first terminal device 120-1 and the second terminal device 120-2 is a 1: 1 mapping.
  • connection between the second terminal device 120-2 and the network device 110 also may be a non-standardize path. If so, the examples described for the communication between the first terminal device 120-1 and the second terminal device 120-2 may be adaptable for the communication between the second terminal device 120-2 and the network device 110. Merely foe brevity, the same contents are omitted here.
  • the communication environment 100 may include any suitable number of network devices and/or terminal devices adapted for implementing implementations of the present disclosure. Further, the communication environment 100 may include any other devices than the network devices and the terminal devices, such as a core network element, but they are omitted here so as to avoid obscuring the present invention.
  • the terminal device 120 and the network device 110 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) .
  • PUCCH physical uplink control channel
  • PUSCH physical uplink shared channel
  • PRACH physical random-access channel
  • PDCCH physical downlink control channel
  • PDSCH physical downlink shared channel
  • PBCH physical broadcast channel
  • any other suitable channels are also feasible.
  • the communications in the communication network 100 may conform to any suitable standards including, but not limited to, Global System for Mobile Communications (GSM) , Long Term Evolution (LTE) , LTE-Evolution, LTE-Advanced (LTE-A) , New Radio (NR) , Wideband Code Division Multiple Access (WCDMA) , Code Division Multiple Access (CDMA) , GSM EDGE Radio Access Network (GERAN) , Machine Type Communication (MTC) and the like.
  • GSM Global System for Mobile Communications
  • LTE Long Term Evolution
  • LTE-Evolution LTE-Advanced
  • NR New Radio
  • WCDMA Wideband Code Division Multiple Access
  • CDMA Code Division Multiple Access
  • GERAN GSM EDGE Radio Access Network
  • MTC Machine Type Communication
  • 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.
  • FIG. 3 show a signaling chart illustrating process 300 of communication according to some example embodiments of the present disclosure.
  • the process 300 will be described with reference to Figs. 1A to 1D.
  • the process 300 may involve the terminal device 120-1, the second terminal device 120-2 and the network device 110.
  • the operations among the terminal devices 120-1 and 120-2 and the network device 110 should be coordinated.
  • the terminal devices 120-1 and 120-2 and the network device 110 should have common understanding about configuration, parameter, operations and so on. Such common understanding may be implemented by any suitable interactions among the related devices or applying the same rule/policy among the related devices.
  • the corresponding operations should be performed by the coordinated device. Merely for brevity, some of the same or similar contents are omitted here.
  • FIGs. 3 to 6 will be described with reference to FIGs. 1A to 1D.
  • the terminal device (s) 120 and the network device 110 may communicate capability-related information and configuration between each other, which will be discussed as below.
  • the indirect path is a non-standardized path (as shown in FIG. 1D)
  • whether the SRAP entity is configured for the non-standardized path is still pending.
  • whether to use the SRAP entity over UE-UE hop and/or Uu hop may be configured by the network device 110.
  • the network device 110 transmits 310 a first message to the first terminal device 120-1, where the first message may indicate whether the SRAP entity is configured for the non-standardized indirect path.
  • the first message is an RRC signalling.
  • the network device 110 may indicate whether the SRAP entity is configured in either an explicitly manner or an implicitly manner.
  • the first message comprises a third indication indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • the network device 110 may transmit a RRC reconfiguration without including any SRAP information to imply the first terminal device 120-1 not to configure the SRAP entity.
  • the first terminal device 120-1 receives an RRC signalling used for adding/configuring the indirect path, where the RRC signalling does not include the IE of sl-SRAP-config.
  • the network device 110 also may transmit 320 a second message to the second terminal device 120-2, where the second message may indicate whether the SRAP entity is configured for the non-standardized indirect path.
  • the second message is an RRC signalling.
  • the second message may comprise a fourth indication indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • the network device 110 may transmit a RRC reconfiguration without including any SRAP information to imply the second terminal device 120-2 not to configure the SRAP entity (in an implicitly manner) .
  • the second terminal device 120-2 is that the RRC signalling, for adding/configuring the indirect path to the first terminal device 120-1, does not including the IE sl-SRAP-config.
  • either the first terminal device 120-1 or the first terminal device 120-1 may report its capability of SRAP to the network device 110.
  • the first terminal device 120-1 may transmit 305 its capability-related information indicating whether an SRAP entity can be supported by the first terminal device 120-1 to the network device 110.
  • the second terminal device 120-2 also may transmit 315 its capability-related information indicating whether an SRAP entity can be supported by the second terminal device 120-2 to the network device 110.
  • the capability-related information transmitted by the first terminal device 120-1 may comprise an indication indicating whether support to relay without SRAP on UE-UE hop.
  • the capability-related information transmitted by the second terminal device 120-2 may comprise an indication indicating whether support to relay without SRAP on UE-UE hop or Uu hop, or on both hops.
  • the relation between the first terminal device 120-1 and the second terminal device 120-2 involved in a non-standardized indirect path may be pre-configured or static.
  • the mapping between the first terminal device 120-1 and the second terminal device 120-2 is a 1: 1 mapping.
  • the network device also may indicate the relation to the terminal devices 120 via such as an RRC signalling, a system message.
  • one terminal device of the terminal devices 120 can get the relation from another terminal device of the terminal devices 120 via such as a broadcast message.
  • a relation between an indirect path and at least one RB also may be configured by the network device 110.
  • the network device 110 also may configure the above relation (s) and indicate the above relation (s) to the terminal devices 120.
  • the first terminal device 120-1 generates a first packet associated with a layer 2 PDU (such as, a PDCP PDU, an SRAP PDU, an RLC PDU, a MAC PDU) .
  • the first packet indicates first information (also referred to as bearer mapping information in the following sometimes) indicating at least one of the following: an RB identity (ID) of a first RB, an ID of the first terminal device 120-1, or a first indication indicating a type of the first RB, where the first RB corresponds to the first packet.
  • the first terminal device 120-1 transmits 325 the first packet to the second terminal device 120-2 via the non-standardized indirect path (i.e., the UE-UE hop) .
  • the RB ID may refer to/indicate both a bearer type and bearer index.
  • each RB ID value corresponds to a combination of bearer type and bearer index.
  • an RB ID value corresponds an SRB/DRB type and a bearer index (such as, SRB1/SRB2/SRB3/DRB0/DRB1 and so on) .
  • the SRAP entity is not configured for the non-standardized indirect path.
  • a PDCP entity of the first terminal device 120-1 transmits the first packet to a non-standardized entity (also referred to as non-3GPP entity or lower entity) of the first terminal device 120-1 directly, and the non-standardized entity transmits the first packet to the second terminal device 120-2.
  • the SRAP entity is configured for the non-standardized indirect path.
  • the PDCP entity of the first terminal device 120-1 transmits the first packet to the non-standardized entity via the SRAP entity corresponding to the non-standardized path.
  • the SRAP entity is configured for the non-standardized indirect path.
  • the SRAP entity may generates the first packet, and the first information may be determined by either the PDCP entity or the SRAP entity. Then the SRAP entity transmits the first packet to the non-standardized entity.
  • At least part of the first information is determined by the PDCP entity of the first terminal device 120-1 or the SRAP entity of the first terminal device 120-1.
  • the second terminal device 120-2 may obtain the bearer mapping information. With the bearer mapping information, the second terminal device 120-2 may map the first packet to an RLC channel on Uu hop. Thus, the transmission from the first terminal device 120-1 to the network device 110 on the non-standardized indirect path is achieved.
  • a mapping between the first terminal device 120-1 and the second terminal device 120-2 is pre-configured.
  • the mapping between the first terminal device 120-1 and the second terminal device 120-2 is a 1: 1 mapping.
  • the ID of the first terminal device 120-1 may be not indicated by the first information.
  • a mapping between an RB type and the non-standardized indirect path is pre-configured.
  • the non-standardized indirect path is configured only for SRB or DRB.
  • the first indication may be not indicated by the first information.
  • a mapping between at least one RB and the non-standardized indirect path is pre-configured.
  • SRB #1/DRB #2 is mapped to the non-standardized indirect path.
  • the first RB ID may be not indicated by the first information.
  • one or more SRBs are configured for the non-standardized indirect path, and one or more DRBs are configured for the non-standardized indirect path, where the one or more SRBs are indexed with one or more first indexes and the one or more DRBs are indexed with one or more second indexes. The one or more first indexes and the one or more second indexes are different.
  • At least part of the first information is indicated jointly.
  • At least part of the first information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the first information is independent from the PDCP PDU or the SRAP PDU. In this way, the first formation may be indicated flexibly.
  • the second terminal device 120-2 may generates a second packet based on the first packet and transmits 330 the second packet to a network device 110.
  • a non-standardized entity of the second terminal device 120-2 receives the first packet from the first terminal device 120-1.
  • the second terminal device 120-2 (for example, the SRAP entity of the Uu hop for second terminal device 120-2) generates a SRAP PDU as the second packet based on the first information indicated in the first packet, where the SRAP PDU comprises the first RB ID, and the ID of the first terminal device 120-1.
  • the second terminal device 120-2 forwards the received first packet to the SRAP entity for Uu hop.
  • the second terminal device 120-2 generates the SRAP PDU by encapsulating the received first packet (such as, PDCP PDU) to be an Uu SRAP PDU.
  • the second terminal device 120-2 generates the SRAP PDU by extracting a PDCP PDU from the received first packet (such as, SRAP PDU) and then encapsulating the extracted PDCP PDU to be an Uu SRAP PDU.
  • the second packet further comprises the first indication indicating the type of the first RB.
  • the network device 110 may consider or ignore the first indication because the network device 110 may determine the type of the first RB by other manner.
  • the second terminal device 120-2 when transmitting the second packet to the network device 110, determines an RLC channel to be used for transmitting the second packet based on at least one of the following: the first RB ID, the ID of the first terminal device 120-1, or the first indication indicating the type of the first RB.
  • the second terminal device 120-2 also may relay a packet from the network device 110 to the first terminal device 120-1 as discussed below.
  • the second terminal device 120-2 receives 335 a fourth packet from the network device 110.
  • the second terminal device 120-2 generates a third packet associated with a layer 2 PDU (such as, a PDCP PDU, an SRAP PDU, an RLC PDU, a MAC PDU) .
  • the third packet indicates second information (also referred to as bearer mapping information) indicating at least one of the following: an RB ID of a second RB, an ID of the first terminal device 120-1, or a third indication indicating a type of the second RB, where the second RB corresponding to the fourth packet.
  • the second terminal device 120-2 transmits 340 the third packet to the first terminal device 120-1 via the non-standardized indirect path (i.e., UE-UE hop) .
  • the SRAP entity is not configured for the UE-UE hop of the non-standardized indirect path at the second terminal device 120-2.
  • the second terminal device 120-2 (for example, a SRAP entity for the Uu hop of the second terminal device 120-2) transmits the third packet to a non-standardized entity of the second terminal device 120-2 directly, and the non-standardized entity transmits the third packet to the first terminal device 120-1 (such as, the non-standardized entity of the first terminal device 120-1) .
  • the SRAP entity is configured for the UE-UE hop of the non-standardized indirect path at the second terminal device 120-2.
  • the second terminal device 120-2 transmits the third packet to the non-standardized entity via the SRAP entity corresponding to the non-standardized path.
  • At least part of the second information is determined by the PDCP entity or the SRAP entity of the second terminal device 120-2.
  • the SRAP entity is configured for the UE-UE hop of the non-standardized indirect path.
  • the SRAP entity may generates the third packet, and the second information may be determined by either the PDCP entity or the SRAP entity. Then the SRAP entity transmits the first packet to the non-standardized entity.
  • the SRAP entity is configured for the UE-UE hop of the non-standardized indirect path.
  • the SRAP entity configured for the Uu hop may generates the third packet, and the second information may be determined by either the PDCP entity or the SRAP entity configured for the Uu hop. Then the SRAP entity configured for the Uu hop transmits the third packet to the SRAP entity configured for the UE-UE hop, and the SRAP entity configured for the UE-UE hop transmits the third packet to the non-standardized entity.
  • mapping (s) between the first terminal device 120-1 and the second terminal device 120-2 an RB type and a non-standardized indirect path, or an RB and a non-standardized indirect path may be pre-configured. Thus, the corresponding information may be not indicated by the second information.
  • At least part of the second information is indicated jointly.
  • At least part of the second information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the second information is independent from the PDCP PDU or the SRAP PDU. In this way, the second formation may be indicated flexibly.
  • the transmitting terminal device transmits a packet and its bearer mapping information (including the bearer ID and the ID of the terminal device 120) to the lower entity/layer (i.e., a non-standardized entity/layer, or a non-3GPP entity/layer) .
  • the lower entity/layer i.e., a non-standardized entity/layer, or a non-3GPP entity/layer
  • bearer mapping information including both bearer ID (i.e., RB ID) and ID of the terminal device 120 may be transmitted together with the PDCP PDU to the non-standardized entity/layer.
  • the PDCP PDU and the bearer mapping information may be transparent to the non-standardized entity/layer.
  • the PDCP entity of the first terminal device 120-1 forwards PDCP PDU and its related bearer mapping information to the non-standardized entity/layer (i.e., non-3GPP entity/layer) .
  • the second terminal device 120-2 receives the PDCP PDU and its related bearer mapping information from the non-standardized entity/layer (i.e., non-3GPP layer) .
  • the second terminal device 120-2 forms an SRAU PDU, and sets the header of the SRAP PDU according to the bearer mapping information.
  • the second terminal device 120-2 determines the egress link and egress Uu RLC channel.
  • the first terminal device 120-1 when there is a 1: 1 mapping of the first terminal device 120-1 and the second terminal device 120-2, the first terminal device 120-1 only forwards PDCP PDU and bearer ID. Then, the second terminal device 120-2 determines the ID of the first terminal device 120-1 to identify the first terminal device 120-1 according to the 1: 1 mapping.
  • a non-standardized entity of the second terminal device 120-2 provides the ID of the first terminal device 120-1 to identify the first terminal device 120-1 according to the 1: 1 mapping.
  • a entity of the second terminal device 120-2 (for example, the SRAP entity) determines the ID of the first terminal device 120-1 to identify the first terminal device 120-1 according to the 1: 1 mapping.
  • the bearer mapping information when there is a predefined mapping of RB and the indirect path and/or a predefined mapping of RB type and the indirect path, the bearer mapping information also may not indicate RB type. Accordingly, such information may be determined by the non-standardized entity based on the predefined mapping (s) . For example, the upper entity of the second terminal device 120-2 may use this information to determine proper egress RLC channel and forwarding layer 2 PDU (such as PDCP PDU or SRAP PDU) to the network device.
  • PDU such as PDCP PDU or SRAP PDU
  • the upper entity also may determine such information based on the predefined mapping (s) .
  • the upper entity of the second terminal device 120-2 may use this information to determine proper egress Uu RLC channel and forward layer 2 PDU (such as PDCP PDU or SRAP PDU) to the network device.
  • layer 2 PDU such as PDCP PDU or SRAP PDU
  • Below table 1 illustrates examples of input/output for the terminal devices 120 and the network device 110.
  • the second terminal device 120-2 receives an SRAP PDU from the network device 110 and derives SRAP SDU (i.e., PDCP PDU) and its related bearer mapping information from the header of the SRAP PDU. Then, the second terminal device 120-2 (such as, the SRAP entity) forwards PDCP PDU and its related bearer mapping information to the non-standardized entity/layer (i.e., non-3GPP layer) . The non-standardized entity/layer of the second terminal 120-2 transmits the PDCP PDU and its related bearer mapping information to the non-standardized entity/layer (i.e., non-3GPP layer) of the first terminal device 120-1.
  • SRAP SDU i.e., PDCP PDU
  • the second terminal device 120-2 forwards PDCP PDU and its related bearer mapping information to the non-standardized entity/layer (i.e., non-3GPP layer) .
  • the first terminal device 120-1 receives the PDCP PDU and its related bearer mapping information from the non-standardized entity/layer.
  • the non-standardized entity/layer of the first terminal device 120-1 may only forward bearer ID to the PDCP layer.
  • the second terminal device 120-2 only forwards PDCP PDU and bearer ID to the non-standardized entity/layer.
  • both SRB and DRB may be configured for the non-standardized indirect path.
  • the bearer mapping information includes at least one of bearer ID, ID of the terminal device and an indication indicating the RB type may be transmitted together with the bearer mapping information.
  • the SRAP entity transmits bearer ID, the ID of the terminal device 120 and an indication indicating the RB type along with PDCP PDU to the non-standardized entity/layer (i.e., non-3GPP) .
  • the indication indicating the RB type may be a 1-bit indication, where value ‘0’ indicates DRB, value ‘1’ indicates SRB, or value ‘0’ indicates SRB, value ‘1’ indicates DRB.
  • the first terminal device 120-1 (such as, SRAP entity) determines the indication indicating the RB type based on the ID of the first terminal device 120-1, bearer ID and the type of radio bearer (DRB or SRB) . Then, the first terminal device 120-1 (such as, PDCP entity/layer) forwards PDCP PDU, its related bearer mapping information and the indication indicating the RB type to lower layer (i.e. non-3GPP layer) .
  • SRAP entity determines the indication indicating the RB type based on the ID of the first terminal device 120-1, bearer ID and the type of radio bearer (DRB or SRB) . Then, the first terminal device 120-1 (such as, PDCP entity/layer) forwards PDCP PDU, its related bearer mapping information and the indication indicating the RB type to lower layer (i.e. non-3GPP layer) .
  • the second terminal device 120-2 receives PDCP PDU, its related bearer mapping information and the indication indicating the RB type from the non-standardized entity/layer (i.e., non-3GPP layer) . Then the second terminal device 120-2 forms SRAU PDU, sets the header of SRAP PDU according to the bearer mapping information.
  • the second terminal device 120-2 determines egress link and egress Uu RLC channel based one bearer mapping information and the indication indicating the RB type. In some embodiments, the second terminal device 120-2 determines egress Uu RLC channel based on the ID of the first terminal device 120-1, the bearer ID and the indication indicating the RB type.
  • the second terminal device 120-2 receives SRAP PDU and derives SRAP SDU (i.e., PDCP PDU) and its related bearer mapping information from the header of SRAP PDU. Then, the second terminal device 120-2 determines the indication indicating the RB type based on at least one of SRAP configuration, bearer mapping information/the header of SRAP PDU and the RLC channel receiving the SRAP PDU. Then the second terminal device 120-2 (such as, SRAP entity) forwards PDCP PDU, its related bearer mapping information and the indication indicating the RB type to lower layer.
  • SRAP SDU i.e., PDCP PDU
  • the second terminal device 120-2 determines the indication indicating the RB type based on at least one of SRAP configuration, bearer mapping information/the header of SRAP PDU and the RLC channel receiving the SRAP PDU. Then the second terminal device 120-2 (such as, SRAP entity) forwards PDCP PDU, its related bearer
  • the first terminal device 120-1 receives PDCP PDU and its related bearer mapping information from the non-standardized entity/layer (i.e., non-3GPP layer) .
  • the first terminal device 120-1 only receives the PDCP PDU and RB ID from the non-standardized entity/layer (i.e., non-3GPP layer) .
  • part of the bear mapping information and the indication indicating the RB type may be indicated jointly.
  • a joint index may be used for indicating at least one of bearer ID, ID of the first terminal device 120-1 (and/or the second terminal device 120-2) and the indication indicating the RB type .
  • the correspondence between the joint index and the bearer ID, ID of the first terminal device 120-1 (and/or the second terminal device 120-2) and the indication indicating the RB type may be configured by the network device 110, or determined by the inter-working of the second terminal device 120-2 and first terminal device 120-1.
  • the joint index is configured with values from 0 ⁇ N or 1 ⁇ N. Further, there is a 1: 1 mapping of joint index to a combination of bearer ID, ID of the terminal device 120 and the indication indicating the RB type.
  • the correspondence may be represented as a table.
  • table 5 illustrates examples of the correspondence.
  • the second terminal device 120-2 may be aware of the full table of the joint index and its related bearer ID, the ID of the terminal devices 120 and the indication indicating the RB type, while the first terminal device 120-1 may be aware of part of the table.
  • both the first terminal device 120-1 and the second terminal device 120-2 may be aware of the full table of the joint index and its related bearer ID, the ID of the terminal device 120-1 and the indication indicating the RB type.
  • the joint index may comprise: X bits to indicate the first terminal device 120-1/the second terminal device 120-2, Y bits to indicate bearer ID, Z bits to indicate the indication indicating the RB type.
  • X, Y and Z are configured as below:
  • X 8 bits, local UE ID, or X ⁇ 8 (in case that the number of remote terminal devices configured to the relay terminal device is less than 2 8 ) , or specially, the Z bits can be omitted if a 1: 1 mapping of the first terminal device 120-1 and the second terminal device 120-2 is configured;
  • Y 5 bits, for 32 DRBs and 3 SRBs, or Y ⁇ 5 (in case that the number of DRBs configured to the terminal device is less than 32) , or specially, the Y bits can be omitted if only one RB is configured;
  • Z 1 bit, to indicate SRB or DRB, or specially, the Z bits can be omitted if only one RB is configured.
  • the first terminal device 120-1 (such as, SRAP entity) determines the joint index based on the ID of the first terminal device 120-1, bearer ID and the indication indicating the type of RB (DRB or SRB) . Then, the first terminal device 120-1 (such as, PDCP entity/layer) forwards PDCP PDU and it related joint index to the non-standardized entity/layer (i.e., non-3GPP entity) .
  • the non-standardized entity/layer i.e., non-3GPP entity
  • the second terminal device 120-2 receives the PDCP PDU, its related joint index from the non-standardized entity/layer (i.e., non-3GPP layer) . Then the second terminal device 120-2 determines the ID of the first terminal device 120-1, bearer ID and the type of RB based on the joint index.
  • the second terminal device 120-2 forms SRAU PDU, sets the header of SRAP PDU according to the bearer mapping information. Then, the second terminal device 120-2 determines egress link and egress Uu RLC channel based one the bearer mapping information and the indication indicating the RB type. In some embodiments, the second terminal device 120-2 determines egress Uu RLC channel based on the first terminal device 120-1ID, bearer ID and the indication indicating the RB type.
  • the second terminal device 120-2 receives an SRAP PDU from the network device 110 and derives an SRAP SDU (i.e., PDCP PDU) and its related bearer mapping information from the header of SRAP PDU. Then, the second terminal device 120-2 determines the indication indicating the RB type based on at least one of the Uu RLC channel receiving the SRAP PDU, SRAP configuration and bearer mapping information/the header of SRAP PDU.
  • SRAP SDU i.e., PDCP PDU
  • the second terminal device 120-2 determines the indication indicating the RB type based on at least one of the Uu RLC channel receiving the SRAP PDU, SRAP configuration and bearer mapping information/the header of SRAP PDU.
  • the second terminal device 120-2 determines the joint index based on at least one of the ID of the first terminal device 120-1, Bearer ID and the indication indicating the RB type. After that, the second terminal device 120-2 (such as, SRAP entity) forwards the PDCP PDU, its related joint index to lower layer.
  • the first terminal device 120-1 (such as, PDCP entity/layer) receives PDCP PDU and its related joint index from the non-standardized entity/layer.
  • the SRAP PDU may comprises a 1-bit indication indicating the type of RB.
  • the reserved bit in the SRAP PDU header may be used as the 1-bit indication to indicate the type of RB.
  • the other bits in the SRAP PDU header also may be used as the 1-bit indication.
  • the 1-bit indication may be named as S/D indication, where value ‘0’ indicates DRB, value ‘1’ indicates SRB, or value ‘0’ indicates SRB, value ‘1’ indicates DRB.
  • the 1-bit indication may be used when the SRAP PDU is transmitted over both the UE-UE hop and the Uu hop. Alternatively, in some embodiments, the 1-bit indication may be used only when the SRAP PDU is transmitted over the UE-UE hop.
  • the first terminal device 120-1 determines the indication indicating the RB type based on the ID of the first terminal device 120-1, bearer ID and the type of RB (DRB or SRB) .
  • the first terminal device 120-1 (such as, SRAP entity) forms a UE-UE SRAP PDU and forwards this SRAP to the non-standardized entity/layer.
  • the second terminal device 120-2 (such as, SRAP entity) receives SRAP PDU from the non-standardized entity/layer.
  • the second terminal device 120-2 forms Uu SRAU PDU, sets the header of Uu SRAP PDU according to the header of SRAP PDU.
  • the second terminal device 120-2 determines egress link and egress Uu RLC channel based on the information in the header of SRAP PDU (i.e. ID of the first terminal device 120-1, bearer ID ) and the indication indicating the RB type.
  • the second terminal device 120-2 determines the egress Uu RLC channel based on the ID the first terminal device 120-1, bearer ID and the indication indicating the RB type.
  • Below table 8 illustrates examples of input/output for the terminal devices 120 and the network device 110.
  • the second terminal device 120-2 receives Uu SRAP PDU. If the S/D indication is not set by the network device 110 or not introduced, the second terminal device 120-2 determines the indication indicating the RB type based on (optionally) the information in the header of Uu SRAP PDU (i.e., bearer ID ) , Uu bearer mapping information configured by the network device 110 and the Uu RLC channel transmitting this Uu SRAP PDU. Then the second terminal device 120-2 (such as, SRAP entity) forms UE-UE SRAP PDU and forwards it to the non-standardized entity/layer.
  • the second terminal device 120-2 (such as, SRAP entity) receives Uu SRAP PDU. If the S/D indication is not set by the network device 110 or not introduced, the second terminal device 120-2 determines the indication indicating the RB type based on (optionally) the information in the header of Uu SRAP PDU (i.e., bearer ID ) , Uu bearer mapping information configured
  • the first terminal device 120-1 receives the SRAP PDU from the non-standardized entity/layer.
  • the first terminal device 120-1 derives PDCP PDU and forwards it to a proper PDCP entity base on the bearer ID and the indication indicating the RB type in the header of UE-UE SRAP PDU.
  • the first terminal device 120-1 determines the indication indicating the RB type based on the ID of the first terminal device 120-1, bearer ID and the type of radio bearer (DRB or SRB) . Then, the first terminal device 120-1 (such as, SRAP entity) forwards SRAP PDU and its related the indication indicating the RB type to the non-standardized entity/layer.
  • the second terminal device 120-2 receives SRAP PDU and its related the indication indicating the RB type from the non-standardized entity/layer. Then the second terminal device 120-2 forms Uu SRAU PDU, sets the header of Uu SRAP PDU according to the header of SRAP PDU. The second terminal device 120-2 determines egress link and egress Uu RLC channel based on the information in the header of SRAP PDU (i.e., the ID of the first terminal device 120-1, bearer ID ) and the indication indicating the RB type.
  • the second terminal device 120-2 determines egress Uu RLC channel based on the ID of the first terminal device 120-1, bearer ID and the indication indicating the RB type.
  • Below table 10 illustrates examples of input/output for the terminal devices 120 and the network device 110.
  • the second terminal device 120-2 receives Uu SRAP PDU from the network device 110 and derives SRAP SDU (i.e., PDCP PDU) and its related bearer mapping information from the header of Uu SRAP PDU. Then, the second terminal device 120-2 determines the indication indicating the RB type based on the Uu RLC channel sending the SRAP PDU, the information in the header SRAP PDU (i.e. ID of the first terminal device 120-1, bearer ID) and SRAP (such as bearer mapping information configured by the network device 110. Then the second terminal device 120-2 (such as, SRAP entity) forms SRAP PDU and forwards the SRAP PDU and its related indication indicating the RB type to non-standardized entity/layer.
  • SRAP SDU i.e., PDCP PDU
  • SRAP SDU i.e., PDCP PDU
  • bearer mapping information i.e. ID of the first terminal device 120-1, bearer ID
  • the first terminal device 120-1 receives the SRAP PDU and its related the indication indicating the RB type from non-standardized entity/layer.
  • the first terminal device 120-1 derives PDCP PDU and forwards it to proper PDCP entity base on the bearer ID and the indication indicating the RB type.
  • Below table 11 illustrates examples of input/output for the terminal devices 120 and the network device 110.
  • the layer 2 PDU (including PDCP PDU, SRAP PDU, RLC PDU, MAC PDU) may be exchanged among the first terminal device 120-1, the second terminal device 120-2 and the network device 110.
  • the non-standardized entity may report the status information about the non-standardized indirect path to the upper layer (such as, RRC layer, PDCP layer or SRAP layer) .
  • the upper layer such as, RRC layer, PDCP layer or SRAP layer
  • the QoS information about the non-standardized indirect path also may be indicated by the status information.
  • the reporting procedure may be configured/indicated.
  • the non-standardized indirect path may refer to any of the following: a path between the first terminal device 120-1 and the second terminal device 120-2, a path between the first terminal device 120-1 and the network device 110, and a path between the second terminal device 120-2 and the network device 110.
  • a non-standardized entity of the terminal device 120 determines status-related information of the non-standardized indirect path.
  • the non-standardized entity transmits a fifth indication indicating the status of the non-standardized indirect path to one of the following: an RRC entity, a PDCP entity, or an SRAP entity.
  • the upper layer may obtain the status of the non-standardized indirect path.
  • the status information may be reported in different granularities, such as, an RB, an RB group, an indirect path, an RB type and so on.
  • the status-related information is specific to the non-standardized indirect path.
  • the status-related information is specific to at least one service access point (SAP) .
  • SAP service access point
  • the status-related information is specific to at least one RB.
  • the status-related information is specific to an RB type.
  • the status-related information is specific to at least one non-standardized resource.
  • the status-related information of the non-standardized indirect path indicates one of the following:
  • the status-related information also may indicate QoS-related information of the non-standardized indirect path.
  • the status-related information may indicate at least one of the following:
  • At least one 5G QoS identifier (5QI) is at least one 5G QoS identifier (5QI) .
  • the related parameter/resource may be not identifiable for the upper entity.
  • the mapping between the non-standardized parameter (s) and standardized parameter (s) is needed.
  • the non-standardized entity transforms the at least one non-standardized parameter into at least one standardized parameter being identifiable to one of the RRC entity, the PDCP entity or the SRAP entity. Then, the non-standardized entity generates the fifth indication by including the at least one standardized parameter.
  • the correspondence between the at least one non-standardized parameter and the least one standardized parameter is configured by the network device 110 by using a first configuration.
  • the transmission of the fifth indication may be triggered by some pre-defined events.
  • the non-standardized entity determines the status of the non-standardized indirect path in response to receiving a sixth indication from one of the RRC entity, the PDCP entity or the SRAP entity (as shown in FIG. 5) , where the sixth indication is used for requesting the non-standardized indirect entity to establish the non-standardized indirect path or report the status-related information.
  • the sixth indication is transmitted by one of the RRC entity, the PDCP entity or the SRAP entity in response to receiving an RRC signalling from the network device 110.
  • the sixth indication is specific to one of the following: the non-standardized indirect path, at least one RB, an RB type, at least one SAP, or at least one non-standardized resource.
  • the non-standardized entity determines the status of the non-standardized indirect path in response to receiving a packet from one of the RRC entity, the PDCP entity or the SRAP entity (as shown in FIG. 5) .
  • the packet is transmitted to a specific resource via an SAP corresponding to the specific resource.
  • the packet is transmitted together with a resource-related indication, where resource-related indication may indicate at least one RB ID, or at least one non-standardized resource ID.
  • either of the sixth indication or the packet may indicate QoS-related requirement for the non-standardized indirect path.
  • the QoS-related requirement is specific to one of the following: the non-standardized indirect path, at least one RB, an RB type, at least one SAP, or at least one non-standardized resource.
  • the QoS-related requirement for the non-standardized indirect path may be indicated by the network device 110 by using a second configuration.
  • the upper entity such as, the RRC/PDCP/SRAP entity
  • the lower entity i.e., the non-standardized entity
  • the entity layer may be aware of the lower entity (i.e., the non-standardized entity) is ready for sending packets of DRB and SRB.
  • some inter-layer procedures are introduced to check the availability of non-standardized layer. In this way, the packets of DRB and SRB may be transmitted via the indirect path with non-standardized lower layer more reliable.
  • the non-standardized layer is prepared/pre-configured before receiving RRC configuration of the indirect path, and does not check the availability of non-standardized layer.
  • the PDCP/RRC/SRAP entity forwards the data to the non-standardized entity directly.
  • the relation between the first terminal device 120-1 and the second terminal device 120-2 in scenario #2 is pre-configured or static.
  • the non-standardized layer is pre-configured. Then, the fifth indication indicating the status of the non-standardized indirect path is received from the non-standardized entity (as shown in FIG. 5) . After that, the packet of PDCP layer or SRAP layer may be sent to the non-standardized entity. In some embodiments, the pre-configuration procedure is performed before receiving RRC configuration of the indirect path.
  • the fifth indication indicates that the non-standardized indirect path is established (for example, a non-standardized path to the second terminal device 120-2 is established) .
  • the fifth indication indicates that the non-standardized indirect path is established for a specific non-standardized path/to specific the second terminal device 120-2 (for example, in case that the first terminal device connects with more than one second terminal device 120-2) .
  • the fifth indication may not include the ID of the second terminal device 120-2.
  • the ID of the second terminal device 120-2 is needed to identify the second terminal device 120-2/non-standardized path by the first terminal device 120-1 (such as, an RRC layer) .
  • the non-standardized layer indicates the ID of the second terminal device 120-2 to the upper layer.
  • the non-standardized layer of the first terminal device 120-1 may be pre-configured with the mapping of layer 2 ID of the second terminal device 120-2 and the non-standardized ID of the second terminal device 120-2/an index of non-standardized resource (such as, non-3GPP resource) .
  • the non-standardized layer indicates non-standardized ID of the second terminal device 120-2/an index of non-standardized resource (such as, non-3GPP resource) .
  • the upper layer may be pre-configured the mapping layer 2 ID of the second terminal device 120-2 and the non-standardized ID of the second terminal device 120-2/an index of non-standardized resource (such as, non-3GPP resource) .
  • the first terminal device 120-1 may be pre-configured by the network device 110 with the mapping of L2 source the second terminal device 120-2 ID and the non-3GPP ID of the second terminal device 120-2 /index of non-3GPP link.
  • the first terminal device 120-1 may be notified by its lower layer with the mapping of L2 source the second terminal device 120-2 ID and the non-3GPP ID of the second terminal device 120-2 /index of non-3GPP link.
  • the fifth indication may also indicate that the non-standardized path is not established, released, suffering link failure, or paused.
  • the sixth indication may be transmitted to the non-standardized entity, where the sixth indication may be used for triggering the non-standardized entity to establish the non-standardized path.
  • the non-standardized layer is pre-configured.
  • the fifth indication from non-standardized layer may indicate: the lower layer (channel/resource) has been prepared to meet specific QoS requirements.
  • the fifth indication comprises a list of 5QI.
  • the fifth indication comprises a list QoS ID of non-3GPP.
  • the fifth indication comprises a mapping of 5QI and QoS ID of non-3GPP or related QoS parameters of each QoS ID of non-3GPP.
  • the network device 110 may send QoS requirements for DRBs to the core network device to enable the pre-configuration., where the QoS requirements will be configured to the first terminal device 120-1 or a pair of the first terminal device 120-1 and the second terminal device 120-2.
  • QoS requirements may be configured specifically to a specific indirect path (by using common QoS requirements) or a specific RB (such as, by using RB ID and respective QoS requirement) .
  • the fifth indication from the non-standardized may indicate that the lower layer channel/resource is prepared for a specific RB.
  • the fifth indication may indicate at least one of the following:
  • Option 1 a list of ID for non-3GPP resource
  • option 2 at least one mapping of DRB ID and ID for non-3GPP resource
  • option 3 at least one related QoS parameter of each non-3GPP resource
  • SAP for non-3GPP resource
  • SAP may be LCH or RLC channel
  • option 1 at least one mapping of DRB ID and SAP for non-3GPP resource
  • option 2 at least one related QoS parameter of each SAP of non-3GPP resource.
  • the network device 110 may send a list of RBs and their related QoS requirements to the core network device to enable the pre-configuration, the related QoS requirements will be configured for the first terminal device 120-1 or a pair of the first terminal device 120-1 and the second terminal device 120-2.
  • the six indication i.e., an inter-layer signalling
  • the non-standardized entity after receiving the RRC configuration of the indirect path or when an application/upper layer data is waiting for transmission, the six indication (i.e., an inter-layer signalling) is send to the non-standardized entity to trigger the checking of the availability of non-standardized path.
  • the sixth indication is sent only when the lower layer is non-standardized. Further, the non-standardized entity may send an indication to trigger the sixth indication.
  • the sixth indication may include: an indication to request connection establishment of non-standardized path, without being specific to the second terminal device 120-2 ID/an index of non-standardized path. Additionally, the sixth indication also may indicate the pre-configuration of QoS information.
  • the sixth indication may include: an indication of the ID of the second terminal device 120-2/an index of non-3GPP path. Additionally, the sixth indication also may indicate the pre-configuration of QoS information.
  • specific QoS information (such as, QoS requirement for each newly added DRB or QoS flow) may be configured by the RRC reconfiguration message.
  • the QoS requirements may be at least one of 5QI, specific QoS parameters, QoS index defined by non-3GPP.
  • the non-standardized layer may provide 5QI to non-3GPP QoS index mapping information, and QoS parameters of each non-3GPP QoS index.
  • the first terminal device 120-1 e.g. PDCP, SRAP, RRC
  • the specific RB information includes at least one of bearer ID, QoS requirements for each RB. Additionally, in some embodiments, the QoS requirements may be at least one of 5QI, specific QoS parameters, or QoS index defined by non-3GPP.
  • the first terminal device 120-1 (such as, an RRC layer) sends the sixth indication to trigger the checking of the non-standardized connection.
  • the sixth indication is transmitted from the lower layer to indicate at least one of the following:
  • the connection is established.
  • the lower layer channel/resource is prepared to meet specific QoS requirement.
  • option 1 a list of 5QI
  • option 2 a list QoS ID of non-3GPP
  • option 2.1 at least one mapping of 5QI and QoS ID of non-3GPP,
  • option 2.2 at least one related QoS parameter of each QoS ID of non-3GPP,
  • the lower layer channel/resources are prepared for specific Radio Bearer.
  • option 1 a list of DRBs
  • option 2 a list of ID for non-3GPP resource
  • option 2.1 at least one mapping of DRB ID and ID for non-3GPP resource,
  • option 2.1 at least one related QoS parameter of each non-3GPP resource,
  • option 3 a list of SAP for non-3GPP resources
  • option 3.1 at least one mapping of DRB ID and SAP for non-3GPP resource
  • option 3.2 at least one related QoS parameter of each SAP of non-3GPP resource.
  • the packet after receiving RRC configuration of the indirect path, when packed arrives, the packet is sent to non-standardized layer to trigger the checking of the availability of non-standardized path.
  • a packet is sent to trigger the establishment of the non-standardized indirect path. In some embodiments, a packet is sent at the PDCP layer (if SRAP layer is not used over UE-UE hop) or SRAP layer to the non-standardized layer.
  • the packet may be PDCP PDU for SRB (such as, SRB via indirect path, or feedback of RRC reconfiguration message for indirect path) .
  • the packet may be PDCP PDU for DRB (such as, service data received from upper layer) .
  • the packet may be SRAP PDU.
  • the QoS requirement of DRB may be sent together with the packet to the lower layer.
  • the lower layer may provide feedback indicate at least one of the following:
  • the packet is transmitted or transmitted successfully.
  • the connection is established.
  • the lower layer channel/resource is prepared to meet specific QoS requirement.
  • the lower layer channel/resource is prepared for specific RB.
  • the RRC/PDCP/SRAP layer may provide the QoS requirement to the lower layer via signalling.
  • the RRC/PDCP/SRAP layer may send packets only, or send QoS requirement along with each packet.
  • the RRC/PDCP/SRAP layer may perform lower layer resource mapping based on a QoS capability of the lower layer.
  • the non-standardized layer may enable to meet the QoS requirement of each packet/DRB/Uu bearer. How to configure the QoS requirement has been fully discussed above. Merely for brevity, same contents are omitted here.
  • the QoS requirement is indicated by sending QoS requirement along with each packet or based on QoS capability of lower layer.
  • the PDCP/SRAP layer may be not aware of how the lower layer meet the QoS requirement of each packet. Specifically, the PDCP/SRAP layer sends PDCP PDU (if SRAP layer is not used via UE-UE hop) or SRAP PDU (if SRAP layer is used via UE-UE hop) directly.
  • the lower layer may be aware of the QoS requirements of each packet by pre-configuration. Alternatively, default QoS parameters are defined previously.
  • the PDCP/SRAP layer sends packet with QoS information to the lower layer, and the format of QoS information includes:
  • Lower layer is per-configured or informed by the upper layer (e.g. RRC, PDCP, SRAP layer) of 5QI and its related parameters.
  • RRC Radio Resource Control
  • PDCP Packet Control Function
  • SRAP layer Radio Access Management Function
  • the upper layer is informed with the mapping info between the QoS joint index of non-3GPP layer and 5QI:
  • the upper layer chose the QoS joint index of non-3GPP layer according to 5QI DRB that the packet belongs to.
  • the core network Informed by gNB, the core network; interwork with the lower layer to determine the mapping table.
  • the upper layer is informed with the QoS joint index of non-3GPP lower layer and its related non-3GPP QoS parameters:
  • the upper layer determines QoS index of non-3GPP according to the QoS index related QoS parameter and 5QI of DRB that the packet belongs to.
  • the PDCP/SRAP layer sends packet with QoS information to lower layer, and the format of QoS information includes:
  • the upper layer is informed with the mapping info between QoS index of non-3GPP layer and DRB (ID) :
  • the upper layer chose the QoS index of non-3GPP according to DRB ID.
  • the lower layer determines a proper resource based on the QoS index of non-3GPP layer
  • the upper layer determines QoS parameters of non-3GPP according to QoS requirement of DRB that the packet belongs to.
  • the lower layer determines a proper resource based on the QoS parameters of non-3GPP layer.
  • the non-standardized layer enables to meet the QoS requirement of each packet.
  • the PDCP/SRAP entity maps packet of each DRB to lower layer resource/channel/tunnel.
  • the PDCP/SRAP entity sends the packet with an index of the lower layer resource (i.e. the index of non-standardized resource) . Additionally, the PDCP/SRAP entity is informed with the mapping info between resource index of non-standardized layer and DRB ID. Thus, when sending data to the non-standardized layer, the PDCP/SRAP entity chose resource index of non-standardized according to DRB ID.
  • the PDCP/SRAP entity is informed with the resource joint index of the non-standardized layer and its related QoS parameters.
  • the PDCP/SRAP entity determines the resource index of non-standardized layer according to the resource index related QoS parameters and 5QI/QoS requirement of the DRB which the packet belong to.
  • the PDCP/SRAP entity maps packet of each DRB to the lower layer resource/channel/tunnel.
  • the PDCP/SRAP entity sends the packet to proper lower layer resource via its related SAP.
  • the PDCP/SRAP entity is informed with the mapping information between resource index of non-3GPP layer and DRB ID.
  • the u PDCP/SRAP entity determines resource index of non-3GPP according to DRB ID, and sends it to its corresponding SAP.
  • the PDCP/SRAP entity is informed with the resource index of non-standardized layer and its related QoS parameters.
  • the PDCP/SRAP entity determines the resource index of non-standardized layer according to QoS parameters of the resource index and 5QI/QoS requirement of DRB which the packet belongs to.
  • the non-standardized layer determines the proper resource based on the QoS request of RB.
  • the non-standardized layer just sends the packet via proper resource. Further, the implementation at the terminal device is simplified.
  • FIG. 6 illustrates the interactions among the PDCP/SRAP entity/layer and the non-standardized entity/layer.
  • the non-standardized layer enables to meet the QoS requirements.
  • FIG. 7 illustrates a flowchart of an example method 700 in accordance with some embodiments of the present disclosure.
  • the method 700 can be implemented at the first terminal device 120-1 as shown in FIG. 1A.
  • the first terminal device 120-1 generates a first packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU, the first packet indicating first information of at least one of the following: a first RB ID of a first RB, an ID of the first terminal device 120-1, or a first indication indicating a type of the first RB.
  • the first terminal device 120-1 transmits the first packet to a second terminal device 120-2 via a non-standardized indirect path.
  • At least part of the first information is indicated jointly.
  • At least part of the first information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the first information is independent from the PDCP PDU or the SRAP PDU.
  • a mapping between at least one of following is pre-configured: the first terminal device 120-1 and the second terminal device 120-2, an RB type and a non-standardized indirect path, or an RB ID and a non-standardized indirect path.
  • At least part of the first information is determined by a PDCP entity or an SRAP entity of the first terminal device 120-1.
  • transmitting the first packet to the second terminal device 120-2 comprises: transmitting, at a PDCP entity of the first terminal device 120-1, the first packet to a non-standardized entity of the first terminal device 120-1, a layer of the non-standardized entity is lower than a PDCP layer; and transmitting, at the non-standardized entity, the first packet to the second terminal device 120-2.
  • transmitting the first packet to the non-standardized entity comprises: transmitting, at the PDCP entity, the first packet to the non-standardized entity via an SRAP entity corresponding to the non-standardized path.
  • the first terminal device 120-1 receives, from the second terminal device 120-2, a third packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU, the third packet indicating second information of at least one of the following: a second RB ID of a second RB, the ID of the first terminal device 120-1, or a second indication indicating a type of the second RB.
  • a third packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU
  • the third packet indicating second information of at least one of the following: a second RB ID of a second RB, the ID of the first terminal device 120-1, or a second indication indicating a type of the second RB.
  • At least part of the second information is indicated jointly.
  • At least part of the second information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the second information is independent from the PDCP PDU or the SRAP PDU.
  • receiving the third packet comprises: receiving, at a non-standardized entity of the first terminal device 120-1, the third packet from the second terminal device 120-2, a layer of the non-standardized entity being lower than a PDCP layer.
  • the first terminal device 120-1 receives a first message from a network device 110, the first message indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • the first message comprises a third indication indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • he first message is an RRC signalling.
  • the first terminal device 120-1 transmits, to a network device 110, capability-related information indicating whether an SRAP entity is enabled by the first terminal device 120-1.
  • FIG. 8 illustrates a flowchart of an example method 800 in accordance with some embodiments of the present disclosure.
  • the method 800 can be implemented at the second terminal device 120-2 as shown in FIG. 1A.
  • the second terminal device 120-2 receives, from a first terminal device 120-1, a first packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU via a non-standardized indirect path, the first packet indicating first information of at least one of the following: a first RB ID of a first RB, an ID of the first terminal device 120-1, or an indication indicating a type of the first RB.
  • a first packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU via a non-standardized indirect path
  • the first packet indicating first information of at least one of the following: a first RB ID of a first RB, an ID of the first terminal device 120-1, or an indication indicating a type of the first RB.
  • the second terminal device 120-2 generates, a second packet based on the first packet.
  • the second terminal device 120-2 transmits the second packet to a network device 110.
  • At least part of the first information is indicated jointly.
  • At least part of the first information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the first information is independent from the PDCP PDU or the SRAP PDU.
  • a mapping between at least one of following are pre-configured: the first terminal device 120-1 and the second terminal device 120-2, an RB type and a non-standardized indirect path , or an RB and a non-standardized indirect path.
  • receiving the first packet comprises: receiving, at a non-standardized entity of the second terminal device 120-2, the first packet from the first terminal device 120-1, a layer of the non-standardized entity being lower than a PDCP layer.
  • generating the second packet based on the first packet comprises: generating an SRAP PDU based on the first information indicated in the first packet, the SRAP PDU comprising: the first RB ID, and the ID of the first terminal device 120-1.
  • the second packet further comprises the first indication indicating the type of the first RB.
  • transmitting the second packet to the network device 110 comprises: determining, an RLC channel to be used for transmitting the second packet to the network device 110 based on at least one of the following: the first RB ID, the ID of the first terminal device 120-1, or the first indication indicating the type of the first RB.
  • the second terminal device 120-2 receives a fourth packet from the network device 110; and generates a third packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU, the third packet indicating second information of at least one of the following: a second RB ID of a second RB, the ID of the first terminal device 120-1, or a second indication indicating a type of the second RB; and transmitting the third packet to the first terminal device 120-1.
  • a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU
  • the third packet indicating second information of at least one of the following: a second RB ID of a second RB, the ID of the first terminal device 120-1, or a second indication indicating a type of the second RB; and transmitting the third packet to the first terminal device 120-1.
  • At least part of the second information is indicated jointly.
  • At least part of the second information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the second information is independent from the PDCP PDU or the SRAP PDU.
  • At least part of the second information is determined by a PDCP entity or an SRAP entity of the second terminal device 120-2.
  • transmitting the third packet to the first terminal device 120-1 comprises: transmitting, at a PDCP entity of the second terminal device 120-2, the third packet to a non-standardized entity of the second terminal device 120-2, a layer of the non-standardized entity is lower than a PDCP layer; and transmitting, at the non-standardized entity, the third packet to the first terminal device 120-1.
  • the transmitting the third packet to the non-standardized entity comprises: transmitting, at the PDCP entity, the third packet to the non-standardized entity via an SRAP entity corresponding to the non-standardized path.
  • the fourth packet comprise the second indication indicating the type of the second RB.
  • the second terminal device 120-2 receives a second message from the network device 110, the second message indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • the second message comprises a fourth indication indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • the second message is an RRC signalling.
  • the second terminal device 120-2 transmits, to the network device 110, capability-related information indicating whether an SRAP entity is enabled by the second terminal device 120-2.
  • FIG. 9 illustrates a flowchart of an example method 900 in accordance with some embodiments of the present disclosure.
  • the method 900 can be implemented at the terminal device 120 as shown in FIG. 1A.
  • the terminal device 120 determines, at a non-standardized entity of a terminal device 120 involved in a non-standardized indirect path, status-related information of the non-standardized indirect path.
  • the terminal device 120 transmits a fifth indication indicating the status of the non-standardized indirect path to one of the following: an RRC entity, a PDCP entity, or an SRAP entity.
  • the status-related information is specific to one of the following: the non-standardized indirect path, at least one SAP, at least one RB, an RB type, or at least one non-standardized resource.
  • the status-related information of the non-standardized indirect path indicates one of the following: the non-standardized indirect path being available or unavailable, the non-standardized indirect path being established, the non-standardized indirect path being released, the non-standardized indirect path being failed, or the non-standardized indirect path being suspended.
  • the status-related information indicates QoS-related information of the non-standardized indirect path.
  • the status-related information indicates at least one of the following: a layer 2 identity of a further terminal device 120 involved in the non-standardized indirect path, at least one QoS ID, at least one 5QI, at least one RB ID, or at least one non-standardized resource ID.
  • the status-related information is at least one non-standardized parameter
  • the method further comprises: transforming the at least one non-standardized parameter into at least one standardized parameter being identifiable to one of the RRC entity, the PDCP entity or the SRAP entity; and generating the fifth indication by including the at least one standardized parameter.
  • the terminal device 120 receives a first configuration from a network device 110, the first configuration indicating at least one respective correspondence between the at least one non-standardized parameter and the least one standardized parameter.
  • determining the status of the non-standardized indirect path comprises: determining the status of the non-standardized indirect path in response to: receiving a sixth indication from one of the RRC entity, the PDCP entity or the SRAP entity, the sixth indication being used for requesting the non-standardized indirect entity to establish the non-standardized indirect path or report the status-related information, or receiving a packet from one of the RRC entity, the PDCP entity or the SRAP entity.
  • either of the sixth indication or the packet indicates QoS-related requirement for the non-standardized indirect path.
  • the QoS-related requirement is specific to one of the following: the non-standardized indirect path, at least one RB, at least one SAP, an RB type, or at least one non-standardized resource.
  • the terminal device 120 receives a second configuration from the network device 110, the second configuration indicating the QoS-related requirement for the non-standardized indirect path.
  • the sixth indication is transmitted by one of the RRC entity, the PDCP entity or the SRAP entity in response to receiving an RRC signalling from a network device 110.
  • the sixth indication is specific to one of the following:
  • the non-standardized indirect path at least one RB, at least one SAP, an RB type, or at least one non-standardized resource.
  • the packet is transmitted to a specific resource via an SAP corresponding to the specific resource.
  • the packet is transmitted together with a resource-related indication.
  • the resource-related indication indicates one of the following: at least one RB ID, or at least one non-standardized resource ID.
  • FIG. 10 is a simplified block diagram of a device 1000 that is suitable for implementing embodiments of the present disclosure.
  • the device 1000 can be considered as a further example implementation of the terminal device 120 as shown in FIG. 1A. Accordingly, the device 1000 can be implemented at or as at least a part of the terminal device 1120.
  • the device 1000 includes a processor 1010, a memory 1020 coupled to the processor 1010, a suitable transmitter (TX) /receiver (RX) 1040 coupled to the processor 1010, and a communication interface coupled to the TX/RX 1040.
  • the memory 1010 stores at least a part of a program 1030.
  • the TX/RX 1040 is for bidirectional communications.
  • the TX/RX 1040 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.
  • MME Mobility Management Entity
  • AMF Access and Mobility Management Function
  • RN relay node
  • Uu interface for communication between the eNB/gNB and a terminal device.
  • the program 1030 is assumed to include program instructions that, when executed by the associated processor 1010, enable the device 1000 to operate in accordance with the embodiments of the present disclosure, as discussed herein with reference to FIGs. 1A to 6.
  • the embodiments herein may be implemented by computer software executable by the processor 1010 of the device 1000, or by hardware, or by a combination of software and hardware.
  • the processor 1010 may be configured to implement various embodiments of the present disclosure.
  • a combination of the processor 1010 and memory 1020 may form processing means 1050 adapted to implement various embodiments of the present disclosure.
  • the memory 1020 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 1020 is shown in the device 1000, there may be several physically distinct memory modules in the device 1000.
  • the processor 1010 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 1000 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.
  • the first terminal device 120-1 comprises a circuitry configured to: generate a first packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU, the first packet indicating first information of at least one of the following: a first RB ID of a first RB, an ID of the first terminal device 120-1, or a first indication indicating a type of the first RB; and transmit the first packet to a second terminal device 120-2 via a non-standardized indirect path.
  • a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU
  • the first packet indicating first information of at least one of the following: a first RB ID of a first RB, an ID of the first terminal device 120-1, or a first indication indicating a type of the first RB
  • transmit the first packet to a second terminal device 120-2 via a non-standardized indirect
  • At least part of the first information is indicated jointly.
  • At least part of the first information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the first information is independent from the PDCP PDU or the SRAP PDU.
  • a mapping between at least one of following is pre-configured: the first terminal device 120-1 and the second terminal device 120-2, an RB type and a non-standardized indirect path, or an RB ID and a non-standardized indirect path.
  • At least part of the first information is determined by a PDCP entity or an SRAP entity of the first terminal device 120-1.
  • transmitting the first packet to the second terminal device 120-2 comprises: transmitting, at a PDCP entity of the first terminal device 120-1, the first packet to a non-standardized entity of the first terminal device 120-1, a layer of the non-standardized entity is lower than a PDCP layer; and transmitting, at the non-standardized entity, the first packet to the second terminal device 120-2.
  • transmitting the first packet to the non-standardized entity comprises: transmitting, at the PDCP entity, the first packet to the non-standardized entity via an SRAP entity corresponding to the non-standardized path.
  • the circuitry is further configured to: receive, from the second terminal device 120-2, a third packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU, the third packet indicating second information of at least one of the following: a second RB ID of a second RB, the ID of the first terminal device 120-1, or a second indication indicating a type of the second RB.
  • a third packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU
  • the third packet indicating second information of at least one of the following: a second RB ID of a second RB, the ID of the first terminal device 120-1, or a second indication indicating a type of the second RB.
  • At least part of the second information is indicated jointly.
  • At least part of the second information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the second information is independent from the PDCP PDU or the SRAP PDU.
  • receiving the third packet comprises: receiving, at a non-standardized entity of the first terminal device 120-1, the third packet from the second terminal device 120-2, a layer of the non-standardized entity being lower than a PDCP layer.
  • the circuitry is further configured to: receive a first message from a network device 110, the first message indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • the first message comprises a third indication indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • he first message is an RRC signalling.
  • the first terminal device 120-1 transmits, to a network device 110, capability-related information indicating whether an SRAP entity is enabled by the first terminal device 120-1.
  • a second terminal device 120-2 comprises a circuitry configured to: receive, from a first terminal device 120-1, a first packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU via a non-standardized indirect path, the first packet indicating first information of at least one of the following: a first RB ID of a first RB, an ID of the first terminal device 120-1, or an indication indicating a type of the first RB; generate, a second packet based on the first packet; and transmit the second packet to a network device 110.
  • a first packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU via a non-standardized indirect path
  • the first packet indicating first information of at least one of the following: a first RB ID of a first RB, an ID of the first terminal device 120-1, or an
  • At least part of the first information is indicated jointly.
  • At least part of the first information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the first information is independent from the PDCP PDU or the SRAP PDU.
  • a mapping between at least one of following are pre-configured: the first terminal device 120-1 and the second terminal device 120-2, an RB type and a non-standardized indirect path , or an RB and a non-standardized indirect path.
  • receiving the first packet comprises: receiving, at a non-standardized entity of the second terminal device 120-2, the first packet from the first terminal device 120-1, a layer of the non-standardized entity being lower than a PDCP layer.
  • generating the second packet based on the first packet comprises: generating an SRAP PDU based on the first information indicated in the first packet, the SRAP PDU comprising: the first RB ID, and the ID of the first terminal device 120-1.
  • the second packet further comprises the first indication indicating the type of the first RB.
  • transmitting the second packet to the network device 110 comprises: determining, an RLC channel to be used for transmitting the second packet to the network device 110 based on at least one of the following: the first RB ID, the ID of the first terminal device 120-1, or the first indication indicating the type of the first RB.
  • the circuitry is further configured to: receive a fourth packet from the network device 110; and generates a third packet associated with a layer 2 PDU being one of the following: a PDCP PDU, an SRAP PDU, an RLC PDU or a MAC PDU, the third packet indicating second information of at least one of the following: a second RB ID of a second RB, the ID of the first terminal device 120-1, or a second indication indicating a type of the second RB; and transmitting the third packet to the first terminal device 120-1.
  • At least part of the second information is indicated jointly.
  • At least part of the second information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the second information is independent from the PDCP PDU or the SRAP PDU.
  • At least part of the second information is determined by a PDCP entity or an SRAP entity of the second terminal device 120-2.
  • transmitting the third packet to the first terminal device 120-1 comprises: transmitting, at a PDCP entity of the second terminal device 120-2, the third packet to a non-standardized entity of the second terminal device 120-2, a layer of the non-standardized entity is lower than a PDCP layer; and transmitting, at the non-standardized entity, the third packet to the first terminal device 120-1.
  • the transmitting the third packet to the non-standardized entity comprises: transmitting, at the PDCP entity, the third packet to the non-standardized entity via an SRAP entity corresponding to the non-standardized path.
  • the fourth packet comprise the second indication indicating the type of the second RB.
  • the circuitry is further configured to: receive a second message from the network device 110, the second message indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • the second message comprises a fourth indication indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • the second message is an RRC signalling.
  • the second terminal device 120-2 transmits, to the network device 110, capability-related information indicating whether an SRAP entity is enabled by the second terminal device 120-2.
  • the first terminal device 120-1 comprises a circuitry configured to: determine, at a non-standardized entity of a terminal device 120 involved in a non-standardized indirect path, status-related information of the non-standardized indirect path; and transmit a fifth indication indicating the status of the non-standardized indirect path to one of the following: an RRC entity, a PDCP entity, or an SRAP entity.
  • the status-related information is specific to one of the following: the non-standardized indirect path, at least one SAP, at least one RB, an RB type, or at least one non-standardized resource.
  • the status-related information of the non-standardized indirect path indicates one of the following: the non-standardized indirect path being available or unavailable, the non-standardized indirect path being established, the non-standardized indirect path being released, the non-standardized indirect path being failed, or the non-standardized indirect path being suspended.
  • the status-related information indicates QoS-related information of the non-standardized indirect path.
  • the status-related information indicates at least one of the following: a layer 2 identity of a further terminal device 120 involved in the non-standardized indirect path, at least one QoS ID, at least one 5QI, at least one RB ID, or at least one non-standardized resource ID.
  • the status-related information is at least one non-standardized parameter
  • the method further comprises: transforming the at least one non-standardized parameter into at least one standardized parameter being identifiable to one of the RRC entity, the PDCP entity or the SRAP entity; and generating the fifth indication by including the at least one standardized parameter.
  • the circuitry is further configured to: receive a first configuration from a network device 110, the first configuration indicating at least one respective correspondence between the at least one non-standardized parameter and the least one standardized parameter.
  • determining the status of the non-standardized indirect path comprises: determining the status of the non-standardized indirect path in response to: receiving a sixth indication from one of the RRC entity, the PDCP entity or the SRAP entity, the sixth indication being used for requesting the non-standardized indirect entity to establish the non-standardized indirect path or report the status-related information, or receiving a packet from one of the RRC entity, the PDCP entity or the SRAP entity.
  • either of the sixth indication or the packet indicates QoS-related requirement for the non-standardized indirect path.
  • the QoS-related requirement is specific to one of the following: the non-standardized indirect path, at least one RB, at least one SAP, an RB type, or at least one non-standardized resource.
  • the circuitry is further configured to: receives a second configuration from the network device 110, the second configuration indicating the QoS-related requirement for the non-standardized indirect path.
  • the sixth indication is transmitted by one of the RRC entity, the PDCP entity or the SRAP entity in response to receiving an RRC signalling from a network device 110.
  • the sixth indication is specific to one of the following:
  • the non-standardized indirect path at least one RB, at least one SAP, an RB type, or at least one non-standardized resource.
  • the packet is transmitted to a specific resource via an SAP corresponding to the specific resource.
  • the packet is transmitted together with a resource-related indication.
  • the resource-related indication indicates one of the following: at least one RB ID, or at least one non-standardized resource ID.
  • circuitry used herein may refer to hardware circuits and/or combinations of hardware circuits and software.
  • the circuitry may be a combination of analog and/or digital hardware circuits with software/firmware.
  • 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.
  • 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.
  • 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.
  • a method of communication comprises: determining, at a first entity of a terminal device configured with a plurality of paths including a first path, a successful transmission associated with a packet data convergence protocol (PDCP) data packet data unit (PDU) on the first path, the first path being an indirect path, the first entity corresponding to the first path, a layer of the first entity being lower than a PDCP layer; and performing one of the following: transmitting, to a PDCP entity of the terminal device, a confirmation indication indicating the successful transmission; or disabling to transmit the confirmation indication to the PDCP entity.
  • PDCP packet data convergence protocol
  • PDU packet data packet data unit
  • a method of communication comprises: generating, at a first terminal device, a first packet associated with a layer 2 packet data unit (PDU) being one of the following: a packet data convergence protocol (PDCP) PDU, a sidelink relay adaptation protocol (SRAP) PDU, a radio link control (RLC) PDU or a media access control (MAC) PDU, the first packet indicating first information of at least one of the following: a first radio bearer (RB) identity (ID) of a first RB, an ID of the first terminal device, or a first indication indicating a type of the first RB; and transmitting, the first packet to a second terminal device via a non-standardized indirect path.
  • PDU packet data convergence protocol
  • SRAP sidelink relay adaptation protocol
  • RLC radio link control
  • MAC media access control
  • At least part of the first information is indicated jointly.
  • At least part of the first information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the first information is independent from the PDCP PDU or the SRAP PDU.
  • a mapping between at least one of following is pre-configured: the first terminal device and the second terminal device, an RB type and a non-standardized indirect path, or an RB ID and a non-standardized indirect path.
  • At least part of the first information is determined by a PDCP entity or an SRAP entity of the first terminal device.
  • transmitting the first packet to the second terminal device comprises: transmitting, at a PDCP entity of the first terminal device, the first packet to a non-standardized entity of the first terminal device, a layer of the non-standardized entity is lower than a PDCP layer; and transmitting, at the non-standardized entity, the first packet to the second terminal device.
  • the transmitting the first packet to the non-standardized entity comprises: transmitting, at the PDCP entity, the first packet to the non-standardized entity via an SRAP entity corresponding to the non-standardized path.
  • the method further comprises: receiving, from the second terminal device, a third packet associated with a layer 2 packet data unit (PDU) being one of the following: a packet data convergence protocol (PDCP) PDU, a sidelink relay adaptation protocol (SRAP) PDU, a radio link control (RLC) PDU or a media access control (MAC) PDU, the third packet indicating second information of at least one of the following: a second RB ID of a second RB, the ID of the first terminal device, or a second indication indicating a type of the second RB.
  • PDU layer 2 packet data unit
  • PDCP packet data convergence protocol
  • SRAP sidelink relay adaptation protocol
  • RLC radio link control
  • MAC media access control
  • At least part of the second information is indicated jointly.
  • At least part of the second information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the second information is independent from the PDCP PDU or the SRAP PDU.
  • receiving the third packet comprises: receiving, at a non-standardized entity of the first terminal device, the third packet from the second terminal device, a layer of the non-standardized entity being lower than a PDCP layer.
  • the method further comprises: receiving a first message from a network device, the first message indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • the first message comprises a third indication indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • the first message is a radio resource control (RRC) signalling.
  • RRC radio resource control
  • the method further comprises: transmitting, to a network device, capability-related information indicating whether an SRAP entity is enabled by the first terminal device.
  • a method of communication comprises: receiving, at a second terminal device and from a first terminal device, a first packet associated with a layer 2 packet data unit (PDU) being one of the following: a packet data convergence protocol (PDCP) PDU, a sidelink relay adaptation protocol (SRAP) PDU, a radio link control (RLC) PDU or a media access control (MAC) PDU via a non-standardized indirect path, the first packet indicating first information of at least one of the following: a first radio bearer (RB) identity (ID) of a first RB, an ID of the first terminal device, or an indication indicating a type of the first RB; and generating, a second packet based on the first packet; and transmitting, the second packet to a network device.
  • PDU packet data convergence protocol
  • SRAP sidelink relay adaptation protocol
  • RLC radio link control
  • MAC media access control
  • At least part of the first information is indicated jointly.
  • At least part of the first information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the first information is independent from the PDCP PDU or the SRAP PDU.
  • a mapping between at least one of following are pre-configured: the first terminal device and the second terminal device, an RB type and a non-standardized indirect path , or an RB and a non-standardized indirect path.
  • receiving the first packet comprises: receiving, at a non-standardized entity of the second terminal device, the first packet from the first terminal device, a layer of the non-standardized entity being lower than a PDCP layer,
  • generating the second packet based on the first packet comprises: generating a SRAP PDU based on the first information indicated in the first packet, the SRAP PDU comprising: the first RB ID, and the ID of the first terminal device.
  • the second packet further comprises the first indication indicating the type of the first RB.
  • transmitting the second packet to the network device comprises: determining, a radio link control (RLC) channel to be used for transmitting the second packet to the network device based on at least one of the following: the first RB ID, the ID of the first terminal device, or the first indication indicating the type of the first RB.
  • RLC radio link control
  • the method further comprises: receiving a fourth packet from the network device; generating a third packet associated with a layer 2 packet data unit (PDU) being one of the following: a packet data convergence protocol (PDCP) PDU, a sidelink relay adaptation protocol (SRAP) PDU, a radio link control (RLC) PDU or a media access control (MAC) PDU, the third packet indicating second information of at least one of the following: a second RB ID of a second RB, the ID of the first terminal device, or a second indication indicating a type of the second RB; and transmitting the third packet to the first terminal device.
  • PDU layer 2 packet data unit
  • PDCP packet data convergence protocol
  • SRAP sidelink relay adaptation protocol
  • RLC radio link control
  • MAC media access control
  • At least part of the second information is indicated jointly.
  • At least part of the second information is comprised in a header of the PDCP PDU or the SRAP PDU, or at least part of the second information is independent from the PDCP PDU or the SRAP PDU.
  • At least part of the second information is determined by a PDCP entity or an SRAP entity of the second terminal device.
  • transmitting the third packet to the first terminal device comprises: transmitting, at a PDCP entity of the second terminal device, the third packet to a non-standardized entity of the second terminal device, a layer of the non-standardized entity is lower than a PDCP layer; and transmitting, at the non-standardized entity, the third packet to the first terminal device.
  • the transmitting the third packet to the non-standardized entity comprises: transmitting, at the PDCP entity, the third packet to the non-standardized entity via an SRAP entity corresponding to the non-standardized path.
  • the fourth packet comprise the second indication indicating the type of the second RB.
  • the method further comprises: receiving a second message from the network device, the second message indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • the second message comprises a fourth indication indicating whether an SRAP entity is configured for the non-standardized indirect path.
  • the second message is a radio resource control (RRC) signalling.
  • RRC radio resource control
  • the method further comprises: transmitting, to the network device, capability-related information indicating whether an SRAP entity is enabled by the second terminal device.
  • a method of communication comprises: determining, at a non-standardized entity of a terminal device involved in a non-standardized indirect path, status-related information of the non-standardized indirect path; and transmitting a fifth indication indicating the status of the non-standardized indirect path to one of the following: a radio resource control (RRC) entity, a packet data convergence protocol (PDCP) entity, or a sidelink relay adaptation protocol (SRAP) entity.
  • RRC radio resource control
  • PDCP packet data convergence protocol
  • SRAP sidelink relay adaptation protocol
  • the status-related information is specific to one of the following: the non-standardized indirect path, at least one service access point (SAP) , at least one radio bearer (RB) , an RB type, or at least one non-standardized resource.
  • SAP service access point
  • RB radio bearer
  • the status-related information of the non-standardized indirect path indicates one of the following: the non-standardized indirect path being available or unavailable, the non-standardized indirect path being established, the non-standardized indirect path being released, the non-standardized indirect path being failed, or the non-standardized indirect path being suspended.
  • the status-related information indicates quality of service (QoS) -related information of the non-standardized indirect path.
  • QoS quality of service
  • the status-related information indicates at least one of the following: a layer 2 identity of a further terminal device involved in the non-standardized indirect path, at least one quality of service (QoS) identity (ID) , at least one 5G QoS identifier (5QI) , at least one RB ID, or at least one non-standardized resource ID.
  • QoS quality of service
  • ID quality of service identity
  • 5QI 5G QoS identifier
  • the status-related information is at least one non-standardized parameter
  • the method further comprises: transforming the at least one non-standardized parameter into at least one standardized parameter being identifiable to one of the RRC entity, the PDCP entity or the SRAP entity; and generating the fifth indication by including the at least one standardized parameter.
  • the method further comprises: receiving a first configuration from a network device, the first configuration indicating at least one respective correspondence between the at least one non-standardized parameter and the least one standardized parameter.
  • determining the status of the non-standardized indirect path comprises: determining the status of the non-standardized indirect path in response to: receiving a sixth indication from one of the RRC entity, the PDCP entity or the SRAP entity, the sixth indication being used for requesting the non-standardized indirect entity to establish the non-standardized indirect path or report the status-related information, or receiving a packet from one of the RRC entity, the PDCP entity or the SRAP entity.
  • either of the sixth indication or the packet indicates quality of service (QoS) -related requirement for the non-standardized indirect path.
  • QoS quality of service
  • the QoS-related requirement is specific to one of the following: the non-standardized indirect path, at least one radio bearer (RB) , at least one service access point (SAP) , an RB type, or at least one non-standardized resource.
  • the method further comprises: receiving a second configuration from the network device, the second configuration indicating the QoS-related requirement for the non-standardized indirect path.
  • the sixth indication is transmitted by one of the RRC entity, the PDCP entity or the SRAP entity in response to receiving an RRC signalling from a network device.
  • the sixth indication is specific to one of the following: the non-standardized indirect path, at least one radio bearer (RB) , at least one service access point (SAP) , an RB type, or at least one non-standardized resource.
  • the packet is transmitted to a specific resource via a service access point (SAP) corresponding to the specific resource.
  • SAP service access point
  • the packet is transmitted together with a resource-related indication.
  • the resource-related indication indicates one of the following: at least one RB identity (ID) , or at least one non-standardized resource ID.
  • a device of communication comprises: a processor configured to cause the device to perform any of the methods above.
  • a computer readable medium has instructions stored thereon, the instructions, when executed on at least one processor, causing the at least one processor to perform the method according to any of the methods above.
  • various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representation, it will be appreciated that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
  • the present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium.
  • the computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the process or method as described above with reference to FIGs. 1 to 6.
  • 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.
  • machine readable storage medium 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.
  • RAM random access memory
  • ROM read-only memory
  • EPROM or Flash memory erasable programmable read-only memory
  • CD-ROM portable compact disc read-only memory
  • magnetic storage device or any suitable combination of the foregoing.

Landscapes

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

Abstract

La présente divulgation concerne, dans des modes de réalisation décrits à titre d'exemple, un mécanisme efficace pour gérer le scénario d'une couverture discontinue. Dans cette solution, un premier dispositif terminal génère un premier paquet associé à une unité de données par paquets (PDU) de couche 2 et transmet le premier paquet à un second dispositif terminal par l'intermédiaire d'un chemin indirect non normalisé. De cette manière, indépendamment du fait qu'il existe ou non une couche/entité SRAP configurée pour le chemin indirect non normalisé, la PDU de couche 2 peut être échangée entre le dispositif terminal distant, le dispositif terminal relais et le dispositif de réseau.
PCT/CN2022/121073 2022-09-23 2022-09-23 Procédé, dispositif et support de stockage informatique de communication WO2024060242A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/121073 WO2024060242A1 (fr) 2022-09-23 2022-09-23 Procédé, dispositif et support de stockage informatique de communication

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/121073 WO2024060242A1 (fr) 2022-09-23 2022-09-23 Procédé, dispositif et support de stockage informatique de communication

Publications (1)

Publication Number Publication Date
WO2024060242A1 true WO2024060242A1 (fr) 2024-03-28

Family

ID=90453770

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/121073 WO2024060242A1 (fr) 2022-09-23 2022-09-23 Procédé, dispositif et support de stockage informatique de communication

Country Status (1)

Country Link
WO (1) WO2024060242A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108029148A (zh) * 2015-07-23 2018-05-11 英特尔Ip公司 层2中继协议和移动性中继方法
US20180183770A1 (en) * 2016-12-26 2018-06-28 Htc Corporation Device and Method of Handling Mobile Data Transmissions in a Wireless Communication System
WO2018176416A1 (fr) * 2017-03-31 2018-10-04 华为技术有限公司 Procédé, appareil, et système de communication à relais
WO2021168630A1 (fr) * 2020-02-24 2021-09-02 Oppo广东移动通信有限公司 Procédé de relais, procédé et appareil de génération de table d'acheminement, terminal et support de stockage
WO2021168632A1 (fr) * 2020-02-24 2021-09-02 Oppo广东移动通信有限公司 Procédé de relais, procédé, appareil et dispositif de production de table de routage, ainsi que support de stockage

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108029148A (zh) * 2015-07-23 2018-05-11 英特尔Ip公司 层2中继协议和移动性中继方法
US20180183770A1 (en) * 2016-12-26 2018-06-28 Htc Corporation Device and Method of Handling Mobile Data Transmissions in a Wireless Communication System
WO2018176416A1 (fr) * 2017-03-31 2018-10-04 华为技术有限公司 Procédé, appareil, et système de communication à relais
WO2021168630A1 (fr) * 2020-02-24 2021-09-02 Oppo广东移动通信有限公司 Procédé de relais, procédé et appareil de génération de table d'acheminement, terminal et support de stockage
WO2021168632A1 (fr) * 2020-02-24 2021-09-02 Oppo广东移动通信有限公司 Procédé de relais, procédé, appareil et dispositif de production de table de routage, ainsi que support de stockage

Similar Documents

Publication Publication Date Title
KR20190006190A (ko) 프런트홀 인터페이스 수립 방법, 사용자 장치에 대한 액세스 수행 방법, 사용자 장치에 대한 핸드오버 수행 방법 및 장치, 데이터 전달 방법, 사용자 장치 및 기지국
RU2722504C1 (ru) Сетевой узел и способ конфигурирования pdcp для устройства беспроводной связи
CN105103636B (zh) 一种中继节点RN、宿主基站DeNB及一种通信方法
CN113273260B (zh) 通信装置及通信方法
CN116250282A (zh) 数据传输的方法和装置
WO2021147030A1 (fr) Procédés, dispositifs, et support de communication
US11812444B2 (en) Resource scheduling between network nodes
WO2024007176A1 (fr) Procédés, dispositifs et support de communication
WO2024060242A1 (fr) Procédé, dispositif et support de stockage informatique de communication
US20230292191A1 (en) Mechanism for cell identity management
WO2021179146A1 (fr) Procédés, dispositifs et support de communication
WO2024207377A1 (fr) Procédé, dispositif et support de stockage informatique de communication
WO2024207238A1 (fr) Dispositifs et procédés de communication
WO2023230884A1 (fr) Procédé, dispositif et support de stockage informatique de communication
WO2024168738A1 (fr) Procédé, dispositif et support de stockage informatique de communication
WO2024060148A1 (fr) Procédé, dispositif et support de stockage informatique de communication
WO2024092657A1 (fr) Procédé, dispositif et support d'enregistrement informatique de communication
WO2024060102A1 (fr) Procédé, dispositif et support de stockage informatique de communication
WO2023050187A1 (fr) Procédé, dispositif et support de stockage informatique de communication
WO2024040540A1 (fr) Procédé, dispositif et support de stockage informatique de communication
WO2023230921A1 (fr) Procédés, dispositifs et support de communication
WO2024212059A1 (fr) Dispositifs et procédés de communication
WO2024152266A1 (fr) Dispositifs et procédés de communication
WO2023173423A1 (fr) Procédés, dispositifs et support lisible par ordinateur pour des communications
WO2024164113A1 (fr) Dispositifs, procédés et support aux fins d'une communication

Legal Events

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

Ref document number: 22959245

Country of ref document: EP

Kind code of ref document: A1