KR102345929B1 - Methods of handling different protocol data unit types in device to device communication sysytem - Google Patents

Abstract

Disclosed are a method and a system for distinguishing various PDUs (Protocol Data Units) in a D2D communication network. According to various embodiments of the present invention, unique data/values are assigned to the types of PDUs to be distinguished by the transmitting user equipment and transmitted to the destination. At the receiving end, the receiving user equipment distinguishes the received various types of PDU packets based on the collected data and associated unique data. In addition, the received PDU data is processed based on the appropriate packet processing function matching the PDU type of the received PDU data.

Description

Method of processing various PDU (Protocol Data Unit) types in a device-to-device communication system

Embodiments of the present invention relate to a device-to-device (D2D) communication system, and more particularly, to processing various PDUs (Protocol Data Units) in a D2D communication system.

Device-to-device (D2D) communication enables direct communication between different user equipments (UEs). During D2D communication, the transmitting D2D UE may send data packets to a group of D2D UEs, broadcast data packets to all D2D UEs, or send unicast data packets to a specific D2D UE. D2D communication between transmitter and receiver(s) is inherently connectionless, ie there is no connection establishment (or control message exchange) between transmitter and receiver before the transmitter starts transmitting data packets. During transmission, the transmitter includes the source ID and destination ID in the data packets. The source ID is set to the UE ID of the transmitter. The destination ID is the ID of the intended recipient of the transmitted packet. The destination ID indicates whether the packet is a broadcast packet, a unicast packet, or a packet destined for a group.

D2D communication may involve the transmission of various traffic types (eg, ARP, IP, etc.) to the same or different destination, and packets belonging to the various traffic types are different in the transmitting UE and the receiving UE involved in the D2D communication. should be dealt with At the transmitter, the upper layer (IP protocol) provides IP packets to the lower layer (PDCP/RLC) for transmission to one or more UEs. The lower layer processes the packet and transmits the processed packet over the D2D communication channel. The receiver receives the packet on the D2D communication channel. The lower layer (PDCP/RLC) processes the packet and sends it to the upper layer. A disadvantage of the existing D2D communication system is that upper and lower layers always identify a packet as an IP packet and process it accordingly. As a result, packet types cannot be exchanged between devices.

An object of the embodiments of the present invention is to distinguish various PDU data types based on at least one data indicating the type of PDU data.

In various embodiments of the present invention, a processing method for distinguishing between at least two types of PDUs (Protocol Data Units) in a device-to-device (D2D) communication network includes receiving at least one by a transmitting UE of the D2D communication network. transmitting at least one PDU to the UE; identifying, by the receiving UE, a PDU type of the at least one PDU received from the transmitting UE, wherein the PDU type is identified based on unique data in a header of the at least one received PDU; and processing, by the receiving UE, the at least one received PDU using at least one data processing function, wherein the data processing function is selected based on the PDU type of the PDU. can

In various embodiments of the present invention, in a device-to-device (D2D) communication network, a system for distinguishing between at least two types of PDUs (Protocol Data Units), by a transmitting UE of the D2D communication network, includes at least one send at least one PDU to the receiving UE; identify, by the receiving UE, a PDU type of the at least one PDU received from the transmitting UE, wherein the PDU type is identified based on unique data in a header of the at least one received PDU; and process, by the receiving UE, the at least one PDU using at least one data processing function, wherein the data processing function is selected based on the PDU type of the data.

According to various embodiments of the present invention, various PDU data types may be distinguished based on at least one data indicating the type of PDU data.

1 illustrates a block diagram of a Device to Device (D2D) communication network as disclosed in embodiments of the present invention.
2 is a block diagram illustrating components of a user equipment (UE) in a D2D communication network as disclosed in embodiments of the present invention.
3 is a flowchart illustrating steps involved in a procedure for transmitting at least one PDU data from a UE in a D2D communication network, as disclosed in embodiments of the present invention.
4 is a flowchart illustrating steps involved in a procedure for receiving at least one PDU data by a UE in a D2D communication network, as disclosed in embodiments of the present invention.
5 is an exemplary flowchart illustrating steps involved in a procedure of processing ARP (Address Resolution Protocol) packets differently from other types of packets by a transmitting UE in a D2D communication network, as disclosed in embodiments of the present invention; to be.
6 is an exemplary flowchart illustrating steps involved in a procedure for distinguishing ARP packets from other types of packets by a receiving UE in a D2D communication network, as disclosed in the embodiments of the present invention.
7 is an exemplary flowchart illustrating steps involved in a procedure for distinguishing non-Internet Protocol (IP) packets from IP packets by a receiving UE in a D2D communication network, as disclosed in embodiments of the present invention.

