DESC:FORM 2
THE PATENTS ACT, 1970
[39 of 1970]
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(Section 10; Rule 13)

METHOD OF PERFORMING DEVICE TO DEVICE COMMUNICATION BETWEEN USER EQUIPMENTS

SAMSUNG R&D INSTITUTE INDIA – BANGALORE Pvt. Ltd.
# 2870, ORION Building, Bagmane Constellation Business Park,
Outer Ring Road, Doddanakundi Circle,
Marathahalli Post,
Bangalore -560037, Karnataka, India
Indian Company

The following Specification particularly describes the invention and the manner in which it is to be performed

RELATED APPLICATION

Benefit is claimed to Indian Provisional Application No. 5430/CHE/2014 titled "METHOD OF GENERATING PDCP PDU IN A D2D COMMUNICATION SYSTEM” filed on 30th October 2014, which is herein incorporated in its entirety by reference for all purposes.

FIELD OF THE INVENTION

The present invention generally relates to Pro-Se Communication in 3GPP. The present invention more particularly relates to generating the Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) depending on whether the security is applied or not during transmission.

BACKGROUND OF THE INVENTION

Device to Device (D2D) communication is being studied in communication standard groups to enable data communication services between the User Equipment (UEs). During the D2D communication a transmitting D2D UE can transmit data packets to a group of D2D UEs or broadcast data packets to all the D2D UEs or send unicast data packets to a specific D2D UE. D2D communication between the transmitter and receiver(s) is connectionless in nature i.e. there is no connection setup (or no control messages are exchanged) between the transmitter and receiver before the transmitter starts transmitting the data packets. During the transmission, the transmitter includes the source ID and the destination ID in the data packets. The source ID is set to the UE ID of the transmitter. The destination ID is the intended recipient of the transmitted packet. The destination ID indicates whether the packet is a broadcast packet or a unicast packet or a packet intended for a group.

Figure 1 is a schematic diagram illustrating a protocol stack for D2D communication. The Packet Data Convergence Protocol (PDCP) layer in the transmitter receives the data packets i.e. IP packets or ARP Packets (PDCP SDUs) from upper layer. It secures the packet and also compresses the IP headers of IP packets. The processed packet PDCP Protocol Data Unit (PDU) is sent to Radio Link Control (RLC) layer. The RLC layer receives the PDCP PDUs (RLC Service Data Unit (SDUs)) from the PDCP layer. It fragments the PDCP PDUs if needed and sends the RLC PDUs to Media Access Control (MAC) layer. The MAC layer multiplexes the RLC PDUs (or MAC SDUs) and sends the MAC PDU to Physical (PHY) layer for transmission on PC5 interface (wireless channel).

Figure 2 is a schematic diagram illustrating a PDCP PDU for D2D communication. The PDCP layer adds a PDCP header to each PDCP SDU. The PDCP header comprises of PDU type, PGK ID, PTK ID and PDCP SN. The PDU type indicates whether the data in PDCP PDU is an ARP packet or IP packet. In order to support the security a Pro-Se Group Key (PGK) is defined. PGK is specific to a group of D2D UEs. Multiple PGKs per group can be pre-provisioned in UE. Each of these PGKs for the same group is identified using an 8 bit PGK ID. If a UE wants to send data packets to a group, then it derives a Pro-Se Traffic Key (PTK) from the PGK corresponding to that group. The PTK is identified using PTK Id. PTK is a group member specific key generated from the PGK. Each PTK is also associated with a 16 bit counter (or PDCP SN). The counter (or PDCP SN) is updated for every packet transmitted.

The transmitter always adds the PDCP header with the PDU type, PGK ID, PTK ID and PDCP SN in every PDCP PDU. The receiver always parses these four fields in every PDCP PDU. The transmitter and receiver always encrypt/decrypt the data in PDCP PDU respectively.

In some D2D communication systems whether to apply the security (encryption and/or integrity protection) or not can be configurable. In case if the transmitter does not apply security, then the current approach does not work as the receiver always assumes that data is encrypted in every PDCP PDU and using the PDCP security information in the PDCP header, receiver derives the security keys and decrypts the data.

In some D2D communication system, a UE can be in coverage of network and another UE can be in out of network coverage. UE in coverage of network can receive the security configuration from network while out of coverage UE has to rely on pre configuration or may not apply security in the absence of security configuration. In case if the receiving UE is in coverage and always assumes that data is encrypted in every PDCP PDU then communication will fail as receiver decrypts the PDU which is not encrypted.

