WO2021253437A1

WO2021253437A1 - Method and apparatus for wireless communication

Info

Publication number: WO2021253437A1
Application number: PCT/CN2020/097217
Authority: WO
Inventors: Lianhai WU; Ran YUE; Zhennian SUN; Jie Shi
Original assignee: Lenovo (Beijing) Limited
Priority date: 2020-06-19
Filing date: 2020-06-19
Publication date: 2021-12-23

Abstract

Embodiments of the present disclosure relate to methods and apparatuses for wireless communication. According to some embodiments of the disclosure, a method may include: receiving a first data at a second user equipment (UE) on a sidelink from a first UE; determining whether a destination of the first data is the second UE or not; adding a second header to the first data at a sidelink adaptation protocol (SLAP) layer to construct a second data when the destination of the first data is not the second UE, wherein the second header of the second data comprises an indicator indicating the destination of the first data; and transmitting the second data to the destination of the first data.

Description

METHOD AND APPARATUS FOR WIRELESS COMMUNICATION

TECHNICAL FIELD

Embodiments of the present application generally relate to wireless communication technology, especially to the protocol data unit (PDU) format employed in a wireless communication system.

BACKGROUND

Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, broadcasts, and so on. Wireless communication systems may employ multiple access technologies capable of supporting communication with multiple users by sharing available system resources (e.g., time, frequency, and power) . Examples of wireless communication systems may include fourth generation (4G) systems such as long term evolution (LTE) systems, LTE-advanced (LTE-A) systems, or LTE-A Pro systems, and fifth generation (5G) systems which may also be referred to as new radio (NR) systems.

In the above wireless communication systems, a user equipment (UE) may communicate with another UE via a data path supported by an operator's network, e.g., a cellular or a Wi-Fi network infrastructure. The data path supported by the operator's network may include a base station (BS) and multiple gateways.

Some wireless communication systems may support sidelink (SL) communications, in which devices (e.g., UEs) that are relatively close to each other may communicate with one another directly via an SL, rather than being linked through the BS. The term "SL" may refer to a direct radio link established for communicating among devices, as opposed to communicating via the cellular infrastructure (uplink and downlink) as discussed above. The term "SL" may also be referred to as a sidelink communication link.

The 3rd generation partnership project (3GPP) is envisioning a scenario which supports a relaying function based on the sidelink. For example, a pair of UEs may be in sidelink communication. One UE of the pair of UEs may reach another UE or a BS via the other UE of the pair of UEs. The industry desires a technology for supporting such relaying function based on the sidelink.

SUMMARY

According to some embodiments of the present application, a method may include: receiving a first data at a second user equipment (UE) on a sidelink from a first UE; determining whether a destination of the first data is the second UE or not; adding a second header to the first data at a sidelink adaptation protocol (SLAP) layer to construct a second data when the destination of the first data is not the second UE, wherein the second header of the second data comprises an indicator indicating the destination of the first data; and transmitting the second data to the destination of the first data.

According to some other embodiments of the present application, a method may include: receiving a first data, at a second user equipment (UE) on a sidelink from a first UE; determining whether a destination of the first data is the second UE or not; adding a second header to the first data at a sidelink adaptation protocol (SLAP) layer to construct a second data when the destination of the first data is not the second UE, wherein the second header of the second data comprises information related to a source; and transmitting the second data to the destination of the first data.

According to some other embodiments of the present application, a method may include: constructing a first data at a sidelink adaptation protocol (SLAP) layer of a first user equipment (UE) , wherein a header of the first data comprises an indicator indicating a destination of the first data; submitting the first data to a lower layer for transmission; and transmitting the first data on a sidelink to a second UE.

According to some other embodiments of the present application, a method may include: constructing a first data at a sidelink adaptation protocol (SLAP) layer of a first user equipment (UE) , wherein a header of the first data comprises information related to a source; submitting the first data to a lower layer for transmission; and transmitting the first data on a sidelink to a second UE.

According to some other embodiments of the present application, a method may include: receiving a second data at a third user equipment (UE) on a sidelink from a second UE; and in the case that a header of the second data comprises an indicator indicating that a destination of the second data is a UE and a destination field indicating the identity of the third UE, determining that the destination of the second data is the third UE.

According to some other embodiments of the present application, a method may include: receiving a second data at a third user equipment (UE) on a sidelink from a second UE, wherein a header of the second data comprises information related to a source indicating that the header of the second data comprises a reduced or a full identity of a source UE, and the header of the second data further comprises a reduced or a full identity of the source UE; and in the case that the header of the second data comprises an identity of the third UE, determining that the destination of the second data is the third UE.

According to some other embodiments of the present application, a method may include: receiving a second data at a base station (BS) from a second user equipment (UE) ; wherein a header of the second data comprises an indicator indicating that a destination of the second data is a BS and a source field indicating an identity of a source UE, or wherein the header of the second data comprises information related to a source indicating that the header of the second data comprises a reduced or a full identity of a source UE, and the header of the second data further comprises a reduced or a full identity of the source UE.

Some embodiments of the present application also provide an apparatus, include: at least one non-transitory computer-readable medium having computer executable instructions stored therein, at least one receiving circuitry; at least one transmitting circuitry; and at least one processor coupled to the at least one non-transitory computer-readable medium, the at least one receiving circuitry and the at least one transmitting circuitry. The computer executable instructions are programmed to implement any method as stated above with the at least one receiving circuitry, the at least one transmitting circuitry and the at least one processor.

Embodiments of the present application provide technical solutions for supporting the relaying function based on the sidelink, and can facilitate and improve the implementation of 5G NR technology.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which advantages and features of the application can be obtained, a description of the application is rendered by reference to specific embodiments thereof, which are illustrated in the appended drawings. These drawings depict only example embodiments of the application and are not therefore to be considered limiting of its scope.

FIG. 1 illustrates a schematic diagram of a wireless communication system in accordance with some embodiments of the present application;

FIG. 2 illustrates a schematic diagram of a wireless communication system in accordance with some embodiments of the present application;

FIG. 3 illustrates an example block diagram of a protocol stack for relaying in accordance with some embodiments of the present application;

FIG. 4 illustrates a schematic diagram of a wireless communication system in accordance with some embodiments of the present application;

FIG. 5 illustrates an example block diagram of a protocol stack for relaying in accordance with some embodiments of the present application;

FIG. 6 illustrates an exemplary procedure for performing wireless communication via a relay node in accordance with some embodiments of the present application; and

FIG. 7 illustrates a block diagram of an exemplary apparatus in accordance with some embodiments of the present disclosure.

DETAILED DESCRIPTION

The detailed description of the appended drawings is intended as a description of the preferred embodiments of the present disclosure and is not intended to represent the only form in which the present disclosure may be practiced. It should be understood that the same or equivalent functions may be accomplished by different embodiments that are intended to be encompassed within the spirit and scope of the present disclosure.

Reference will now be made in detail to some embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. To facilitate understanding, embodiments are provided under specific network architecture and new service scenarios, such as the 3rd generation partnership project (3GPP) 5G (NR) , 3GPP long-term evolution (LTE) Release 8, and so on. It is contemplated that along with the developments of network architectures and new service scenarios, all embodiments in the present disclosure are also applicable to similar technical problems; and moreover, the terminologies recited in the present disclosure may change, which should not affect the principle of the present disclosure.