Embodiments and various configurations of the present invention and preferred details thereof are more fully described with reference to non-limiting embodiments illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as not to unnecessarily obscure embodiments of the present invention. The examples used herein are merely intended to aid in understanding how embodiments of the invention may be practiced and to enable those skilled in the art to practice embodiments of the invention. Accordingly, the examples should not be construed as limiting the scope of the embodiments of the present invention.

Embodiments of the present invention disclose a mechanism for distinguishing various PDU packets exchanged between user equipments (UEs) involved in device-to-device (D2D) communication. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments are now shown when reference is made to the drawings in which like reference characters refer to corresponding configurations throughout the drawings, in particular FIGS. 1-7 , consistently throughout the drawings.

1 illustrates a block diagram of a Device to Device (D2D) communication network as disclosed in embodiments of the present invention. The D2D communication network 100 includes at least two user devices 101 . One UE operates as the transmitting UE 101a and the other as the receiving UE 101b. In one embodiment, each UE 101 may be configured to transmit and receive data as part of communication with at least one counterpart UE 101 . The data may be user data, control data, and associated protocol data units (PDU). The UE 101 may be any device that may be configured to perform D2D communication with at least one counterpart UE. D2D communication involves the distinction between different PDU data types by the UE 101 . For example, the UE 101 may be a smart phone, a tablet, a wearable device, and the like.

The transmitting UE 101a may be configured to identify the data packet type (or PDU type) of the data to be transmitted to the receiving UE 101b . The transmitting UE 101a may be further configured to map data related to one or more PDU types to a D2D radio bearer. The transmitting UE 101a may be further configured to create a new D2D radio bearer for transmitting data to the receiving UE 101b when the D2D radio bearer does not yet exist. The transmitting UE 101a may be further configured to add a unique value/data to the PDU data type being transmitted. The transmitting UE 101a may be further configured to send data along with the unique value to the receiving UE 101b. For example, the PDU data type may be an Address Resolution Protocol (ARP) packet, that is, an ARP PDU, or an Internet Protocol (IP) packet, that is, an IP PDU, a discovery message, a control signaling message, a relay packet, or the like. By adding a unique value/data to at least one of the above-mentioned PDU types and sharing the data with the receiving UE 101b, the transmitting UE 101a will cause the receiving UE 101b to identify the type of the received PDU packet. can The transmitting UE 101a may be further configured to apply packet processing functions matching the type of the PDU, and then transmit the data to the selected destination (receiving UE 101b in this scenario).

The receiving UE 101b may be configured to receive data transmitted by the transmitting UE 101a. The receiving UE 101b further identifies the type of PDU data received based on the unique value/data included in the message. A lower layer in the protocol stack of the receiving UE 101b identifies the type of the received PDU, applies one or more packet processing functions matching the type of the received PDU, and sets the type of the received PDU to higher layers of the protocol stack. Indicate at least one of

2 is a block diagram illustrating components of a user equipment (UE) in a D2D communication network as disclosed in embodiments of the present invention. The UE 101 includes a transmitter module 201 , a packet discriminator module 202 , a receiver module 203 , and a higher layer protocol module 204 .

The transmitter module 201 may be configured to communicate with the packet discriminator module 202 and collect information pertaining to the type of packet to be transmitted. The transmitter module 201 further collects information pertaining to one or more packet processing functions matching the type of data to be transmitted. In addition, the transmitter module 201 applies the one or more packet processing functions to the data, and transmits the data to the receiving UE 101b. The transmitter module 201 may be configured to use any suitable communication technology and protocol to establish communication with the receiving UE 101b using the at least one suitable D2D radio bearer. The transmitter module 201 is configured to select a matching D2D radio bearer from available D2D radio bearers if a matching D2D radio bearer already exists, or to create a new D2D bearer if no matching D2D radio bearer exists. can

The packet discriminator 202 may be preferably configured to perform at least two main functions based on the role of the UE 101 belonging to the communication process. At the transmitting UE 101a, the packet identifier 202 identifies the PDU type and selects one or more packet processing functions matching the identified PDU type. The packet discriminator 202 further sends the PDU type and matching packet functions to the transmitter module 201 based on the selected one or more packet processing functions and prompts the transmitter module 201 to process the data. The transmitter module 201 also adds a unique value/data to the PDU data type being transmitted. The transmitter module 201 then sends the processed data along with its unique value to the receiving UE 101b. At the receiving UE 101b, the packet discriminator 202 processes the data received from the sending UE 101a and based on a unique value, i.e., a discriminator present in the data/message received from the sending UE 101a. Identifies the data type, that is, the PDU type.