Thus, there is a need for a method to generate the PDCP PDU depending on whether the security is applied or not. Further it is required to reduce the overhead in the radio interface by avoiding transmitting redundant information, especially when security is not applied, then it is not required to send the security information in the PDCP header.

SUMMARY

An embodiment of the present invention describes a method of performing device to device communication between user equipments (UEs). The method comprises determining security feature to be applied on one or more PDCP (packet data convergence protocol) data units at a transmitting UE, processing the one or more PDCP data units at the transmitting UE, based on the determination of security feature applied status before transmitting the one or more PDCP data units to one or more receiving UEs, and processing the one or more PDCP data units received from the transmitting UE at the one or more receiving UEs, based on the security feature applied status, and performing communication between the transmitting UE and one or more receiving UEs using one or more processed PDCP data units.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The aforementioned aspects and other features of the present invention will be explained in the following description, taken in conjunction with the accompanying drawings, wherein:

Figure 1 is a schematic diagram illustrating a protocol stack for D2D communication, according to an embodiment of the present invention.

Figure 2 is a schematic diagram illustrating a PDCP PDU for D2D communication, according to an embodiment of the present invention.

Figure 3 is a flowchart illustrating a PDCP Entity Operation in the transmitter for generating the PDCP PDU, according to an embodiment of the present invention.

Figure 4 is a flowchart illustrating a PDCP Entity Operation in the receiver, according to an embodiment of the present invention.

Figure 5 is a flowchart illustrating a PDCP Entity Operation in the receiver, according to another embodiment of the present invention.

Figure 6 is a flowchart illustrating a PDCP Entity Operation in the transmitter for generating the PDCP PDU, according to one embodiment of the present invention.

Figure 7 is a flowchart illustrating a PDCP Entity Operation in the receiver, according to one embodiment of the present invention.

Figure 8 is a flowchart illustrating a PDCP Entity Operation in the transmitter for generating the PDCP PDU, according to one embodiment of the present invention.

Figure 9 is a flowchart illustrating a PDCP Entity Operation in the receiver, according to one embodiment of the present invention.

Figure 10 is a flowchart illustrating a PDCP Entity Operation in the transmitter for generating the PDCP PDU, according to one embodiment of the present invention.

Figure 11 is a flowchart illustrating a PDCP Entity Operation in the receiver, according to one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The embodiments of the present invention will now be described in detail with reference to the accompanying drawings. However, the present invention is not limited to the embodiments. The present invention can be modified in various forms. Thus, the embodiments of the present invention are only provided to explain more clearly the present invention to the ordinarily skilled in the art of the present invention. In the accompanying drawings, like reference numerals are used to indicate like components.

The specification may refer to “an”, “one” or “some” embodiment(s) in several locations. This does not necessarily imply that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.

As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms “includes”, “comprises”, “including” and/or “comprising” when used in this specification, specify the presence of stated features, integers, steps, operations, elements and/or components, but do not preclude the presence or addition of one or more other features integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations and arrangements of one or more of the associated listed items.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein. Any name or term (which is registered trademark/copyright) used in the specification is only for the purpose of explaining the invention and not for any commercial gain.

The present invention describes a method to generate the PDCP PDU depending on whether the security feature is applied or not during Pro-Se Communication in 3GPP.

EMBODIMENT 1:
Figure 3 is a flowchart illustrating a PDCP Entity Operation in the transmitter for generating the PDCP PDU according to an embodiment of the present invention. In this method of present invention the transmitter adds the same PDCP header irrespective of whether security feature (e.g. ciphering) is applied on the data (i.e. PDCP SDU) or not by PDCP entity. In an embodiment, the Pro-Se configuration provided by the network (which is stored in the secure element (UICC) of the device) indicates to PDCP whether security feature (e.g. ciphering) should be applied or not to PDCP SDUs for a particular destination ID or for all destination IDs or for a particular PDU SDU type (e.g. relay SDU, signaling SDU, ARP SDU, etc). In an embodiment, whether to apply security feature (e.g. ciphering) or not is configured by the Pro-Se key management function or Pro-Se function in the network. In another embodiment, the upper layer indicates to PDCP whether security feature (e.g. ciphering) should be applied or not to PDCP SDUs by the PDCP entity. Whether security feature (e.g. ciphering) should be applied or not to PDCP SDUs, can be indicated for a particular destination ID or for all destination IDs or for a particular PDU SDU type (e.g. relay SDU, signaling SDU, ARP SDU, etc). Upper layer may indicate not to apply security feature in PDCP if the security is already applied to the PDCP SDU at upper layer. If the security feature is applied then PDCP generates the PDCP PDU by adding the PDCP header and including the PDU type, PGK ID and PTK ID and PDCP SN values associated with the PDCP SDU in the PDCP PDU. If the security feature is not applied then PDCP generates the PDCP PDU by adding the PDCP header and setting the PDU type associated with the PDCP SDU in the PDCP PDU. The PGK ID and PTK ID are set to predefined values. In one embodiment they can be set to zeroes. In another embodiment they can be set to ones. The pre-defined values of PGK ID and/or PTK ID indicated in the PDCP header when the security feature is not applied are used to identify (i.e. should be excluded from values used to identify PGK and PTK when the security is applied) PGK and PTK when the security feature is applied. In an embodiment, the PDCP SDUs are not numbered if the security is not applied, and the PDCP SN in the PDCP header is set to a pre-defined value. The pre-defined value can be zero.