FIG. 1 illustrates a schematic diagram of a wireless communication system 100 in accordance with some embodiments of the present disclosure.

As shown in FIG. 1, the wireless communication system 100 may support sidelink communications. In the context of the present application, sidelink communications may be categorized according to the wireless communication technologies adopted. For example, NR sidelink communications (specified in 3GPP specification TS 38.311) may refer to access stratum (AS) functionality enabling at least vehicle-to-everything (V2X) communications as defined in 3GPP specification TS 23.287 between neighboring UEs, using NR technology but not traversing any network node. V2X sidelink communications (specified in 3GPP specification TS 36.311) may refer to AS functionality enabling V2X communications as defined in 3GPP specification TS 23.285 between neighboring UEs, using evolved-universal mobile telecommunication system (UMTS) terrestrial radio access (UTRA) (E-UTRA) technology, but not traversing any network node. However, if being not specified, "sidelink communications" may refer to NR sidelink communications, V2X sidelink communications, or any sidelink communications adopting other wireless communication technologies.

Referring to FIG. 1, the wireless communication system 100 may include some base stations (e.g., BS 102 and BS 103) and some UEs (e.g., UE 101A, UE 101B, and UE 101C) . Although a specific number of UEs and BSs are depicted in FIG. 1, it is contemplated that any number of UEs and BSs may be included in the wireless communication system 100.

The UEs and the BSs may support communication based on, for example, 3G, long-term evolution (LTE) , LTE-advanced (LTE-A) , new radio (NR) , or other suitable protocol (s) . In some embodiments of the present disclosure, a BS may be referred to as an access point, an access terminal, a base, a base unit, a macro cell, a Node-B, an evolved Node B (eNB) , a gNB, an ng-eNB, a Home Node-B, a relay node, or a device, or described using other terminology used in the art. A UE may include, for example, but is not limited to, a computing device, a wearable device, a mobile device, an IoT device, a vehicle, etc. Persons skilled in the art should understand that as technology develops and advances, the terminologies described in the present disclosure may change, but should not affect or limit the principles and spirit of the present disclosure.

The UE 101A and UE 101B may be in-coverage. For example, as shown in FIG. 1, the UE 101A may be within the coverage of BS 102, and the UE 101B may be within the coverage of BS 103. The UE 101C may be out-of-coverage. For example, as shown in FIG. 1, the UE 101C may be outside the coverage of any BSs, for example, both the BS 102 and BS 103. The UE 101A and UE 101B may respectively connect to the BS 102 and BS 103 via a network interface, for example, the Uu interface as specified in 3GPP standard documents. The control plane protocol stack in the Uu interface may include a radio resource control (RRC) layer, which may be referred to as a Uu-RRC. The BS 102 and BS 103 may be connected to each other via a network interface, for example, the Xn interface as specified in 3GPP standard documents. The UE 101A, UE 101B, and UE 101C may be connected to each other respectively via, for example, a PC5 interface as specified in 3GPP standard documents. The control plane protocol stack in the PC5 interface may include a radio resource control (RRC) layer, which may be referred to as PC5-RRC.

Support for V2X services via the PC5 interface can be provided by, for example, NR sidelink communication or V2X sidelink communication. NR sidelink communication can support one of the following three types of transmission modes for a pair of a Source Layer-2 ID and a Destination Layer-2 ID: unicast transmission, groupcast transmission, and broadcast transmission. Sidelink communication transmission and reception over the PC5 interface are supported when the UE is either in-coverage or out-of-coverage. For example, the UE 101A, which is within the coverage of the BS 102, can perform sidelink transmission and reception (e.g., sidelink unicast transmission, sidelink groupcast transmission, or sidelink broadcast transmission) over a PC5 interface. The UE 101C, which is outside the coverage of both the BS 102 and BS 103, can also perform sidelink transmission and reception over a PC5 interface.

A UE which supports sidelink communication or V2X communication may be referred to as a V2X UE. A V2X UE may be a cell phone, a vehicle, a roadmap device, a computer, a laptop, an IoT (internet of things) device or other type of device in accordance with some other embodiments of the present application.

A V2X UE can operate in different modes. At least two sidelink resource allocation modes are defined for sidelink communication. For example, mode 1 may refer to the situation where a base station schedules sidelink resource (s) to be used by the UE for sidelink transmission (s) , and mode 2 may refer to the situation where a UE determines sidelink transmission resource (s) and timing within a resource pool. The resource pool may be configured by a base station or network, or may be pre-configured according to a standard. In mode 2, the base station may not need to dynamically schedule the sidelink resources for the UE, and the UE may determine the sidelink transmission resources and timing in the resource pool based on, for example, a measurement result and a sensing result.

In mode 1, a UE may need to be in an RRC_CONNECTED state in order to transmit data. A base station can dynamically schedule resources to the UE via a physical downlink control channel (PDCCH) for NR sidelink communication. In addition, the base station can allocate sidelink resources to the UE with two types of configured sidelink grants (e.g., sidelink resources) :

- sidelink configured grant type 1: an RRC directly provides the configured sidelink grant only for NR sidelink communication; and

- sidelink configured grant type 2: an RRC defines the periodicity of the configured sidelink grant while the PDCCH can either signal and activate the configured sidelink grant, or deactivate it.

For a UE performing NR sidelink communication, there can be more than one configured sidelink grant activated at a time on the carrier configured for sidelink transmission.

In mode 2, a UE can transmit data when the UE is either in-coverage or out-of-coverage. The UE may autonomously select a sidelink grant from a resource pool provided by system information (e.g., system information block (SIB) ) or dedicated signaling while the UE is inside the coverage of a BS or a pre-configured resource pool while the UE is outside the coverage of any BS.

For NR sidelink communication, the resource pool can be provided for a given validity area where the UE does not need to acquire a new resource pool while moving within the validity area, at least when this pool is provided by an SIB (for example, a reuse valid area of an NR SIB) . The UE may be allowed to temporarily use the UE autonomous resource selection method with random selection for sidelink transmission based on configuration of the exceptional transmission resource pool as specified in 3GPP specification TS 38.331.

FIG. 2 illustrates a schematic diagram of a wireless communication system 200 in accordance with some embodiments of the present application.

As shown in FIG. 2, the wireless communication system 200 may include some UEs (e.g., UE 201A, UE 201B, and UE 201C) . The wireless communication system 200 may also include some base stations (not shown in FIG. 2) . Each of the UE 201A, UE 201B, and UE 201C may be in-coverage or out-of-coverage. Although a specific number of UEs are depicted in FIG. 2, it is contemplated that any number of UEs may be included in the wireless communication system 200.

The wireless communication system 200 may support sidelink communications. For example, UE 201B may be in sidelink communication with UE 201A and UE 201C, respectively. UE 201A and UE 201C may not be able to communicate with each via direct sidelink communication due to a relatively far distance therebetween. However, UE 201A and UE 201C may establish a connection via UE 201B. In the context of the present application, a UE (e.g., UE 201B) , which functions as a relay between two or more UEs, may be referred to a UE-to-UE relay. Although a UE-to-UE relay for unicast transmission is depicted in FIG. 2, it is contemplated that UEs may perform groupcast transmission and broadcast transmission via a UE-to-UE relay. It should be appreciated by persons skilled in the art that although a single relay node between UE 201A and UE 201C is depicted in FIG. 2, it is contemplated that any number of relay nodes may be included.