The receiving module 203 may be configured to collect data that the transmitting UE 101a is transmitting and provide the collected data to the packet identifier 202 of the receiving UE 101 . The receiving module 203 also collects information pertaining to the type of the received PDU. The lower layer of the PDCP/RLC (Packet Data Convergence Protocol/Radio Link Control) layer in the receiving UE 101b collects PDU type information and transmits the PDU type information to upper layers.

The upper layer protocol module 204 is configured to undertake at least one sub-module capable of generating at least one type of PDU data. For example, the upper layer protocol module 204 includes an ARP protocol submodule, an IP protocol submodule, a discovery protocol submodule, and a signaling protocol submodule. The ARP protocol submodule generates ARP packets to be sent to one or more UEs. The IP protocol submodule generates IP packets to be sent to one or more UEs. The discovery protocol submodule generates discovery messages to be sent to one or more UEs. The signaling protocol sub-module generates control signaling messages to be sent to one or more UEs. The higher layer protocol module 204 also associates the data with the destination ID and PDU type, and shares the data with the transmitter module 201 of the transmitting UE 101a.

3 is a flowchart illustrating steps involved in a procedure for transmitting at least one PDU data from a UE in a D2D communication network, as disclosed in embodiments of the present invention. The transmitter module 201 of the transmitting UE 101a receives data to be transmitted from the higher layer protocol module 202 to the receiving UE 101b ( 302 ). The upper layer protocol module is one of an ARP protocol module, an IP protocol module, a discovery protocol module, and a signaling protocol module. The ARP protocol module generates ARP packets to be sent to one or more UEs. The IP protocol module generates IP packets to be sent to one or more UEs. The discovery protocol module generates discovery messages to be sent to one or more UEs. The signaling protocol module generates control signaling messages to be sent to one or more UEs. The data received from the upper layer protocol module 204 is associated with at least a destination ID and a PDU type. The destination ID and PDU type associated with the data are received by the transmitter module 201 of the transmitting UE 101a from the higher layer protocol module. The destination ID identifies the destination to which the data will be transmitted. The destination can be another UE (i.e. destination ID corresponds to UE ID), a group of UEs (i.e. destination ID corresponds to group ID), or all nearby UEs (i.e. destination ID corresponds to broadcast ID). .

The PDU type identifies the type of data. For example, the PDU type may be an ARP packet, an IP packet, a discovery message, a control signaling message, a relay packet, and the like. The transmitter module 201 of the transmitting UE 101a maps the data associated with the destination ID and PDU type to the appropriate D2D radio bearer (304). In one embodiment data associated with different destination IDs are mapped to different D2D radio bearers. Data of all PDU types for one destination ID are mapped to the same D2D radio bearer. For example, data for destination ID1 (of some PDU type) is mapped to D2D radio bearer 1, and data for destination ID2 (of any PDU type) is mapped to D2D radio bearer 2, and so on. An advantage of this approach is that fewer D2D radio bearers may be maintained in the D2D communication network. In other embodiments data associated with different destination IDs are mapped to different D2D radio bearers. Data of several PDU types for the same destination ID are also mapped to different D2D radio bearers. For example, PDU type data corresponding to ARP for destination ID1 is mapped to D2D radio bearer 1, PDU type data corresponding to IP for destination ID1 is mapped to D2D radio bearer 2, and ARP for destination ID2 The mapping is performed in such a way that PDU type data corresponding to D2D radio bearer 3 is mapped, and PDU type data corresponding to IP for destination ID2 is mapped to D2D radio bearer 4. The advantage of this method is that various quality of service can be provided for various PDU types. For example, ARP packets may take precedence over IP packets. In order to map the data to the appropriate D2D radio bearer, the transmitter module 201 of the transmitting UE 101a checks whether there is a D2D radio bearer for processing the data associated with the destination ID and PDU type. The transmitter module 201 of the transmitting UE 101a is configured to process the data associated with the destination ID and PDU type when there is no D2D radio bearer for processing the data associated with the destination ID and PDU type yet. Create a radio bearer (ie, a PDCP entity and an RLC entity). If such a D2D radio bearer already exists, the UE 101a selects a bearer that matches the destination ID and PDU type of the data to be transmitted.