In one embodiment, the transmitter determines if security feature is to be applied on PDCP SDU or not, at step 301. At step 302, the security feature is either applied or not based on the information received from the step 302. If security feature is applied, at step 303, PDCP entity encrypts the PDCP SDU. PDU Type and PDCP SN are set to the corresponding values associated with PDCP SDU. At step 304, PGK ID is set in PDCP header to PGK ID of the PGK or some least significant bits (LSBs) of PGK ID of the PGK which was used to generate PTK used for securing this PDCP SDU. At step 305, PTK ID is set to PTK ID of the PTK which was used to generate PEK used for securing this PDCP SDU. Encrypted PDCP SDU is transmitted together with PDCP header to a receiver.

If security feature is not to be applied, PDCP entity does not encrypt the PDCP SDU. PDU Type is set to the corresponding value associated with PDCP SDU at step 306. At step 307, PGK ID is set in PDCP header to predefined values (e.g. zeros or ones). At step 308, PTK ID is set in PDCP header to predefined values (e.g. zeros or ones). At step 309, PDCP SDUs are not numbered and the PDCP SN in the PDCP header is set to a pre-defined value (e.g. zeros or ones). Unencrypted PDCP SDU is transmitted together with PDCP header to the receiver.

Figure 4 is a flowchart illustrating a PDCP Entity Operation in the receiver according to an embodiment of the present invention. In one embodiment, the receiver knows whether the security feature is applied or not to the PDCP SDU based on configuration information received from a network (which is stored in the secure element (UICC) of the device). In an embodiment, whether security feature (e.g. ciphering) is applied or not is configured by the Pro-Se key management function or Pro-Se function in the network. In another embodiment, the upper layer indicates to PDCP whether security feature is applied or not to PDCP SDUs. If the security feature is applied, PDCP entity parses the PDCP header and determines the PGK and PTK used for securing the PDCP SDU based on PTK ID and PGK ID in the PDCP header. PDCP entity also parses the PDCP header and determines PDCP SN. If the security feature is not applied, then PDCP entity ignores the PTK ID and PGK ID field in the PDCP header. In an alternate embodiment, wherein PDCP SDUs are not numbered if security feature is not applied, then PDCP entity ignores the PDCP SN, PTK ID and PGK ID field in the PDCP header.

In one embodiment, the receiver process the data received from the transmitter to determine if security feature is applied on PDCP SDU or not based on configuration from Pro-Se function or Pro-Se key management function, at step 401. At step 402, a check is performed whether security feature is applied or not based on the information received from the step 401. At step 403, the PDCP entity parses the PDCP header and determines the PDCP SN, PGK and PTK used for securing the PDCP SDU based on PTK ID and PGK ID in the PDCP header when the security feature is applied. At step 404, the received PDCP SDU is decrypted and sent to upper layer. In one embodiment, the upper layer includes, but not limited to NAS Protocol, Pro-Se Protocol, Application, IP protocol, ARP Protocol, and Signaling Protocol.

At step 405, the PDCP SDUs are not numbered if security feature is not applied, and the PDCP entity ignores the PDCP SN, PTK ID and PGK ID field in the PDCP header. In an alternate embodiment at step 405, the PDCP entity ignores the PTK ID and PGK ID field in the PDCP header when the security feature is not applied. At step 406, the PDCP entity sends the received PDCP SDU to upper layer without decryption. In one embodiment, the upper layer includes, but not limited to NAS Protocol, Pro-Se Protocol, Application, IP protocol, ARP Protocol, and Signaling Protocol.