After establishing a connection via UE 201B, a User Plane (UP) protocol stack may be establish at UE 201A, UE 201B and UE 201C. FIG. 3 illustrates an example block diagram of a protocol stack for layer 2 relaying in accordance with some embodiments of the present application.

Referring to FIG. 3, a User Plane (UP) protocol stack 300 may be established at a transmitting (TX) UE (e.g., UE 201A) , a relay UE (e.g., UE 201B) , and a receiving (Rx) UE (e.g., UE 201C) to support layer 2 (L2) relaying according to some embodiments of the present disclosure. UE 201A may connect to relay UE 201B via a sidelink (e.g., a PC5 interface 373a) . Relay UE 201B may connect to Rx UE 201C via a sidelink (e.g., a PC5 interface 373b) .

The data flow of the protocol stack 300 is described below.

As illustrated in FIG. 3, the UE 201A protocol stack may include a service data adaptation protocol (SDAP) layer 320A, a packet data convergence protocol (PDCP) layer 330A, a radio link control (RLC) layer 350A, a medium access control (MAC) layer 360A, and a physical (PHY) layer 370A.

At the UE 201A, a higher layer (e.g., Internet Protocol (IP) layer, which is not shown in FIG. 3) may submit IP Packets to the SDAP layer 320A. The SDAP layer 320A may add SDAP headers to SDAP SDUs received from the higher layer to form SDAP Packet Data Units (PDUs) , and may submit the SDAP PDUs to a lower layer (e.g., the PDCP layer 330A) . The PDCP layer 330A may add PDCP headers to PDCP SDUs received from the SDAP layer 320A, and may submit PDCP PDUs to a lower layer (e.g., the RLC layer 350A) . The RLC layer 350A may add RLC headers to RLC SDUs received from the PDCP layer 330A, and may submit RLC PDUs to a lower layer (e.g., the MAC layer 360A) . The MAC layer 360A may add MAC headers to MAC SDUs received from the RLC layer 350A to form MAC PDUs, and may submit the MAC PDUs to a lower layer (e.g., the PHY layer 370A) . The PHY layer 370A may add information such as Cyclic Redundancy Check (CRC) information to Transport Blocks (TBs) corresponding to the MAC PDUs for transmission. Control information, such as sidelink control information, corresponding to the TBs may also be transmitted.

The UE 201B may include a receiving protocol stack and a transmitting protocol stack. The receiving protocol stack of the UE 201B may include an RLC layer 350B, an MAC layer 360B, and a PHY layer 370B. The transmitting protocol stack of the UE 201B may include a sidelink adaptation protocol (SLAP) layer 340B', an RLC layer 350B', an MAC layer 360B', and a PHY layer 370B'.

The UE 201B may receive data from the UE 201A. For example, at the receiving protocol stack of the UE 201B, the PHY layer 370B may receive and decode data from the UE 201A, and may deliver TBs decoded from the data to an upper layer (e.g., the MAC layer 360B) . The MAC layer 360B may decode MAC PDUs corresponding to the TBs, and may deliver MAC SDUs to an upper layer (e.g., the RLC layer 350B) . The RLC layer 350B may decode RLC PDUs received from the MAC layer 360B, and may deliver the decoded data (e.g., RLC SUDs) to the transmitting protocol stack of the UE 201B.

The transmitting protocol stack of the UE 201B may receive decoded data from the receiving protocol stack of the UE 201B. For example, the SLAP layer 340B' may receive decoded data from the receiving protocol stack of the UE 201B, and may encode it as SLAP PDUs to submit to a lower layer (e.g., RLC layer 350B') . The RLC layer 350B' may encode RLC SDUs from the SLAP layer 340B' as RLC PDUs to submit to a lower layer (e.g., MAC layer 360B') . The MAC layer 360B' may encode MAC SDUs from the RLC layer 350B' as MAC PDUs to submit to a lower layer (e.g., the PHY layer 370B') . The PHY layer 370B' may add information such as CRC to the TBs corresponding to the MAC PDUs for transmitting to a destination device (e.g., the UE 201C) . Control information, such as sidelink control information, corresponding to the TBs may also be transmitted.

The UE 201C protocol stack may include an SDAP layer 320C, a PDCP layer 330C, an SLAP layer 340C, an RLC layer 350C, an MAC layer 360C, and a PHY layer 370C.

The UE 201C may receive data from the UE 201B. For example, the PHY layer 370C may receive and decode data from the UE 201B, and may deliver decoded TBs to an upper layer (e.g., the MAC layer 360C) . The MAC layer 360C may decode MAC PDUs corresponding to the TBs, and may deliver MAC SDUs to an upper layer (e.g., the RLC layer 350C) . The RLC layer 350C may decode RLC PDUs and may deliver RLC SDUs to an upper layer (e.g., the SLAP layer 340C) . The SLAP layer 340C may decode SLAP PDUs and may deliver SLAP SDUs to an upper layer (e.g., the PDCP layer 330C) . The PDCP layer 330C may decode PDCP PDUs and may deliver PDCP SDUs to an upper layer (e.g., the SDAP layer 320C) . The SDAP layer 320C may decode SDAP PDUs and may deliver SDAP SDUs to an upper layer (e.g., an IP layer, which is not shown in FIG. 3) .

For the UE-to-UE relay, different bearers are distinguished on the SLAP layer by different logical channel IDs (LCIDs) . An LCID may identify the logical channel (LCH) instance of a corresponding MAC SDU. Since an LCH and a bearer may have a certain mapping relationship (e.g., a one-to-one correspondence) , a bearer can be identified by an LCID. The SLAP layer may support functions such as bearer mapping and routing. As can be seem from FIG. 3, SLAP 340B' and SLAP 340C between the relay UE 201B and UE 201C may identify the source transmitting UE (e.g., UE 201A) and the corresponding bearer.

It should be appreciated by persons skilled in the art that although the protocol stack of the UE 201A and the receiving protocol stack of the UE 201B in FIG. 3 do not show an SLAP layer, it is contemplated that these two protocol stacks may include respective SLAP layers, the function of which can be readily comprehended by persons skilled in the art based on the present disclosure.

FIG. 4 illustrates a schematic diagram of a wireless communication system 400 in accordance with some embodiments of the present application.

As shown in FIG. 4, the wireless communication system 400 may include one BS (e.g., BS 402) and some UEs (e.g., UE 401A and UE 301B) . UE 401B may be within the coverage of BS 402, and UE 401A may be out-of-coverage. Although a specific number of UEs and BS are depicted in FIG. 4, it is contemplated that any number of UEs may be included in the wireless communication system 400.

The wireless communication system 400 may support sidelink communications. For example, UE 401B may be in sidelink communication with UE 401A. Although UE 401A is outside the coverage of BS 402, UE 401A may access BS 402 via UE 401B. UE 401A and BS 402 may thus establish an RRC connection therebetween, and UE 401A may have RRC states, such as an RRC_IDLE state, an RRC_INACTIVE state, and an RRC_CONNECTED state. In the context of the present application, a UE (e.g., UE 401B) , which functions as a relay between a UE and a BS, may be referred to a UE-to-network relay. It should be appreciated by persons skilled in the art that although a single relay node between UE 401A and BS 402 is depicted in FIG. 4, it is contemplated that any number of relay nodes may be included.