The transmitter module 201 of the transmitting UE 101a identifies (306) the data packet type (or PDU type). The PDU type may be IP, Address Resolution Protocol (ARP), discovery message, control signaling message, relay packet, or the like. In various embodiments, the D2D communication network 100 may be configured to add a unique value/data with at least one of the available PDU types, allowing the receiving UE 101b to distinguish between the types of PDUs. have. In one embodiment, the packet discriminator module may be implemented with PDCP.

In addition, the transmitter module 201 selects packet processing functions (ROHC, secure sequence numbering) that match the identified PDU type, based on the information belonging to the PDU type of the data, and applies the selected packet processing functions to the data (308). For example, if the PDU type is ARP, the ROHC function is not applied, whereas the ROHC function is applied to data associated with the PDU type corresponding to the IP. In addition, the transmitter module 201 of the transmitting UE 101a adds ( 310 ) at least one unique data/value indicating the PDU type of the data to the data.

In one embodiment, to enable the receiving UE 101b to identify the PDU type, one or more LCIDs are reserved for each PDU type, and the LCID is each D2D radio bearer according to the PDU type processed by the corresponding is assigned to The LCID is a logical channel ID of a logical channel to which a D2D radio bearer is mapped on lower layers. There is a one-to-one mapping between the logical channel and the D2D radio bearer. The LCID is added to the PDU header. The header may be one of PDCP/RLC/MAC headers. The advantage of this approach is that a new header field is not needed when the LCID field is already present in the PDU header. In another embodiment where data packets of different PDU types may be mapped to the same D2D radio bearer, a PDU type field is added to the PDU header to identify the PDU type. The header may be one of PDCP/RLC/MAC headers. The advantage of this approach is that multiple D2D radio bearers do not need to be maintained for each destination, thus reducing complexity. In another embodiment in which PDU type data packets corresponding to IP and non-IP are mapped to different D2D radio bearers, one or more LCIDs are reserved for IP and non-IP packets, and the LCID determines whether to process IP packets or not It is allocated to each D2D radio bearer according to whether or not it is processed. A PDU type field is added to the header of a PDCP PDU or MAC PDU to identify the PDU type of each non-IP data. The non-IP data is either an ARP packet or a discovery message or a control signaling message.

Transmitter operation in one embodiment: allocating respective radio bearers for ARP packets and IP packets

In this scenario (as shown in FIG. 5 ), the transmitter module 201 of the transmitting UE 101a receives 502 packets to be transmitted from the higher layer protocol module. The transmission module 201 further creates an individual D2D radio bearer (or PDCP/RLC entity) for transmission of ARP packets, and the AS receives the destination ID and PDU type along with the packet from the upper layer protocol module 202 ( 504). In one embodiment, each PDCP/RLC entity carries PDCP/RLC packets to different destinations using at least one data transmission mode, such as unicast, multicast, broadcast, etc. /RLC entities can be created/existent. Also, LCIDARPPkts are reserved from the LCID space to distinguish a PDCP/RLC entity carrying ARP packets from a PDCP/RLC entity carrying at least one other type of PDCP/RLC packet.

In one embodiment, when ARP packets are broadcast only, the reserved LCIDARPPkts are not used/allocated for identification of the PDCP/RLC entity carrying the broadcast IP packets. Reserved LCIDARPPkts may be used or allocated for identification of PDCP/RLC entities carrying unicast or group cast IP packets.

In this scenario, if the PDU is identified as being of type ARP, packet processing matching the ARP packets is applied (512 and 514). In an exemplary embodiment, the packet processing function matching ARP packets may have the following characteristics:

- The header compression function is not applied by the corresponding PDCP entity (ie, no ROHC (Robust Header Compression)).

- Security according to the destination ID is applied by the corresponding PDCP entity.

- Source UE ID, Destination ID and LCID _{ARPPkts identify} the created D2D radio bearer, ie, PDCP entity and RLC entity, where LCID _ARPPkts is a given LCID for ARP packets.

- Source UE ID, Destination ID and LCID are sent in the MAC PDU header carrying this packet, where LCIDARPPkts is the given LCID for ARP packets.

If the PDU has been identified as a non-ARP packet, i.e. IP type in this scenario, at least one corresponding packet handling function is applied (508 and 510). The packet processing function for the IP PDU may have the following characteristics.

- The header compression function is applied by the corresponding PDCP entity (that is, ROHC (Robust Header Compression) is applied).

- Security according to the destination ID is applied by the corresponding PDCP entity.

- Source UE ID, destination ID and LCID (unused LCID from LCID set of IP packets) identify the created D2D radio bearer, i.e. PDCP entity and RLC entity, where LCID is from set of LCIDs for IP packets Some unused LCIDs.