Figure 5 is a flowchart illustrating a PDCP Entity Operation in the receiver according to another embodiment of the present invention. In this embodiment the receiver determines whether the security feature is applied or not to the PDCP SDU based on PGK ID and/or PTK ID field values in the PDCP header. If the PGK ID and/or PTK ID are set to predefined values then PDCP entity interprets that security feature is not applied to the PDCP SDU otherwise it interprets that security feature is applied to the PDCP SDU. In an alternate embodiment the receiver determines whether the security feature is applied or not to the PDCP SDU based on PDCP SN and/orPGK ID and/or PTK ID field values in the PDCP header. If the PDCP SN and/orPGK ID and/or PTK ID are set to predefined values then PDCP entity interprets that security feature is not applied to the PDCP SDU otherwise it interprets that security feature is applied to the PDCP SDU.

At step 501, the receiver reads the PGK ID and/or PTK ID information in the received PDCP header. At step 502, a check is performed whether PGK ID and/or PTK ID is set to pre-defined values. At step 503, the receiver observes that the security feature is applied to PDCP SDU when the PGK ID and/or PTK ID is not set to pre-defined values. In an alternate embodiment at step 501, the receiver reads the PDCP SN and/or PGK ID and/or PTK ID information in the received PDCP header. At step 502, a check is performed whether PDCP SN and/or PGK ID and/or PTK ID is set to pre-defined values. At step 503, the receiver observes that the security feature is applied to PDCP SDU when the PDCP SN and/or PGK ID and/or PTK ID is not set to pre-defined values. The PGK and PTK used for securing the PDCP SDU are determined based on PTK ID and PGK ID in the PDCP header. At step 504, the received PDCP SDU is decrypted and sent to the upper layer. In one embodiment, the upper layer includes, but not limited to NAS Protocol, Pro-Se Protocol, Application, IP protocol, ARP Protocol, and Signaling Protocol.

At step 505, the receiver observes that the security feature is not applied to PDCP SDU when the PGK ID and/or PTK ID is set to pre-defined values. Alternately, at step 505, the receiver observes that the security feature is not applied to PDCP SDU when the PDCP SN and/or PGK ID and/or PTK ID is set to pre-defined values. The received PDCP SDU is sent to upper layer without decryption. In one embodiment, the upper layer includes, but not limited to NAS Protocol, Pro-Se Protocol, Application, IP protocol, ARP Protocol, and Signaling Protocol.

EMBODIMENT 2:
Figure 6 is a flowchart illustrating a PDCP Entity Operation in the transmitter for generating the PDCP PDU, according to an embodiment of the present invention. In this embodiment, the transmitter adds different type of PDCP header depending on whether security feature (e.g. ciphering) is applied on the data (i.e. PDCP SDU) or not. In an embodiment, the Pro-Se configuration provided by the network (which is stored in the secure element (UICC) of the device) indicates to PDCP whether security feature (e.g. ciphering) should be applied or not to PDCP SDUs by PDCP entity for a particular destination ID or all destination IDs or for a particular PDU SDU type (e.g. relay SDU, signaling SDU, ARP SDU, etc). In an embodiment, whether to apply security feature (e.g. ciphering) or not is configured by the Pro-Se key management function or Pro-Se function in the network. In another embodiment, the upper layer indicates to PDCP whether security feature should be applied or not to PDCP SDUs. Whether security feature (e.g. ciphering) should be applied or not to PDCP SDUs, can be indicated for a particular destination ID or for all destination IDs or for a particular PDU SDU type (e.g. relay SDU, signaling SDU, ARP SDU, etc). Upper layer may indicate not to apply security feature in PDCP if the security is already applied to the PDCP SDU at upper layer. If the security feature is applied then PDCP generates the PDCP PDU by adding the PDCP header and setting the PDU type, PGK ID, PTK ID and PDCP SN associated with the PDCP SDU in the PDCP PDU. If the security feature is not applied then PDCP generates the PDCP PDU by adding the PDCP header wherein the PDCP header comprises of PDU type and PDCP SN fields only. These fields are set to PDU type and PDCP SN associated with the PDCP SDU in the PDCP PDU. The PGK ID and PTK ID are not included in the PDCP header.

In yet another embodiment, an indicator is provided in PDCP header which indicates whether PGK ID and PTK ID are included in PDCP header or not.

At step 601, the transmitter determines if security feature to be applied on the PDCP SDU or not. At step 602, the security feature is either applied or not based on information received from the step 601. At step 603, PDCP entity encrypts the PDCP SDU and the PDCP header is added to data i.e. PDCP SDU, which comprises of only PDU Type, PGK ID, PTK ID, PDCP SN when the security feature is applied. At step 604, the PDU Type and the PDCP SN are set to the corresponding values associated with the PDCP SDU. At step 605, PGK ID in the PDCP header is set to PGK ID of the PGK which was used to generate PTK used for securing this PDCP SDU. At step 606, PTK ID is set to PTK ID of the PTK which was used to generate PEK used for securing this PDCP SDU. Encrypted PDCP SDU is transmitted together with PDCP header to the receiver.