After establishing a connection via UE 401B, a User Plane (UP) protocol stack may be established at UE 401A, UE 401B and BS 402. FIG. 5 illustrates an example block diagram of a protocol stack for layer 2 relaying in accordance with some embodiments of the present application.

Referring to FIG. 5, a User Plane (UP) protocol stack 500 may be established at UE 401A, UE 401B and BS 402 to support layer 2 (L2) relaying according to some embodiments of the present disclosure. UE 401A may connect to relay UE 401B via a sidelink (e.g., a PC5 interface 573) . The Relay UE 401B may connect to BS 402 via a Uu interface 575.

The data flow of the protocol stack 500 is described below.

As illustrated in FIG. 5, the UE 401A protocol stack may include a service data adaptation protocol (SDAP) layer 520A, a packet data convergence protocol (PDCP) layer 530A, a radio link control (RLC) layer 550A, a medium access control (MAC) layer 560A, and a physical (PHY) layer 570A.

At the UE 401A, a higher layer (e.g., Internet Protocol (IP) layer, which is not shown in FIG. 5) may submit IP Packets to the SDAP layer 520A. The SDAP layer 520A may add SDAP headers to SDAP SDUs received from the higher layer to form SDAP Packet Data Units (PDUs) , and may submit the SDAP PDUs to a lower layer (e.g., the PDCP layer 530A) . The PDCP layer 530A may add PDCP headers to PDCP SDUs received from the SDAP layer 520A, and may submit PDCP PDUs to a lower layer (e.g., the RLC layer 550A) . The RLC layer 550A may add RLC headers to RLC SDUs received from the PDCP layer 530A, and may submit RLC PDUs to a lower layer (e.g., the MAC layer 560A) . The MAC layer 560A may add MAC headers to MAC SDUs received from the RLC layer 550A to form MAC PDUs, and may submit the MAC PDUs to a lower layer (e.g., the PHY layer 570A) . The PHY layer 570A may add information such as Cyclic Redundancy Check (CRC) information to Transport Blocks (TBs) corresponding to the MAC PDUs for transmission. Control information, such as sidelink control information, corresponding to the TBs may also be transmitted.

The UE 401B may include a receiving protocol stack and a transmitting protocol stack. The receiving protocol stack of the UE 401B may include an RLC layer 550B, an MAC layer 560B, and a PHY layer 570B. The transmitting protocol stack of the UE 401B may include a sidelink adaptation protocol (SLAP) layer 540B', an RLC layer 550B', an MAC layer 560B', and a PHY layer 570B'.

The UE 401B may receive data from the UE 401A. For example, at the receiving protocol stack of the UE 401B, the PHY layer 570B may receive and decode data from the UE 401A, and may deliver TBs decoded from the data to an upper layer (e.g., the MAC layer 560B) . The MAC layer 560B may decode MAC PDUs corresponding to the TBs, and may deliver MAC SDUs to an upper layer (e.g., the RLC layer 550B) . The RLC layer 550B may decode RLC PDUs received from the MAC layer 560B, and may deliver the decoded data (e.g., RLC SDUs) to the transmitting protocol stack of the UE 401B.

The transmitting protocol stack of the UE 401B may receive decoded data from the receiving protocol stack of the UE 401B. For example, the SLAP layer 540B' may receive decoded data from the receiving protocol stack of the UE 401B, and may encode it as SLAP PDUs to submit to a lower layer (e.g., RLC layer 550B') . The RLC layer 550B' may encode RLC SDUs from the SLAP layer 540B' as RLC PDUs to submit to a lower layer (e.g., MAC layer 560B') . The MAC layer 560B' may encode MAC SDUs from the RLC layer 550B' as MAC PDUs to submit to a lower layer (e.g., the PHY layer 570B') . The PHY layer 570B' may add information such as CRC to the TBs corresponding to the MAC PDUs for transmitting to a destination device (e.g., the BS 402) . Control information, such as sidelink control information, corresponding to the TBs may also be transmitted.

The BS 402 protocol stack may include an SDAP layer 520C, a PDCP layer 530C, an SLAP layer 540C, an RLC layer 550C, an MAC layer 560C, and a PHY layer 570C.

The BS 402 may receive data from the UE 401B. For example, the PHY layer 570C may receive and decode data from the UE 401B, and may deliver decoded TBs to an upper layer (e.g., the MAC layer 560C) . The MAC layer 560C may decode MAC PDUs corresponding to the TBs, and may deliver MAC SDUs to an upper layer (e.g., the RLC layer 550C) . The RLC layer 550C may decode RLC PDUs and may deliver RLC SDUs to an upper layer (e.g., the SLAP layer 540C) . The SLAP layer 540C may decode SLAP PDUs and may deliver SLAP SDUs to an upper layer (e.g., the PDCP layer 530C) . The PDCP layer 530C may decode PDCP PDUs and may deliver PDCP SDUs to an upper layer (e.g., the SDAP layer 520C) . The SDAP layer 520C may decode SDAP PDUs and may deliver SDAP SDUs to an upper layer (e.g., an IP layer, which is not shown in FIG. 5) .

For the UE-to-network relay, different bearers are distinguished on the SLAP layer by different logical channel IDs (LCIDs) . The SLAP layer may support functions such as bearer mapping and routing. As can be seem from FIG. 5, SLAP 540B' and SLAP 540C between the relay UE 401B and BS 402 (i.e., over the Uu interface) may identify the remote UE (e.g., UE 401A) and the corresponding bearer.

It should be appreciated by persons skilled in the art that although the protocol stack of the UE 401A and the receiving protocol stack of the UE 401B in FIG. 5 do not show an SLAP layer, it is contemplated that these two protocol stacks may include respective SLAP layers, the function of which can be readily comprehended by persons skilled in the art based on the present disclosure.

In the

protocol stack

300 or 500, an SLAP layer is introduced. For the relaying process to function properly, the SLAP PDU may include certain information. Embodiments of the present application provide solutions for designing the PDU format of the SLAP layer.

There are some principles for designing the data format of the SLAP layer.

For example, in the example of FIG. 2 where UE 201A (source UE) has established a connection with UE 201C (destination) via UE 201B (UE-to-UE relay) , in the first hop link (i.e., the link between UE 201A and UE 201B) , the identity of the destination should be indicated in the SLAP layer (if established at the source UE) , for example, in the header of an SLAP PDU. The identity of the source UE can be absent from the SLAP layer since it has been included in the header of a lower layer (e.g., MAC layer or PHY layer) . Moreover, depending on the mapping relationship of the LCHs between the source UE and the relay UE, a corresponding LCID of the source UE may be optionally included in the header of the SLAP PDU. For example, when the LCHs of the source UE and the relay UE may have a one-to-one correspondence, the LCID of the source UE may be eliminated. In the case where a source UE does not establish an SLAP layer, the above-mentioned information (e.g., the identity of the destination, the identity of the source UE, and the corresponding LCID) may be included in the data at another layer (e.g., the MAC layer) . In the second hop link (i.e., the link between UE 201B and UE 201C) , the identity of the destination and the identity of the source UE should be indicated in the SLAP layer (e.g., the header of an SLAP PDU) , and the LCID of the source UE may be optional, for example, depending on the mapping relationship of the LCHs between the source UE and the relay UE.