- Source UE ID, Destination ID and LCID are transmitted in the MAC PDU header carrying this packet, where LCID is some unused LCID from the set of LCIDs of IP packets.

In another embodiment, instead of reserving the LCID for the ARP packet, the PDU type field may be added to the PDU header. The header may be a PDCP header or a MAC PDU header. The PDU type distinguishes whether the packet is IP or ARP. The PDU type may also distinguish different types of PDUs, such as a discovery message, a control signaling message, a relay packet, a secure or non-secure IP packet, and the like.

The operation for ARP and IP packets is described. However, the same may apply for various PDU types. In another embodiment, if there are various PDU types other than IP packets, one LCID may be reserved for each of those PDU types. The transmitter module 201 creates another PDCP/RLC entity for transmission of packets of each PDU type. In one embodiment, only one PDCP/RLC entity is created to transmit packets of a specific PDU type. In another embodiment, there are multiple PDCP/RLC entities to transmit packets of one PDU type, where each PDCP/RLC entity has one for different destinations (eg, broadcast, unicast, group cast). It carries packets of PDU type. One or more LCIDs are reserved from the LCID space for D2D communication for each PDU type. MAC SDUs carrying packets of a particular PDU type are identified within the MAC PDU by the LCID reserved for that PDU type.

Transmitter operation in second embodiment: allocating respective radio bearers for IP packets and non-IP packets

In this scenario, the transmitter module 201 of the transmitting module UE 101a creates a separate PDCP/RLC entity for transmission of packets other than IP packets. In another embodiment, there may be multiple PDCP/RLC entities for the transmission of packets other than IP packets, with each PDCP/RLC entity carrying non-IP packets to a different destination. A PDCP/RLC entity carrying non-IP packets is identified by a _{source ID, destination ID, and LCID NonIPPkts.} A LCID (LCID _NonIPPkts ) is reserved to distinguish a PDCP/RLC entity carrying non-IP packets from a PDCP/RLC entity carrying IP packets. PDCP/RLC entities for IP and non-IP packets are mapped to different logical channels. MAC SDUs carrying non-IP packets are identified by _{LCID NonIPPkts in the MAC PDU.}

In this scenario, if the PDU is of some type other than IP (ie, non-IP packet), the packet processing may have the following characteristics:

- Source UE ID, Destination ID and LCID _NonIPPkts identify the created PDCP/RLC entity.

- The header compression function is not applied by the corresponding PDCP entity (ie, ROHC) is applied).

- The PDCP entity adds the PDU type to the PDCP header. The PDU type distinguishes various types of non-IP packets (eg, ARP packets, relay packets, discovery messages, control signaling messages, etc.), where the PDU type is different for each type of non-IP packet.

- Security according to the destination ID is applied by the corresponding PDCP entity.

- A smaller counter size can be used to have headers of the same size.

If the PDU is IP, the packet format may have the following characteristics:

- Source UE ID, Destination ID and LCID (from LCID for IP packets) identify the created PDCP/RLC entity.

- The header compression function is applied by the corresponding PDCP entity (ie, ROHC) is applied).

- The PDCP entity does not add the PDU type to the PDCP header. In one embodiment, the PDU type is added to the PDCP header and set to an IP packet.

- Security according to the destination ID is applied by the corresponding PDCP entity.

Likewise, unique data/values may be associated with other PDU types. In this case, the packet formats may vary accordingly. It should be noted that the packet format characteristics described above may be changed according to requirements.

The various operations of method 300 may be performed in the order presented, in a different order, or concurrently. Also, in some embodiments, some operations listed in FIG. 3 may be omitted.

4 is a flowchart illustrating steps involved in a procedure for receiving at least one PDU data by a UE in a D2D communication network, as disclosed in the embodiments of the present invention. The receiving UE 101b receives the data transmitted by the transmitting UE 101a ( 402 ). Data is received over a D2D communication link. In the receiving UE 101b, the receiving module 203 maps the received data to a corresponding D2D radio bearer (PDCP/RLC entity) (404). Here, the corresponding D2D radio bearer is identified based on the source ID, destination ID, and LCID present in the PDU header. The packet identifier module 202 of the receiving UE 101b identifies the PDU type by referring to the LCID type and/or PDU type field in the header associated with the PDU.

Based on the determined PDU type, the receiving UE 101b applies different operations to process the received data, and indicates the PDU type to higher layers together with the processed data. For example, if the PDU type is ARP, the ROHC function is not applied, whereas the ROHC function is applied to data associated with the PDU type corresponding to the IP.