At step 607, PDCP entity does not encrypt the PDCP SDU the PDCP header is added to the data, which comprises of only PDU Type and PDCP SN, when the security feature is not applied. At step 608, the PDU Type and the PDCP SN are set to the corresponding values associated with the PDCP SDU. Unencrypted PDCP SDU is transmitted together with PDCP header to the receiver.

Figure 7 is a flowchart illustrating a PDCP Entity Operation in the receiver, according to an embodiment of the present invention. In this embodiment, the receiver already knows whether the security feature is applied or not to the PDCP SDU based on configuration received from a network (which is stored in the secure element (UICC) of the device). In an embodiment, whether security feature (e.g. ciphering) is applied or not is configured by the Pro-Se key management function or Pro-Se function in the network. In an embodiment, the upper layer indicates to PDCP whether security feature is applied or not to PDCP SDUs. If the security feature is applied, PDCP entity parses the PDCP header comprising of PDU type, PGK ID, PTK ID and PDCP SN. PDCP entity then determines the PGK and PTK used for securing the PDCP SDU based on PTK ID and PGK ID in the PDCP header. If the security feature is not applied, then the PDCP entity parses the PDCP header comprising of PDU type and PDCP SN (as the receiver knows that PGK ID and PTK ID are not included in the PDCP header).

At step 701, the receiver determines if security feature is to be applied on PDCP SDU or not based on configuration from Pro-Se Function. At step 702, security feature is either applied or not based on information received from the step 701. At step 703, PDCP entity parses the PDU Type, PGK ID and PDCP SN from beginning of PDCP PDU, and determines the PGK and PTK used for securing the PDCP SDU based on PTK ID and PGK ID in the PDCP header. At step 704, the received PDCP SDU is decrypted and sent to upper layer. In one embodiment, the upper layer includes, but not limited to NAS Protocol, Pro-Se Protocol, Application, IP protocol, ARP Protocol, and Signaling Protocol.

At step 705, PDCP entity parses the PDU Type and PDCP SN from beginning of PDCP PDU. Alternately, at step 705, PDCP entity parses the PDU Type from beginning of PDCP PDU. At step 706, the received PDCP SDU is sent to upper layer. In one embodiment, the upper layer includes, but not limited to NAS Protocol, Pro-Se Protocol, Application, IP protocol, ARP Protocol, and Signaling Protocol.

EMBODIMENT 3:
Figure 8 is a flowchart illustrating a PDCP Entity Operation in the transmitter for generating the PDCP PDU according to an embodiment of the present invention. In this embodiment the transmitter adds different type of PDCP header depending on whether security feature is applied on the data (i.e. PDCP SDU) or not. In an embodiment, the Pro-Se configuration provided by the network (which is stored in the secure element (UICC) of the device) indicates to PDCP whether security feature should be applied or not to PDCP SDUs by PDCP entity for a particular destination ID or all destination IDs or for a particular PDU SDU type (e.g. relay SDU, signaling SDU, ARP SDU, etc). In an embodiment, whether security feature (e.g. ciphering) is applied or not is configured by the Pro-Se key management function or Pro-Se function in the network. In an embodiment, the upper layer indicates to PDCP whether security feature should be applied or not to PDCP SDUs. Whether security feature (e.g. ciphering) should be applied or not to PDCP SDUs, can be indicated for a particular destination ID or for all destination IDs or for a particular PDU SDU type (e.g. relay SDU, signaling SDU, ARP SDU, etc). Upper layer may indicate not to apply security feature in PDCP if the security is already applied to the PDCP SDU at upper layer. If the security feature is applied then PDCP generates the PDCP PDU by adding the PDCP header and setting the PDU type, PGK ID PTK ID and PDCP SN associated with the PDCP SDU in the PDCP PDU. If the security feature is not applied then PDCP generates the PDCP PDU by adding the PDCP header wherein the PDCP header comprises of PDU type only. The field PDU type is set to PDU type associated with the PDCP SDU in the PDCP PDU. The PGK ID, PTK ID and PDCP SN fields are not included in the PDCP header. PDCP SN is not maintained since security feature is not applied.

In another embodiment, an indicator is provided in PDCP header which indicates whether PGK ID, PTK ID and PDCP SN are included in PDCP header or not.