In the case of a multi-relay UE-to-UE scenario (that is, a UE may hop through more than one relay node (e.g., UE) to reach a destination UE) , from the second hop link to the last hop link, the identity of the destination and the identity of the source UE should be indicated in the data at the SLAP layer (e.g., the header of an SLAP PDU) , while the LCID of the source UE may be optional.

For example, in the example of FIG. 4 where UE 401A (source UE) has established a connection with BS (destination) via UE 401B (UE-to-network relay) , the identity of the source UE may need to be indicated in the SLAP layer (e.g., the header of an SLAP PDU) . For example, in the second hop link (i.e., the link between UE 401B and BS 402) , the identity of the source UE should be indicated in data at the SLAP layer while in the first hop link (i.e., the link between UE 401A and UE 401B) , the identity of the source UE can be absent from the SLAP layer (if established at the source UE) since it has been included in the header of a lower layer (e.g., MAC layer or PHY layer) . Moreover, as mentioned above, depending on the mapping relationship of the LCHs between the source UE and the relay UE, the LCID of the source UE may be optional. Similarly, in the case where a source UE does not establish an SLAP layer, the above-mentioned information (e.g., the corresponding LCID) may be included in the data at another layer (e.g., MAC layer) .

In the case of a two-hop UE-to-network scenario, the identity of the destination may not need since the relay node would know that the destination is the serving BS of the relay node. In the case of a multi-relay UE-to-network scenario (that is, a UE may hop through more than one relay node to reach a BS) , the identity of the destination may need to be indicated in the SLAP layer (e.g., the header of an SLAP PDU) . For example, from the second hop link to the last hop link, the identity of the destination may need to be indicated.

According to the above principles, several types of PDU format may be needed at the SLAP layer. For example, in the case of a two-hop UE-to-network relay scenario, the PDU format of the SLAP layer may need to include information related to the identity of the source and optionally the corresponding LCID (hereinafter, "PDU format type 1" ) . In the case of a two-hop UE-to-UE relay scenario, the PDU format of the SLAP layer used in the first hop may need to include information related to the identity of the destination and optionally the corresponding LCID (hereinafter, "PDU format type 2" ) ; and the PDU format of the SLAP layer used in the second hop may need to include information related to the identity of the source, the identity of the destination, and optionally the LCID (hereinafter, "PDU format type 3" ) .

In some embodiments of the present application, separate PDU formats may be employed at the SLAP layer (hereinafter, "separate PDU formats scheme" ) . The header of an SLAP PDU may include an indicator to indicate the types of the PDU format (e.g., PDU format type 1, PDU format type 2, and PDU format type 3) . The header of the SLAP PDU may further include corresponding information according to the PDU format type indicated by the indicator.

For example, the header of the SLAP PDU may include an indicator indicating a destination of the SLAP PDU. The indicator may include one bit indicating whether the destination is a BS or a UE. By employing such indicator, PDU formats (e.g., PDU format type 2 and PDU format type 3) for the UE-to-UE relay scenario can be distinguished from the PDU format (e.g., PDU format type 1) for UE-to-network relay scenario.

In some other examples, the header of the SLAP PDU may include an indicator to indicate respective types of PDU format, and the indicator may include more than one bit. For example, the indicator being "0" may denote PDU format type 1, the indicator being "1" may denote PDU format type 2, and the indicator being "2" may denote PDU format type 3.

In some embodiments of the present application, a common PDU format may be employed to accommodate all possible types of PDU format (hereinafter, "common PDU format scheme" ) . For example, the header of an SLAP PDU may include information related to a source (e.g., an indicator) . The information related to a source may indicate whether the identity of the source is included or not and whether a reduce version or a full version of the identity of the source is included. For instance, the information related to a source may indicate one of: the header of the SLAP PDU does not include an identity of a source UE; the header of the SLAP PDU includes a reduced identity of a source UE; and the header of the SLAP PDU includes a full identity of a source UE. The header of the SLAP PDU may further include a reduced (or full) identity of the source UE when the information related to a source indicates that the header of the SLAP PDU includes a reduced (or full) identity of a source UE. The information related to a source may include 2 bits.

An upper layer (i.e., a layer higher than an RRC layer) of a UE may designate a layer-2 identity of the UE, which may include 24 bits. This 24 bits UE identity may be referred to as a full identity of the UE. A reduced identity of the UE may include a part (10 bits) of the 24 bits layer-2 UE identity.

In some embodiments of the present application, the header of the SLAP PDU may also include information related to a destination of the SLAP PDU. The information related to the destination of the SLAP PDU may indicate whether the identity of the source is a BS or a UE. For instance, the information related to the destination of the SLAP PDU may indicate one of: an identity of a UE, an identity of a BS (e.g., a cell ID) , and a predefined value indicating that the destination is either a UE or a BS. In some embodiments of the present application, the header of the SLAP PDU may not include information related to the destination of the SLAP PDU, which may implicitly suggest that the destination of the SLAP PDU is a BS.

In some embodiments of the present application, the header of the SLAP PDU may also include an identity of a logical channel.

FIG. 6 illustrates a flow chart of an exemplary procedure 600 of performing wireless communication via a relay node according to some embodiments of the present disclosure. Details described in all of the foregoing embodiments of the present disclosure are applicable for the embodiments shown in FIG. 6.

The exemplary procedure 600 shows a procedure of a source UE (e.g., UE 601A) communicating with a destination device (e.g., destination device 602) via a relay node (e.g., UE 601B) . In some examples, UE 601A may function as UE 201A in FIGS. 2 and 3, or UE 401A in FIGS. 4 and 5. UE 601B may function as a relay node such as UE 201B in FIGS. 2 and 3 or UE 401B in FIGS. 4 and 5. Destination device 602 may function as UE 201C in FIGS. 2 and 3, or BS 402 in FIGS. 4 and 5.