In one embodiment where the PDU type is relay PDU, the receiving UE 101b relays the received PDU to the wide area communication network, ie, sends the PDU to the base station. The receiving UE 101b transmits the LCID (in the LCID field of the PDU header) of the PDU received from the transmitting UE 101a through the D2D communication channel and the radio/EPS (Evolved packet system) in which the packet is sent to the base station. Radio/EPS of the bearer Manages the mapping between bearers. The receiving UE 101b uses this mapping to determine the LCID for transmitting packets received from the base station to the transmitting UE 101a. For example, the receiving UE 101b receives a PDU from the transmitting UE 101a, where the LCID field in the PDU header is LCID1 and the PDU type corresponding to the relay PDU. The receiving UE 101b transmits this PDU to the base station through the radio/EPS bearer ID corresponding to RBID2/EPSBID2. The receiving UE 101b manages the mapping of LCID1 to RBID2/EPSBID2. The receiving UE 101b receives the PDU on RBID2/EPSBID2 from the base station for the transmitting UE 101a. The receiving UE 101b determines based on the stored mapping that LCID1 should be used to transmit the PDU to the transmitting UE 101a. The receiving UE 101b maps this PDU to the D2D radio bearer corresponding to LCID1 and transmits it to the transmitting UE 101a on the D2D communication network. The advantage is that, if the LCID is an indication of priority, the PDU received from the base station for the transmitting UE 101a is applied by the transmitting UE 101a when transmitting the PDU to the receiving UE 101b for relaying to the base station. The same priority as that may be applied by the receiving UE 101b. In another embodiment, instead of the RBID/EPSBID, the LCID is five sets of IPs (ie, the SRC IP address in the PDU received from the transmitting UE 101a, the destination IP address in the PDU received from the transmitting UE 101a, the port number, the source IP address in the PDU sent (relayed) by the receiving UE 101b to the base station, and the destination IP address in the PDU sent (relayed) to the base station by the receiving UE 101b). This is useful when PDUs of multiple LCIDs are mapped to the same RBID/EPSBID and relayed to the base station. In one embodiment, if there is a fixed mapping between the LCID and the packet priority, the receiving UE 101b may indicate the packet priority to a higher layer for the packet received from the transmitting UE 101a. The upper layer stores the mapping between packet priorities and EPS bearer IDs or 5 IPs. In addition, the upper layer of the receiving UE 101b provides this packet priority to lower layers for the packet received from the base station for relaying to the transmitting UE 101a.

Receiver operation in the first embodiment: allocating respective radio bearers for ARP packets

In this scenario (as shown in FIG. 6 ), the receiver module 203 of the receiving UE 101b receives data, that is, MAC SDU (Medium Access Control Service Data Unit), and PDCP/RLC (Packet Data Convergence). Protocol/Radio Link Control) protocol and data to be routed are identified, and the MAC SDU is routed to the identified PDCP (602). The PDCP verifies (604) the LCID associated with the data. If the LCID is LCID _ARPPackets , that is, an LCID indicating ARP data, the PDCP indicates to an upper layer that the received PDCP SDU is an ARP packet (608). Further corresponding actions are applied to the data. When the LCID is LCID _ARPPackets or a PDU type corresponding to ARP, the operations that can be applied are as follows:

- The header decompression function is not applied by the PDCP entity.

- Security is applied according to the destination ID.

- The PDCP entity indicates to the upper layer that the received packet is an ARP packet.

If the LCID associated with the received data _{is not LCID ARPPackets} , then the PDCP indicates to the upper layer that the received PDCP SDU is an IP packet (in this scenario) (610), and the corresponding operations are applied to that data. When the LCID is _{other than LCID ARPPackets} or a PDU type corresponding to IP, the applicable operations are as follows:

- The header decompression function is applied by the PDCP entity.

- Security is applied according to the destination ID.

- The PDCP entity indicates to the upper layer that the received PDCP SDU is an IP packet.

Receiver operation in the second embodiment: Assign each radio bearer for packets other than IP packets

In this scenario (scenario as shown in FIG. 7 ), the receiver module 203 of the receiving UE 101b receives the data, ie the MAC SDU, identifies the PDCP/RLC protocol, the data to be routed, and the identified PDCP to route the MAC SDU (702). The PDCP verifies the LCID associated with the data (704). If the LCID is LCID _NonIPackets , that is, an LCID representing ARP data (in this scenario), the PDCP analyzes header type 1 (708) and indicates to an upper layer the PDCP SDU type of the received data (710). Further corresponding actions are applied to the data. When the LCID indicates non-IP packets, that is, LCID _NonIPPackets , the applicable operations are as follows.