At step 801, the transmitter determines if security feature is to be applied on PDCP SDU or not. At step 802, security feature is either applied or not based on information received from the step 801. At step 803, PDCP entity encrypts the PDCP SDU and PDCP header is added which comprises of only PDU Type, PGK ID, PTK ID, PDCP SN, when the security feature is applied. At step 804, PDU Type and PDCP SN are set to the corresponding values associated with PDCP SDU. At step 805, PGK ID in PDCP header is set to PGK ID of the PDG which was used to generate PTK used for securing this PDCP SDU. At step 806, PTK ID is set to PTK ID of the PTK which was used to generate PEK used for securing this PDCP SDU. Encrypted PDCP SDU is transmitted together with PDCP header to the receiver.

At step 807, PDCP entity does not encrypt the PDCP SDU and PDCP header is added which comprises of only PDU Type, when the security feature is not applied. At step 808, PDU Type is set to the corresponding value associated with PDCP SDU. Unencrypted PDCP SDU is transmitted together with PDCP header to the receiver.

Figure 9 is a flowchart illustrating a PDCP Entity Operation in the receiver, according to an embodiment of the present invention. In this embodiment, the receiver already knows whether the security feature is applied or not to the PDCP SDU based on configuration received from network (which is stored in the secure element (UICC) of the device). In an embodiment, the upper layer indicates to PDCP whether security feature is applied or not to PDCP SDUs. If the security feature is applied, PDCP entity parses the PDCP header comprising of PDU type, PGK ID, PTK ID and PDCP SN. The PDCP entity then determines the PGK and PTK used for securing the PDCP SDU based on PTK ID and PGK ID in the PDCP header. If the security feature is not applied, then the PDCP entity parses the PDCP header comprising of PDU type only (as the receiver knows that PGK ID and PTK ID are not included in the PDCP header).

At step 901, the receiver determines if security feature is to be applied on PDCP SDU or not based on configuration from Pro-Se function. At step 902, security feature is either applied or not based on information received from the step 902. At step 903, PDCP entity parses the PDU Type, PGK ID, PTK ID and PDCP SN from beginning of PDCP PDU, and determines the PGK and PTK used for securing the PDCP SDU based on PTK ID and PGK ID in the PDCP header, when the security feature is applied. At step 904, the received PDCP SDU is decrypted and sent to upper layer.

At step 905, the PDCP entity parses the PDU Type from beginning of PDCP PDU. At step 906, the received PDCP SDU is sent to upper layer.

EMBODIMENT 4:
Figure 10 is a flowchart illustrating a PDCP Entity Operation in the transmitter for generating the PDCP PDU, according to an embodiment of the present invention. In this embodiment, the transmitter adds different type of PDCP header depending on whether security feature is applied on the data (i.e. PDCP SDU) or not. In an embodiment, the Pro-Se configuration provided by the network (which is stored in the secure element (UICC) of the device) indicates to PDCP whether security feature should be applied or not to PDCP SDUs for a particular destination ID (can be a Group ID) or all destination IDs or for a particular PDU SDU type (e.g. relay SDU, signaling SDU, ARP SDU, etc). In an embodiment, whether security feature (e.g. ciphering) is applied or not is configured by the Pro-Se key management function or Pro-Se function in the network. In an embodiment, the upper layer indicates to PDCP whether security feature should be applied or not to PDCP SDUs. Whether security feature (e.g. ciphering) should be applied or not to PDCP SDUs, can be indicated for a particular destination ID or for all destination IDs or for a particular PDU SDU type (e.g. relay SDU, signaling SDU, ARP SDU, etc). Upper layer may indicate not to apply security feature in PDCP if the security is already applied to the PDCP SDU at upper layer. If the security feature is applied then PDCP generates the PDCP PDU by adding the PDCP header and setting the PDU type as secured (example, if PDU type indicates ARP and IP packets then two additional types indicating unsecured ARP and unsecured IP are defined) and further adds the PGK ID, PTK ID and PDCP SN associated with the PDCP SDU in the PDCP PDU. If the security feature is not applied then PDCP generates the PDCP PDU by adding the PDCP header wherein the PDCP header comprises of PDU type only. The field PDU type is set to PDU type associated with the PDCP SDU in the PDCP PDU as unsecured (security feature not applied). The PGK ID, PTK ID and PDCP SN fields are not included in the PDCP header. PDCP SN is not maintained since security feature is not applied.
In an alternate embodiment an indicator can be there in PDCP header which indicates whether PGK ID, PTK ID and PDCP SN are included in PDCP header or not.