Referring to FIG. 6, in step 611, UE 601A may establish a connection with destination device 602 via UE 601B. As described above, after completing such connection establishment, UE 601 can transmit data to or receive data from destination device 602 via UE 601B using protocol stack including the SLAP layer (e.g., protocol stack 300 in FIG. 3 or protocol stack 500 in FIG. 5) . For example, UE 601 may generate the data (data #1) to be transmitted according to the following methods.

In some embodiments of the present disclosure, separate PDU formats scheme may be employed at the SLAP layer. In this scheme, a header of an SLAP PDU may include an indicator indicating a destination of data #1. For example, the indicator may indicate whether the destination is a UE or a BS. The header of the SLAP PDU may further include a destination field indicating an identity of the destination.

For example, in the exemplary procedure 600, UE 601A may generate an SLAP PDU (SLAP PDU #A1) at the SLAP layer of the protocol stack of UE 601A. The header of SLAP PDU #A1 may include an indicator indicating whether the destination is a UE or a BS. In the case that the indicator indicates that the destination is a UE (e.g., the destination device 602 being a UE) , the header of SLAP PDU #A1 may further include a destination field indicating the identity of the destination UE. The header of SLAP PDU #A1 may optionally indicate an identity of an LCH between UE 601A and a relay node (e.g., UE 601B) . The LCH corresponds to a bearer (e.g., a signaling radio bearer (SRB) or a data radio bearer (DRB) ) on which SLAP PDU #A1 is to be transmitted.

In some embodiments of the present disclosure, common PDU format scheme may be employed at the SLAP layer. In this scheme, a header of the SLAP PDU may include information related to a source (e.g., an indicator) . The information related to a source may indicate whether the identity of the source of data #1 is included or not and whether a reduce version or a full version of the identity of the source is included.

For example, in the exemplary procedure 600, UE 601A may generate an SLAP PDU (SLAP PDU #B1) at the SLAP layer of the protocol stack of UE 601A. The source of SLAP PDU #B1 is UE 601A, so the information related to a source in the header of SLAP PDU #B1 may indicate that the header of SLAP PDU #B1 does not include an identity of the source. The reason why identity of the source can be absent is that it has been included in the header of a lower layer (e.g., MAC layer or PHY layer) . Alternatively, the information related to a source in the header of SLAP PDU #B1 may indicate that the header of SLAP PDU #B1 includes an identity of the source, and the header of SLAP PDU #B1 may include a source field indicating the identity of UE 601A. For example, the information related to a source in the header of SLAP PDU #B1 may indicate that the header of SLAP PDU #B1 includes a reduce (or a full) identity of the source, and the header of SLAP PDU #B1 may include a reduce (or a full) identity of UE 601A.

The header of SLAP PDU #B1 may optionally indicate an identity of an LCH between UE 601A and a relay node (e.g., UE 601B) . The LCH corresponds to a bearer (e.g., a signaling radio bearer (SRB) or a data radio bearer (DRB) ) on which SLAP PDU #B1 is to be transmitted.

Moreover, as mentioned above, in the common PDU format scheme, a header of an SLAP PDU may not include information related to a destination, which suggests that the destination of the SLAP PDU is a BS. The header of the SLAP PDU may include information related to a destination, which may include one of: an identity of a UE, an identity of a BS (e.g., cell ID) , and a predefined value indicating that the destination of the SLAP PDU is a BS. In the exemplary procedure 600, if assuming that destination device 602 is a BS, SLAP PDU #B1 may not include information related to a destination, or may include an identity of the destination device 602 or a predefined value indicating that the destination is a BS. If assuming that destination device 602 is a UE, SLAP PDU #B1 may include an identity of destination device 602.

UE 601A may then submit the generated SLAP PDU (e.g., SLAP PDU #A1 or SLAP PDU #B1) to a lower layer for transmission. In step 615, UE 601A may transmit the data (data #1) associated with the generated SLAP PDU to UE 601B.

After receiving the data from UE 601A, UE 601B may identify the destination of the data. When the destination of the data is UE 601B, UE 601B may process or decode the data. When the destination of the data is not UE 601B, but is a BS or another UE, 601B may transmit the data to a suitable next-hop node. For example, UE 601B may perform the following operations after receiving the data from UE 601A.

In some embodiments of the present disclosure, separate PDU formats scheme may be employed at the SLAP layer. UE 601B may determine whether a destination of data #1 is UE 601B or not. For example, UE 601B may decode the data received from UE 601A into an SLAP PDU (SLAP PDU #A1) at the SLAP layer of the protocol stack of UE 601B. The header of SLAP PDU #A1 may include an indicator indicating a destination of the SLAP PDU #A1. For example, the indicator may indicate whether the destination is a UE or a BS. In the case that the indicator indicates that the destination is a UE, the header of SLAP PDU #A1 may further include a destination field indicating the identity of the destination UE. The header of SLAP PDU #A1 may optionally indicate an identity of an LCH between UE 601A and UE 601B.

Therefore, UE 601B may determine the destination of the data based on the header of SLAP PDU #A1. In the case that UE 601B determines that the destination of data #1 is not UE 601B, UE 601B may add a new header to data #1 to construct another data (data #2) . For example, UE 601B may construct a SLAP PDU (SLAP PDU #A2) based on SLAP PDU #A1 by removing the header from SLAP PDU #A1 and adding a new header to the SDU of SLAP PDU #A1.

In the case that the destination of SLAP PDU #A1 is a UE, a header of SLAP PDU #A2 may include an indicator indicating that the destination of data #2 or SLAP PDU #A2 is a UE. The header of SLAP PDU #A2 may further include a source field indicating the identity of UE 601A and a destination field indicating the identity of the destination UE (e.g., destination device 602) . The header of SLAP PDU #A2 may optionally indicate the identity of a corresponding LCH, e.g., the one on which SLAP PDU #A1 is transmitted.

In the case that the destination of SLAP PDU #A1 is a BS, a header of SLAP PDU #A2 may include an indicator indicating that the destination of the SLAP PDU #A2 is a BS. The header of SLAP PDU #A2 may further include a source field indicating the identity of UE 601A. The identity of UE 601A may be a layer-2 identity or a reduced layer-2 identity. The header of SLAP PDU #A2 may optionally indicate the identity of a corresponding LCH, e.g., the one on which SLAP PDU #A1 is transmitted.

In some embodiments of the present disclosure, common PDU format scheme may be employed at the SLAP layer. UE 601B may determine whether a destination of data #1 is UE 601B or not. For example, UE 601B may decode the data received from UE 601A into an SLAP PDU (SLAP PDU #B1) at the SLAP layer of the protocol stack of UE 601B. The header of SLAP PDU #B1 may include information related to a source. For example, the information related to a source may indicate that the header of SLAP PDU #B1 does not include an identity of the source. The header of SLAP PDU #B1 may optionally indicate an identity of an LCH between UE 601A and UE 601B.

UE 601B may determine whether a destination of data #1 is UE 601B or not. For example, UE 601B may determine whether the header of SLAP PDU #B1 includes information related to a destination or not. When it is determined that the header of SLAP PDU #B1 does not include information related to a destination, UE 601B may determine that the destination of data #1 is a BS. UE 601B may determine that the header of SLAP PDU #B1 includes information related to a destination, which may include one of: an identity of a UE, an identity of a BS (e.g., cell ID) , and a predefined value indicating that the destination is a BS. For example, the header of SLAP PDU #B1 may include the identity of destination device 602.

Therefore, UE 601B may determine the destination of data #1 based on the header of SLAP PDU #B1. In the case that UE 601B determines that the destination of data #1 is not UE 601B, UE 601B may add a new header to data #1 to construct another data (data #2) . For example, UE 601B may construct a SLAP PDU (SLAP PDU #B2) based on SLAP PDU #B1 by removing the header from SLAP PDU #B1 and adding a new header to the SDU of SLAP PDU #B1.

In the case that the destination of SLAP PDU #B1 is a UE, for example, the header of SLAP PDU #B1 includes an identity of a UE (e.g., the identity of destination device 602 assuming that destination device 602 is a UE) , a header of SLAP PDU #B2 may include information related to a destination of data #2. For example, header of SLAP PDU #B2 may include the identity of destination device 602.

The header of SLAP PDU #B2 may further include information related to a source indicating that the header of SLAP PDU #B2 includes a reduced or a full identity of a source UE. Accordingly, the header of SLAP PDU #B2 may further include the reduced or full identity of the source UE (e.g., UE 601A) . The header of SLAP PDU #B2 may optionally indicate the identity of a corresponding LCH, e.g., the one on which SLAP PDU #B1 is transmitted.

In the case that the destination of SLAP PDU #A1 is a BS, a header of SLAP PDU #B2 may or may not include information related to a destination of data #2. For example, the header of SLAP PDU #B2 may include an identity of a BS (as indicated in the header of SLAP PDU #B1) or a predefined value indicating that the destination is a BS. The header of SLAP PDU #B2 may further include information related to a source indicating that the header of SLAP PDU #B2 includes a reduced (or a full) identity of a source UE (e.g., UE 601A) . The header of SLAP PDU #B2 may further include the reduced (or full) identity of UE 601A. The header of SLAP PDU #B2 may optionally indicate the identity of a corresponding LCH, e.g., the one on which SLAP PDU #B1 is transmitted.

UE 601B may then submit the generated SLAP PDU (e.g., SLAP PDU #A2 or SLAP PDU #B2) to a lower layer for transmission. In step 617, UE 601B may transmit data #2 associated with the generated SLAP PDU to destination device 602.

After receiving the data from UE 601B, destination device 602 may process or decode the received data. For example, in some embodiments of the present disclosure, separate PDU formats scheme may be employed at the SLAP layer. Destination device 602 may decode the received data into SLAP PDU #A2.

In the case that destination 602 is a UE, a header of SLAP PDU #A2 may include an indicator indicating that a destination of the data or SLAP PDU #A2 is a UE. The header of SLAP PDU #A2 may further include a source field indicating an identity of UE 601A, and a destination field indicating the identity of destination device 602. The header of SLAP PDU #A2 may optionally indicate the identity of an LCH between UE 601A and UE 601B.

In the case that destination 602 is a BS (e.g., the serving BS of UE 601B) , a header of SLAP PDU #A2 may include an indicator indicating that a destination of SLAP PDU #A2 is a BS. The header of SLAP PDU #A2 may further include a source field indicating an identity of UE 601A. The header of SLAP PDU #A2 may optionally indicate the identity of an LCH between UE 601A and UE 601B.

In some embodiments of the present disclosure, common PDU format scheme may be employed at the SLAP layer. Destination device 602 may decode the received data into SLAP PDU #B2.

In the case that destination 602 is a UE, a header of SLAP PDU #B2 may include information related to a source indicating that the header of SLAP PDU #B2 includes a reduced (or a full) identity of a source UE. Accordingly, the header of SLAP PDU #B2 may further include a reduced (or a full) identity of UE 601A. The header of SLAP PDU #B2 may also include information related to a destination of the data or SLAP PDU #B2. For example, the header of SLAP PDU #B2 may indicate an identity of destination 602. The header of SLAP PDU #B2 may optionally indicate the identity of an LCH between UE 601A and UE 601B.

In the case that destination 602 is a BS (e.g., the serving BS of UE 601B) , a header of SLAP PDU #B2 may include information related to a source indicating that the header of SLAP PDU #B2 includes a reduced (or a full) identity of a source UE. Accordingly, the header of SLAP PDU #B2 may further include a reduced (or a full) identity of UE 601A. The header of SLAP PDU #B2 may optionally indicate the identity of an LCH between UE 601A and UE 601B. The header of SLAP PDU #B2 may not include information related to a destination of the data or SLAP PDU #B2. Alternatively, the header of SLAP PDU #B2 may include information related to a destination of SLAP PDU #B2. For example, the header of SLAP PDU #B2 may indicate the identity of destination 602 or a predefined value indicating that the destination is a BS.

It should be appreciated by persons skilled in the art that although a single relay node (UE 601B) between UE 601A and destination device 602 is depicted in FIG. 6, it is contemplated that any number of relay nodes may be included.

FIG. 7 illustrates an example block diagram of an apparatus 700 according to some embodiments of the present disclosure. The apparatus 700 may be a BS or a UE.

eferring to FIG. 7, the apparatus 700 may include at least one non-transitory computer-readable medium 702, at least one receiving circuitry 704, at least one transmitting circuitry 706, and at least one processor 708. In some embodiment of the present application, at least one receiving circuitry 704 and at least one transmitting circuitry 706 and be integrated into at least one transceiver. The at least one processor 708 may be coupled to the at least one non-transitory computer-readable medium 702, the at least one receiving circuitry 704 and the at least one transmitting circuitry 706. In some embodiments of the present disclosure, the apparatus 700 may further include an input device, a memory, and/or other components.

In some embodiments of the present disclosure, the at least one non-transitory computer-readable medium 702 may have stored thereon computer-executable instructions to cause the at least one processor 708 to implement the operations, steps, or methods with respect to the UEs as described above. For example, the computer-executable instructions, when executed, cause the at least one processor 708 interacting with the at least one receiving circuitry 704 and the at least one transmitting circuitry 706, so as to perform the steps with respect to the UEs depicted in FIGS. 1-6.

In some examples, the at least one transmitting circuitry 706 may receive a first data on a sidelink from a first UE. The at least one processor 708 may determine whether a destination of the first data is the apparatus 700 or not. The at least one processor 708 may remove a header of the first data and add a new header to the first data to construct a second data at, for example, a sidelink adaptation protocol (SLAP) layer, when the destination of the first data is not the apparatus 700. The header of the first data and the header of the second data may include information as described above with respect to FIGS. 2-6. The at least one transmitting circuitry 706 may transmit the second data to the destination of the first data. Otherwise, when it is determined that the destination of the first data is the apparatus 700, the at least one processor 708 may deliver the first data to an upper layer for further processing.

In some embodiments of the present disclosure, the at least one non-transitory computer-readable medium 702 may have stored thereon computer-executable instructions to cause the at least one processor 708 to implement the operations, steps, or methods with respect to the BSs as described above. For example, the computer-executable instructions, when executed, cause the at least one processor 708 interacting with the at least one receiving circuitry 704 and the at least one transmitting circuitry 706, so as to perform the steps with respect to the BSs depicted in FIGS. 1 and 4-6.

Those having ordinary skill in the art would understand that the steps of a method described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. Additionally, in some aspects, the steps of a method may reside as one or any combination or set of codes and/or instructions on a non-transitory computer-readable medium, which may be incorporated into a computer program product.

While this disclosure has been described with specific embodiments thereof, it is evident that many alternatives, modifications, and variations may be apparent to those skilled in the art. For example, various components of the embodiments may be interchanged, added, or substituted in the other embodiments. Also, all of the elements of each figure are not necessary for the operation of the disclosed embodiments. For example, one of ordinary skill in the art of the disclosed embodiments would be enabled to make and use the teachings of the disclosure by simply employing the elements of the independent claims. Accordingly, embodiments of the disclosure as set forth herein are intended to be illustrative, not limiting. Various changes may be made without departing from the spirit and scope of the disclosure.

In this document, the terms "includes" , "including" , or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "a" , "an" , or the like does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that includes the element. Also, the term "another" is defined as at least a second or more. The term "having" and the like, as used herein, are defined as "including. "

Claims

A method, comprising:

receiving a first data, at a second user equipment (UE) , on a sidelink from a first UE;

determining whether a destination of the first data is the second UE or not; adding a second header to the first data at a sidelink adaptation protocol (SLAP) layer to construct a second data when the destination of the first data is not the second UE, wherein the second header of the second data comprises an indicator indicating the destination of the first data; and

transmitting the second data to the destination of the first data.
The method of Claim 1, wherein the destination of the first data is a UE or a base station (BS) .
The method of Claim 1, wherein the first data comprises a first header comprising an indicator indicating that the destination of the first data is a UE, and the first header of the first data further comprises a destination field indicating an identity of a third UE.
The method of Claim 1, wherein the first data comprises a first header comprising an identity of a logical channel between the first UE and the second UE.
The method of Claim 3, further comprising:

removing the first header from the first data in response to the reception of the first data,

wherein the indicator in the second header indicates that the destination of the second data is a UE.
The method of Claim 3, wherein the second header of the second data further comprises a source field indicating the identity of the first UE and a destination field indicating the identity of the third UE.
The method of Claim 1, wherein the first data comprises a first header comprising an indicator indicating that the destination of the first data is a BS.
The method of Claim 7, further comprising:

removing the first header from the first data in response to the reception of the first data;

wherein the indicator in the second header indicates that the destination of the second data is a BS, and the second header of the second data further comprises a source field indicating the identity of the first UE.
The method of Claim 6 or 8, wherein the identity of the first UE is a layer-2 identity or a reduced layer-2 identity.
The method of Claim 1, wherein the second header of the second data further comprises an identity of a logical channel between the first UE and the second UE.
A method, comprising:

receiving a first data, at a second user equipment (UE) on a sidelink from a first UE;

determining whether a destination of the first data is the second UE or not;

adding a second header to the first data at a sidelink adaptation protocol (SLAP) layer to construct a second data when the destination of the first data is not the second UE, wherein the second header of the second data comprises information related to a source; and

transmitting the second data to the destination of the first data.
The method of Claim 11, wherein determining whether a destination of the first data is the second UE or not comprises:

determining whether a first header of the first data comprises information related to the destination of the first data; and

in the case that the first header of the first data does not comprise the information related to the destination of the first data, determining that the destination of the first data is a base station (BS) .
The method of Claim 11, wherein a first header of the first data comprises information related to the destination of the first data, and the information related to the destination of the first data comprises one of the following:

an identity of a UE,

an identity of a BS, and

a predefined value indicating that the destination of the first data is a BS.
The method of Claim 12 or 13, wherein the first header of the first data comprises information related to a source indicating one of the following:

the first header of the first data does not include an identity of a source UE;

the first header of the first data includes a reduced identity of a source UE; and

the first header of the first data includes a full identity of a source UE.
The method of Claim 11, wherein a first header of the first data further comprises an identity of a logical channel between the first UE and the second UE.
The method of Claim 14, wherein the information related to the destination of the first data comprises an identity of a third UE, and the method further comprises:

removing the first header from the first data in response to the reception of the first data;

wherein the second header of the second data further comprises information related to a destination of the second data comprising the identity of the third UE; and

wherein the information related to a source in the second header indicates that the second header of the second data includes a reduced or full identity of the source UE, and the second header of the second data further comprises a reduced or full identity of the source UE.
The method of Claim 16, wherein the source UE is the first UE.
The method of Claim 11, wherein the second header of the second data further comprises an identity of a logical channel between the first UE and the second UE.
The method of Claim 14, wherein in the case that the destination of the first data is a BS, the method further comprises:

removing the first header from the first data in response to the reception of the first data;

wherein the second header of the second data does not comprise information related to a destination of the second data, or the second header of the second data comprises information related to a destination of the second data comprising an identity of a BS or a predefined value indicating that the destination of the second data is a BS; and

wherein the information related to a source in the second header indicates that the second header of the second data includes a reduced or full identity of the source UE, and the second header of the second data further comprises a reduced or a full identity of the source UE.
The method of Claim 19, wherein the source UE is the first UE.
The method of Claim 11, wherein the second header of the second data further comprises an identity of a logical channel between the first UE and the second UE.
A method, comprising:

constructing a first data at a sidelink adaptation protocol (SLAP) layer of a first user equipment (UE) , wherein a header of the first data comprises an indicator indicating a destination of the first data;

submitting the first data to a lower layer for transmission; and

transmitting the first data on a sidelink to a second UE.
The method of Claim 22, wherein the destination of the first data is a UE or a base station (BS) .
The method of Claim 22, wherein in the case that the indicator indicates that the destination of the first data is a UE, the header of the first data further comprises a destination field indicating an identity of a third UE.
The method of Claim 22, wherein the indicator indicates that the destination of the first data is a BS.
The method of Claim 24 or 25, wherein the header of the first data further comprises an identity of a logical channel between the first UE and the second UE.
A method, comprising:

constructing a first data at a sidelink adaptation protocol (SLAP) layer of a first user equipment (UE) , wherein a header of the first data comprises information related to a source;

submitting the first data to a lower layer for transmission; and

transmitting the first data on a sidelink to a second UE.
The method of Claim 27, wherein in the case that the header of the first data does not comprise information related to a destination of the first data, the destination of the first data is a base station (BS) .
The method of Claim 27, wherein the header of the first data further comprises information related to a destination of the first data, and the information related to the destination of the first data comprises one of the following:

an identity of a UE,

an identity of a BS, and

a predefined value indicating that the destination of the first data is a BS.
The method of Claim 28 or 29, wherein the information related to a source in the first header indicates one of the following:

the header of the first data does not include an identity of a source UE;

the first header of the first data includes a reduced identity of a source UE; and

the first header of the first data includes a full identity of a source UE.
The method of Claim 27, wherein the header of the first data further comprises an identity of a logical channel between the first UE and the second UE.
A method, comprising:

receiving a second data at a third user equipment (UE) on a sidelink from a second UE; and

in the case that a header of the second data comprises an indicator indicating that a destination of the second data is a UE and a destination field indicating the identity of the third UE, determining that the destination of the second data is the third UE.
The method of Claim 32, wherein the header of the second data further comprises a source field indicating an identity of a source UE.
The method of Claim 33, wherein the header of the second data further comprises an identity of a logical channel between the source UE and the second UE.
A method, comprising:

receiving a second data at a third user equipment (UE) on a sidelink from a second UE, wherein a header of the second data comprises information related to a source indicating that the header of the second data comprises a reduced or a full identity of a source UE, and the header of the second data further comprises a reduced or a full identity of the source UE; and

in the case that the header of the second data comprises an identity of the third UE, determining that the destination of the second data is the third UE.
The method of Claim 35, wherein the header of the second data further comprises an identity of a logical channel between the source UE and the second UE.
A method, comprising:

receiving a second data at a base station (BS) from a second user equipment (UE) ;

wherein a header of the second data comprises an indicator indicating that a destination of the second data is a BS and a source field indicating an identity of a source UE, or

wherein the header of the second data comprises information related to a source indicating that the header of the second data comprises a reduced or a full identity of a source UE, and the header of the second data further comprises a reduced or a full identity of the source UE.
The method of Claim 37, wherein the header of the second data further comprises an identity of a logical channel between the source UE and the second UE.
The method of Claim 37, wherein the header of the second data further indicates a destination of the second data.
An apparatus, comprising:

at least one non-transitory computer-readable medium having stored thereon computer-executable instructions;

at least one receiving circuitry;

at least one transmitting circuitry; and

at least one processor coupled to the at least one non-transitory computer-readable medium, the at least one receiving circuitry and the at least one transmitting circuitry,

wherein the computer-executable instructions cause the at least one processor to implement the method of any of Claims 1-36.
An apparatus, comprising:

at least one non-transitory computer-readable medium having stored thereon computer-executable instructions;

at least one receiving circuitry;

at least one transmitting circuitry; and

at least one processor coupled to the at least one non-transitory computer-readable medium, the at least one receiving circuitry and the at least one transmitting circuitry,

wherein the computer-executable instructions cause the at least one processor to implement the method of any of Claims 37-39.