- The PDCP entity does not apply the header decompression function.

- The PDCP entity analyzes header type 1 (ie, header with PDU type).

- The PDCP entity analyzes the PDU type, and the PDCP entity indicates to the upper layer the PDU type received through the PDCP header.

If the LCID associated with the received data _{is not LCID NonIPackets} , the PDCP indicates to an upper layer that the received PDCP SDU is an IP packet (712). When the LCID indicates IP packets, the applicable actions are as follows:

- The PDCP entity applies the header decompression function.

- The PDCP entity analyzes header type 2 (header without PDU type).

- The PDCP entity indicates to the upper layer that the received PDCP SDU is an IP packet.

The embodiments disclosed herein may be implemented through at least one software program running on at least one hardware device and performing network management functions for controlling network elements. The network components shown in FIG. 1 include blocks that may be at least one of a combination of a hardware device, a hardware device, and a software module.

Embodiments of the present invention specify a mechanism for distinguishing between different IP packets in a D2D communication network. The mechanism enables the distinction between different PDU packets and provides a system accordingly. It can thus be seen that the scope of protection extends to such systems, and by extension, computer readable means having a message therein, said computer readable means of said method when the program is executed on a server or mobile device or any suitable programmable device. contains program code for the implementation of one or more steps. The method is implemented through a preferred embodiment using, for example, a system in which a software program is written. Very high speed integrated circuit Hardware Description Language (VHDL), another programming language is implemented by one or more VHDL or some software modules running on at least one hardware device. The hardware device may be any kind of device that can be programmed, including any kind of computer, such as a server, a personal computer, etc. or any combination thereof, for example, one processor and two FPGAs. The apparatus may also comprise means which may be, for example, hardware means such as an ASIC or a combination of hardware and software means, an ASIC and FPGA, or at least one memory and at least one microprocessor in which software modules are located. Accordingly, said means is at least one hardware means or at least one hardware and software means. Embodiments of the method described herein may be implemented through pure hardware or partial hardware and partial software. Alternatively, the embodiment may be implemented using other hardware devices, such as a plurality of CPUs.

The foregoing description of specific embodiments sufficiently reveals the general nature of the embodiments therein so that others can apply their present knowledge to easily modify and/or adapt various applications such as specific embodiments without departing from the general concept. , so that adaptations and variations are intended to be embraced within the meaning and scope of the disclosed embodiments. It is to be understood that the phraseology or terminology used herein is for the purpose of description and not limitation. Accordingly, while the embodiments herein have been described with reference to preferred embodiments, those skilled in the art will recognize that the embodiments herein may be practiced with modifications within the spirit and scope of the claims set forth herein.

Claims (21)