At step 1001, the transmitter determines if security feature is to be applied on PDCP SDU or not. At step 1002, security feature is either applied or not based on information received from the step 1001. At step 1003, the PDCP header is added which comprises of PDU Type, PGK ID, PTK ID, PDCP SN, when the security feature is applied. At step 1004, PDU Type and PDCP SN is set to the corresponding values associated with PDCP SDU.

At step 1005, PGK ID in the PDCP header is set to PGK ID of the PGK which was used to generate PTK used for securing this PDCP SDU. At step 1006, PTK ID is set to PTK ID of the PTK which was used to generate PEK used for securing this PDCP SDU.

At step 1007, PDCP header is added to data, which comprises of only PDU Type, when the security feature is not applied. At step 1008, PDU Type is set to the corresponding value associated with PDCP SDU.

Figure 11 is a flowchart illustrating a PDCP Entity Operation in the receiver, according to an embodiment of the present invention. In this embodiment, PDCP entity parses the PDCP header comprising of PDU type and based on the received PDU type knows whether the security feature is applied or not. If the PDU type indicates that the security feature is applied, then PDCP entity further parses the PDCP header comprising of PGK ID, PTK ID and PDCP SN. PDCP entity then determines the PGK and PTK used for securing the PDCP SDU based on PTK ID and PGK ID in the PDCP header. If the security feature is not applied (based on the PDU type), then the PDCP entity further process the data packet without decrypting the packet (or verifying the message authentication code (MAC-I)).

At step 1101, the receiver process the data received from transmitter to determine if security feature is applied on PDCP SDU or not based on PDU Type in the received PDCP Header. At step 1102, a check is performed whether security feature is applied or not based on information received from the step 1101. At step 1103, PDCP entity parses the PGK ID, PTK ID, and PDCP SN from beginning of PDCP PDU, and determines the PGK and PTK used for securing the PDCP SDU based on PTK ID and PGK ID in the PDCP header, when the security feature is applied. At step 1104, the received PDCP SDU is decrypted and sent to upper layer.

At step 1105, the received PDCP SDU is sent to upper layer without decryption, when the security feature is not applied. In one embodiment, the upper layer includes, but not limited to NAS Protocol, Pro-Se Protocol, Application, IP protocol, ARP Protocol, and Signaling Protocol.

Proposed Solution 5:
In one embodiment of the transmitter operation of the present invention, the transmitter adds different type of PDCP header (as explained in solution 1 to 4) depending on whether security feature is applied on the data (i.e. PDCP SDU) or not. In an embodiment, the Pro-Se configuration provided by the network (which is stored in the secure element (UICC) of the device) indicates to PDCP entity whether security feature should be applied or not to the PDCP SDUs for a particular destination ID (can be a Group ID).

In one embodiment of the receiver operation of the present invention, the receiver knows whether the security feature is applied or not to the PDCP SDU based on configuration received from Pro-Se Function during the service authorization. Further the configuration indicates, whether a particular device within a group will apply security feature or not. For example, if there are four devices (D1, D2, D3, D4) within a group performing D2D communication, where D1, D2 and D3 are subscribed for transmission and D4 is subscribed for only reception. In D4, the network configuration indicates that, D1 and D3 will apply security feature and D2 will not apply security feature. So when D4 receives data packets from D1 and D3, it knows security feature will be applied and when receives data packets from D2 it knows security feature is not applied. Network decides the configuration based on the device capability, subscription (low priority device) and like so.

EMBODIMENT 6:
In one embodiment of the present invention during the Transmitter Operation, the transmitter adds different type of PDCP header (as described in Embodiments 1 to 4) depending on whether security feature is applied on the data (i.e. PDCP SDU) or not. In an embodiment, the transmitting device decides whether security feature should be applied or not to the PDCP SDUs based on application (for example, whether application applies security feature or not, applications sensitivity), upper layer protocol (for example, if upper layer protocol (s) is RTP and/or UDP and/or HTTPS no security feature will be applied), its security capability and like so.

In one embodiment of the present invention during the Receiver Operation, the receiver already knows whether the security feature is applied or not to the PDCP SDU based on configuration received from Pro-Se Function during the service authorization. Further the configuration may indicates, whether a particular device within a group will apply security feature or not. In an embodiment, based on the indication/information received in the data packets, the receiver knows whether security feature is applied or not applied (for example using pre-defined values in the security information fields, based on PDU Type value in the PDCP header).

Although the invention of method has been described in connection with the embodiments of the present invention illustrated in the accompanying drawings, it is not limited thereto. It will be apparent to those skilled in the art that various substitutions, modifications and changes may be made thereto without departing from the scope and spirit of the invention.

,CLAIMS:
We claim:
1. A method of performing device to device communication between user equipments (UEs), the method comprising:
determining a security feature to be applied on one or more PDCP (packet data convergence protocol) data units at a transmitting UE;
processing the one or more PDCP data units at the transmitting UE, based on the determination of the security feature applied status, before transmitting the one or more PDCP data units to one or more receiving UEs;
processing the one or more PDCP data units received from the transmitting UE at the one or more receiving UEs, based on the security feature applied status; and
performing communication between the transmitting UE and the one or more receiving UEs using the one or more processed PDCP data units.

2. The method as claimed in claim 1, wherein determining the security feature to be applied on the one or more PDCP (packet data convergence protocol) data units at the transmitting UE based on a Pro-Se configuration received from a network.

3. The method as claimed in claim 1, wherein determining the security feature to be applied on the one or more PDCP (packet data convergence protocol) data units at the transmitting UE based on one of a Pro-Se key management function and Pro-Se function in a network.

4. The method as claimed in claim 1, wherein determining the security feature to be applied on the one or more PDCP (packet data convergence protocol) data units at the transmitting UE based on instruction received from an upper layer.

5. The method as claimed in claim 1, wherein processing the one or more PDCP data units at the transmitting UE when the security feature being applied to the one or more PDCP data units, comprises
including protocol data unit (PDU) type and packet data convergence protocol sequence number (PDCP SN) in PDCP header of each of the one or more PDCP data units wherein the PDCP SN and the PDU Type are set to values associated with the PDCP data unit;
including least significant bits of Pro-Se Group Key (PGK) ID in the PDCP header of each of the one or more PDCP data units wherein the PGK ID identifies the PGK used to generate PTK for securing the PDCP data unit; and
including Pro-Se Traffic Key (PTK) ID in the PDCP header of each of the one or more PDCP data units wherein the PTK ID identifies the PTK used to generate PEK for securing the PDCP data unit.

6. The method as claimed in claim 1, wherein processing the one or more PDCP data units at the transmitting UE when the security feature being not applied to the one or more PDCP data units, comprises
including protocol data unit (PDU) type in PDCP header of each of the one or more PDCP data units wherein the PDU Type is set to value associated with the PDCP data unit;
including packet data convergence protocol sequence number (PDCP SN) in the PDCP header of each of the one or more PDCP data units wherein the PDCP SN is set to a pre-defined value;
including least significant bits of Pro-Se Group Key (PGK) ID in the PDCP header of each of the one or more PDCP data units wherein the PGK ID is set to a pre-defined value; and
including Pro-Se Traffic Key (PTK) ID in the PDCP header of each of the one or more PDCP data units wherein the PTK ID is set to a pre-defined value.

7. The method as claimed in claim 1, wherein processing the one or more PDCP data units received from the transmitting UE at the one or more receiving UEs, comprises:
determining the security feature applied status on a PDCP SDU based on configuration from a Pro-Se function;
determining PGK and PTK for securing the PDCP SDU based on PTK ID and PGK ID in PDCP header by a PDCP entity when the security feature is applied to the one or more PDCP data units;
decrypting the received PDCP SDU; and
sending the decrypted PDCP SDU to an upper layer.

8. The method as claimed in claim 1, wherein processing the one or more PDCP data units received from the transmitting UE at the one or more receiving UEs, comprises:
determining the security feature applied status on a PDCP SDU based on configuration from a Pro-Se function; and
sending the received PDCP SDU to an upper layer without decryption when the security feature is not applied to the one or more PDCP data units.

9. The method as claimed in claim 1, wherein processing the one or more PDCP data units received from the transmitting UE at the one or more receiving UEs, comprises:
determining the security feature applied on a PDCP SDU when a predefined value is not assigned to at least one of a PDCP SN, PGK ID, and PTK ID;
determining PGK and PTK for securing the PDCP SDU based on at least one of the PDCP SN, PGK ID, and PTK ID in the PDCP header when the security feature is applied to the one or more PDCP data units;
decrypting the received PDCP SDU; and
sending the decrypted PDCP SDU to an upper layer.

10. The method as claimed in claim 1, wherein processing the one or more PDCP data units received from the transmitting UE at the one or more receiving UEs, comprises:
determining the security feature not applied on PDCP SDU when a predefined value is assigned to at least one of a PDCP SN, PGK ID, and PTK ID; and
sending the received PDCP SDU to an upper layer without decryption.

Dated this the 7th day of October 2015

Signature


KEERTHI J S
Patent Agent
Agent for the Applicant