A method for a transmitting UE to transmit data in a device-to-device (D2D) communication network, the method comprising:
Receiving a packet data convergence protocol (PDCP) service data unit (SDU) from a higher layer;
identifying a type of data included in the PDCP SDU;
generating a PDCP protocol data unit (PDU) including the PDCP SDU and a header; and
Transmitting the generated PDCP PDU to a receiving UE,
The header includes information indicating the type of the data included in the PDCP SDU.
According to claim 1,
When the type of the data included in the PDCP SDU is an IP (internet protocol) packet type, the generation of the PDCP PDU indicates that the type of the data included in the PDCP SDU is the IP packet type. A method comprising: setting to a predefined value and performing header compression of the PDCP SDU.
3. The method of claim 2,
If the type of the data included in the PDCP SDU is not the IP packet type, header compression of the PDCP SDU is not performed.
The method of claim 1 , wherein the method comprises:
and processing the PDCP SDU using at least one data processing function selected based on the type of the PDCP SDU.
The method of claim 1 , wherein the method comprises:
The method further comprises mapping the PDCP PDU to at least one D2D radio bearer,
and the at least one D2D radio bearer processes the PDCP PDU based on the type of the PDCP SDU.
The method of claim 1, wherein the generating of the PDCP PDU comprises:
selecting at least one logical channel ID (LCID) matching the type of the PDCP SDU, wherein one or more LCIDs indicate the type of the PDCP SDU;
allocating the selected LCID to at least one D2D radio bearer that processes the PDCP PDU based on the type of the PDCP SDU; and
The method further comprising adding the selected LCID to an LCID field in a header of the PDCP PDU.
According to claim 1,
The generating of the PDCP PDU further includes adding the information to a PDU type field in the header of the PDCP PDU.
According to claim 1,
The type of the PDCP SDU is one of an IP packet type, an Address Resolution Protocol (ARP) packet type, a discovery message type, a relay packet type, and a control signaling message type.
The method of claim 1,
The type of the PDCP SDU is an Address Resolution Protocol (ARP) PDU, the method comprising:
allocating an LCID for ARP packets to at least one D2D radio bearer that processes the transmitted ARP PDU, wherein the LCID for the ARP packets is at least one LCID reserved for an ARP PDU; and
sending the ARP PDU with the LCID for the ARP packets to at least one receiving UE.
According to claim 1,
The packet data type of the PDU is an Address Resolution Protocol (ARP) PDU,
The method is:
adding a PDU type field to the header of the ARP PDU, wherein the PDU type field is set to a value indicating the ARP PDU; and
The method further comprising transmitting the ARP PDU having the PDU type field to at least one receiving UE.
The method of claim 1,
The packet data type of the PDU is an Address Resolution Protocol (ARP) PDU,
The method is:
allocating LCIDs for Non-IP packets to at least one D2D radio bearer that processes the transmitted ARP PDU;
adding a PDU type field to the header field of the ARP PDU, wherein the PDU type field is set to a value indicating an ARP PDU; and
The method further comprising transmitting the ARP PDU having the LCID and the PDU type field for the Non-IP packets to at least one receiving UE.
A method for receiving data by a receiving UE in a device-to-device (D2D) communication network, the method comprising:
receiving a packet data convergence protocol (PDCP) service data unit (SDU) and a PDCP protocol data unit (PDU) including a header from the transmitting UE of the D2D communication network;
identifying information indicating a type of data included in the PDCP SDU, wherein the information is included in the header; and
and processing the PDCP SDU using at least one data processing function selected based on the information.
13. The method of claim 12,
When the information is set to a predefined value indicating that the type of the data included in the PDCP SDU is an IP packet type, the processing operation of the PDCP SDU includes performing header decompression of the PDCP SDU , Way.
14. The method of claim 13,
If the information is not set to a predefined value indicating that the type of the data included in the PDCP SDU is the IP packet type, header decompression of the PDCP SDU is not performed.
13. The method of claim 12,
The method is:
receiving the PDCP PDU from the transmitting UE; and
if the LCID for ARP packets is associated with the received PDCP PDU, identifying the type of the PDCP SDU of the received PDCP PDU as an ARP packet.
13. The method of claim 12,
The method is:
receiving the PDCP PDU from the transmitting UE; and
When the PDCU type field in the header of the received PDCP PDU indicates an ARP PDU, the method further comprising: identifying the type of the PDCP SDU of the received PDCP PDU as an ARP packet.
13. The method of claim 12,
The method is:
receiving the PDCP PDU from the transmitting UE; and
When the LCID field in the header is the same as the LCID for non-IP packets and the PDU type field is set to a value indicating the ARP PDU in the received PDCP PDU, the type of the PDCP SDU of the received PDCP PDU and identifying as an ARP packet.
A transmitting UE transmitting data in a device-to-device (D2D) communication network, comprising:
receiving set;
transmitter; and
a processor operably connected to the receiver and the transmitter, the processor comprising:
receiving a packet data convergence protocol (PDCP) service data unit (SDU) from a higher layer;
identify a type of data included in the PDCP SDU;
generating a PDCP protocol data unit (PDU) including the PDCP SDU and a header; and
configured to transmit the generated PDCP PDU to a receiving UE,
The header includes information indicating the type of the data included in the PDCP SDU, the transmitting UE.
19. The method of claim 18,
When the type of the data included in the PDCP SDU is an Internet protocol (IP) packet type, generating the PDCP PDU indicates that the type of the data included in the PDCP SDU is the IP packet type. and performing header compression of the PDCP SDU.
In a device-to-device (D2D) communication network, in a receiving UE receiving data,
receiving set;
transmitter; and
a processor operably connected to the receiver and the transmitter, the processor comprising:
receive a packet data convergence protocol (PDCP) service data unit (SDU) and a PDCP protocol data unit (PDU) including a header from the transmitting UE of the D2D communication network;
Identifies information indicating a type of data included in the PDCP SDU, wherein the information is included in the header; and
and process the PDCP SDU using at least one data processing function selected based on the information.
21. The method of claim 20,
When the information is set to a predefined value indicating that the type of the data included in the PDCP SDU is an IP packet type, processing the PDCP SDU includes performing header decompression of the PDCP SDU, receiving UE.

Images