CLIAMS:We claim:

1. A method for establishing dynamic connectivity for setting up Device-to-Device communication between a connecting device and a target device in a Device to Device (D2D) communication network, said method comprising:
collecting presence information pertaining to said target device, by said connecting device from a registration server;
identifying at least one optimum path to connect with said target device, based on said presence information, by said connecting device; and
establishing said dynamic connectivity with said target device using said optimum path, by said connecting device.
2. The method as claimed in claim 1, wherein said presence information further comprises at least one of a firewall information and a Network Address Translation (NAT) type information pertaining to said target device.
3. The method as claimed in claim 1, wherein identifying said at least one optimum path further comprises comparing at least one of a firewall information and a Network Address Translation (NAT) type information pertaining to said targeted device with a reference database, by said connecting device.
4. The method as claimed in claim 1, wherein said optimum path uses at least one of a User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and a Hyper Text Transfer Protocol (HTTP).
5. The method as claimed in claim 4, wherein using at least one of said UDP, TCP, and HTTP for said optimum path further comprises:
using said UDP if firewall of said target device supports said UDP, by said communicating device;
checking if said firewall of said target device supports said TCP if said firewall does not support UDP, by said communicating device;
using said TCP if firewall of said target device supports said TCP, by said communicating device; and
using said HTTP if said firewall of said target device does not support said TCP, by said communicating device.
6. The method as claimed in claim 1, wherein establishing said dynamic connectivity, when said connecting device and said target device are in same local network, further comprises:
identifying by performing a background connectivity check that said connecting device is in said same local network, by said target device;
identifying by performing a background connectivity check that said target device is in said same local network, by said connecting device; and
initiating a direct signalling to establish said dynamic connectivity using said at least one optimum path, by at least one of said connecting device and said target device, if said target device and said connecting device belong to said local network.
7. The method as claimed in claim 1, wherein establishing said dynamic connectivity, when said connecting device and said target device are in different public networks further comprises:
identifying by performing a background connectivity check that said connecting device is in a different public network, by said target device;
identifying by performing a background connectivity check that said target device is in a different public network, by said connecting device;
collecting presence information pertaining to said target device from said registration server, by said connecting device;
collecting presence information pertaining to said connecting device from said registration server, by said target device; and
initiating a public connectivity check using at least one optimum path, by at least one of said connecting device and target device.
8. The method as claimed in claim 1, wherein establishing said dynamic connectivity, when said connecting device and said target device are behind symmetric NAT networks further comprises:
identifying by performing a background connectivity check that said connecting device is behind a symmetrical NAT network, by said target device;
identifying by performing a background connectivity check that said target device is behind a symmetrical NAT network, by said connecting device;
collecting presence information pertaining to said target device from said registration server, by said connecting device;
collecting presence information pertaining to said connecting device from said registration server, by said target device; and
initiating a relay connectivity check using at least one optimum path, by at least one of said connecting device and target device.
9. The method as claimed in claim 1, wherein said presence information pertaining to said connecting device and target device is pre-stored in said registration server, wherein pre-storing said presence information with said registration server further comprises:
registering at least one of said connecting device and target device with said registration server;
collecting said presence information pertaining to said at least one connecting device and target device, by said registration server;
storing said collected presence information in at least one database, by said registration server; and
updating said presence information stored in said database, by said registration server.
10. A device for establishing dynamic connectivity with at least one target device using Device-to-Device (D2D) communication, wherein said device and said target device are associated with a D2D communication network, said device configured for:
collecting presence information pertaining to said target device from a registration server;
comparing said presence information with a reference database stored in a memory module; and
identifying at least one optimum path to communicate with said target device.
11. The device as claimed in claim 10, wherein said device is further configured to identify said optimum path based on at least one of a firewall and a network Address Translation (NAT) type information pertaining to said target device, wherein said device is configured to collect information pertaining to said firewall and NAT type from said presence information.
12. The device as claimed in claim 10, wherein said device is further configured to use at least one of a User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and a Hyper Text Transfer Protocol (HTTP) with said optimum path.
13. The device as claimed in claim 12, wherein said device is further configured for selecting at least one of said UDP, TCP, and HTTP for said optimum path by:
using said UDP if firewall of said target device supports said UDP;
checking if said firewall of said target device supports said TCP if said firewall does not support UDP;
using said TCP if firewall of said target device supports said TCP, by said communicating device; and
using said HTTP if said firewall of said target device does not support said TCP.
14. The device as claimed in claim 10, wherein said device is further configured for initiating said dynamic connectivity with said target device, wherein initiating said dynamic connectivity comprises sending a communication invite to said target device.
15. The device as claimed in claim 10, wherein said device is further configured to initiate a direct signalling with said target device if said device and said target device are in same local network, wherein said device is configured to identify by performing a background connectivity check that said target device is in said same local network.
16. The device as claimed in claim 10, wherein said device is configured to initiate a public connectivity check, if said device and said target device are in different public networks, wherein said device is configured to identify by performing a background connectivity check that said target device is in a different public network.
17. The device as claimed in claim 10, wherein said device is configured to initiate a relay connectivity check, if said device and said target device are in symmetric Network Address Translation (NAT) networks, wherein said device is configured to identify by performing a background connectivity check that said target device is behind said symmetric NAT network.
18. A device for establishing dynamic connectivity with at least one connecting device using Device-to-Device (D2D) communication, wherein said device and said connecting device are associated with a D2D communication network, said device configured for:
receiving a communication invite from said connecting device;
collecting presence information pertaining to said connecting device from a registration server;
comparing said presence information with a reference database stored in a memory module; and
identifying at least one optimum path to communicate with said connecting device.
19. The device as claimed in claim 18, wherein said device is further configured to identify said optimum path based on at least one of a firewall and a network Address Translation (NAT) type information pertaining to said connecting device, wherein said device is configured to collect information pertaining to said firewall and NAT type from said presence information.
20. The device as claimed in claim 19, wherein said device is further configured to use at least one of a User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and a Hyper Text Transfer Protocol (HTTP) with said optimum path.
21. The device as claimed in claim 20, wherein said device is further configured for selecting at least one of said UDP, TCP, and HTTP for said optimum path by:
using said UDP if firewall of said connecting device supports said UDP;
checking if said firewall of said connecting device supports said TCP if said firewall does not support UDP;
using said TCP if firewall of said connecting device supports said TCP, by said communicating device; and
using said HTTP if said firewall of said connecting device does not support said TCP.
22. The device as claimed in claim 18, wherein said device is further configured to initiate a direct signalling with said connecting device if said device and said connecting device are in same local network, wherein said device is configured to identify by performing a background connectivity check that said connecting device is in said same local network.
23. The device as claimed in claim 18, wherein said device is configured to initiate a public connectivity check, if said device and said connecting device are in different public networks, wherein said device is configured to identify by performing a background connectivity check that said connecting device is in a different public network.
24. The device as claimed in claim 18, wherein said device is configured to initiate a relay connectivity check, if said device and said connecting device are in symmetric Network Address Translation (NAT) networks, wherein said device is configured to identify by performing a background connectivity check that said connecting device is behind said symmetric NAT network.
25. A registration server for supporting dynamic connectivity between a connecting device and a target device, said registration server configured for:
establishing a connection with at least one device;
collecting presence information pertaining to said at least one device;
updating said collected presence information; and
providing said collected presence information to at least one other device upon receiving a request from said at least one other device.
26. The registration server as claimed in claim 25, wherein said registration server is further configured to update said presence information periodically.
27. The registration server as claimed in claim 25, wherein said registration server is further configured to update said presence information upon detecting occurrence of at least one trigger event.

Date: 26 February 2015 Signature:
Kalyan Chakravarthy

,TagSPECI:FORM 2
The Patent Act 1970
(39 of 1970)
&
The Patent Rules, 2005

COMPLETE SPECIFICATION
(SEE SECTION 10 AND RULE 13)

TITLE OF THE INVENTION

“NAT Traversal for optimized Device to Device Communication”

APPLICANT:

Name Nationality Address
SAMSUNG R&D Institute India - Bangalore Private Limited India # 2870, Orion Building, Bagmane Constellation Business Park, Outer Ring Road, Doddanekundi Circle, Marathahalli Post, Bangalore-560037, India

The following specification particularly describes and ascertains the nature of this invention and the manner in which it is to be performed:-

FIELD OF INVENTION
[001] The present invention relates to the field of Device to Device (D2D) communication and more particularly to reducing data latency and call set up latency in D2D communication networks.

BACKGROUND OF INVENTION
[002] Device-to-Device (D2D) communication permits direct communication between different User Equipments (UE). Most of the devices which are part of the networks are governed by a Network Address Translation (NAT) mechanism in which network/networks is mapped to a single IP address. When a device A tries to communicate with a device B, the device A needs to know the NAT associated with the device B, so that the packets may be routed to the right address.
[003] In addition to the NAT details, the device may also require information about the firewall each device is associated with. Certain firewalls do not allow data of particular type(s) to pass through. In existing communication systems that support NAT traversal, the devices that communicate are not aware of NAT type the target device is part of, and the firewall the target information is associated with. As a result, while establishing communication with a device B, the device A tries to use all possible protocols, without knowing which one will be supported by the destination device. This results in the setup latency and communication media latency; which adversely affects the network performance by causing delays.
[004] For example, in the existing networks, even if the devices A and B are in the same local networks, the devices still require to perform local connectivity check; which causes the setup latency and communication media latency. Similarly, if the devices A and B are in different public networks, each device still performs local connectivity check; though the local connection is not possible between devices in different public networks. This in turn causes time delays and results in setup latency and communication media latency. In another example, even if the devices A and B are behind symmetrical NAT works, the devices perform local and public connectivity checks, though local and public connections are not possible between devices behind symmetrical NAT networks. This in turn causes time delays and results in setup latency and communication media latency. Further, in the existing networks, even if the devices are in the same local networks or are reachable on public network directly, signalling between the devices may still happen through the registration server; increasing load on the server, thus affecting efficiency of the server.

OBJECT OF INVENTION
[005] The principal object of the embodiments herein is to eliminate data latency and call set up latency in a Device to Device (D2D) communication network, by establishing Device-to-Device communication between a plurality of User Equipment (UE) using an optimum path.
[006] Another object of the invention is to identify an optimum path for the UE to communicate with a target UE.
[007] Another object of the invention is to identify the optimum path based on firewall and Network Address Translation (NAT) information pertaining to the target device.

SUMMARY
[008] Accordingly the invention provides a method for a method for establishing dynamic connectivity for setting up Device-to-Device communication between a connecting device and a target device in a Device to Device (D2D) communication network. In this method, a connecting device collects presence information pertaining to the target device from a registration server. The connecting device, based on the presence information, identifies at least one optimum path to connect with the target device, and then establishes the dynamic connectivity with the target device using the optimum path.
[009] Accordingly the invention provides a device for establishing dynamic connectivity with at least one target device using Device-to-Device (D2D) communication, wherein the device and the target device are associated with a D2D communication network. The device collects presence information pertaining to the target device from a registration server. Further, the device compares the presence information with a reference database stored in a memory module and identifies at least one optimum path to communicate with the target device.
[0010] Accordingly the invention provides a device for establishing dynamic connectivity with at least one connecting device using Device-to-Device (D2D) communication, wherein the device and the connecting device are associated with a D2D communication network. The device, upon receiving a communication invite from the connecting device, collects presence information pertaining to the connecting device from a registration server. Further, by comparing the presence information with a reference database stored in a memory module, identifies at least one optimum path to communicate with the connecting device.
[0011] Accordingly the invention provides a registration server for supporting dynamic connectivity between a connecting device and a target device. The registration server establishes a connection with at least one device, and collects presence information pertaining to the device and updates the collected presence information. The registration server further provides the collected presence information to at least one other device upon receiving a request from the at least one other device.
[0012] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

BRIEF DESCRIPTION OF FIGURES
[0013] This invention is illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:
[0014] FIG. 1 illustrates a block diagram of optimum path selection framework, according to embodiments as disclosed herein;
[0015] FIG. 2 illustrates a block diagram which shows various components of the User Equipment (UE), according to embodiments as disclosed herein;
[0016] FIGs. 3a and 3b illustrate a block diagram which shows optimum path selection based communication in a local network, according to embodiments as disclosed herein;
[0017] FIG. 4 illustrates a block diagram which shows optimum path selection based communication between a UE and a target UE in different networks, according to embodiments as disclosed herein;
[0018] FIG. 5 illustrates a flow diagram which shows various steps involved in the process of establishing a communication using the optimum path selection framework, according to embodiments as disclosed herein; and
[0019] FIGs. 6a, 6b, and 6c illustrate example scenarios of establishing a communication using the optimum path selection framework for devices in a local, public, and symmetrical Network Address Translation (NAT) networks respectively, according to embodiments as disclosed herein.

DETAILED DESCRIPTION OF INVENTION
[0020] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0021] The embodiments herein achieve optimum path selection to establish Device-to-Device (D2D) communication in a telecommunication network. Referring now to the drawings, and more particularly to FIGS. 1 through 6, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments.
[0022] FIG. 1 illustrates a block diagram of optimum path selection framework, according to embodiments as disclosed herein. The optimum path selection framework 100 comprises of a plurality of User Equipments (UE) 101, and at least one Registration Server 102.
[0023] The UE 101 can function as a connecting device as well as a target device at the same time. The UE 101, while functioning as a connecting device, can select an optimum path to communicate with the target device, and initiate a D2D communication with a target device. The same UE 101, while functioning as a target device, can receive a D2D communication request from a connecting device, and in response, can select an optimum path to communicate with the communicating device, and initiate a D2D communication with the communicating device.
[0024] The UE 101 may be a mobile phone, or any such communication device, which may be configured to establish communication using a telecommunication network. The UE 101 may be configured establish communication with the registration server 102, using a suitable communication channel. The UE 101 may be further configured to register with, and update own presence information with the registration server 102. In a preferred embodiment, the UE 101 may be configured to collect from the registration server 102, presence information pertaining to at least one target UE and identify at least one optimum path to establish communication with said target UE. In an embodiment, the UEs 101.a and 101.b can be in same local network and may be locally reachable. In another embodiment, the UEs 101.a and 101.b can be in different networks and may not be locally reachable. Further, the UEs 101.a and 101.b may be behind same or different Network Address Translation (NAT) networks.
[0025] The registration server 102 may be configured to communicate with the UE 101 and provide option for the UE 101 to register with the registration server 102. The registration server 102 may be further configured to collect presence information pertaining to all UEs 101 registered with the registration server 102. The registration server 102 may be further configured to provide presence information pertaining to a UE 101 (for example UE 101.a) to another UE 101 (for example UE 101.b), upon receiving a request from the UE 101.b. In various embodiments, the registration server 102 may be further configured to update the stored presence information, periodically, or upon detecting occurrence of a pre-configured trigger event.
[0026] FIG. 2 illustrates a block diagram, which shows various components of the User Equipment (UE), according to embodiments as disclosed herein. The UE 101 comprises of an Input/Output (I/O) interface 201, a memory module 202, and an optimum path detector module 203.
[0027] The I/O interface 201 may be configured to provide at least one channel for the UE 101 to communicate with another UE 101 (I.e. a target UE) and/or the registration server 102. The I/O interface 201 may be configured to support a plurality of communication protocols such as but not limited to Transmission Control Protocol (TCP), and User Datagram Protocol (UDP).
[0028] The memory module 202 may be configured to store all information required for the optimum path detector module 203 to identify an optimum path for at least two UEs 101 to establish a communication. For example, the memory module 202 can possess a rulebook, which can be used for identifying the optimum path. The rulebook may further comprise information such as but not limited to NAT information pertaining to each UE 101, and optimum path that suits each type of NAT.
[0029] The optimum path detector module 203 may be configured to process real time presence information pertaining to a target UE 101, based on data in the rulebook, and identify at least one optimum path for the UE 101 to communicate with the target UE. In a preferred embodiment, the optimum path may refer to a communication channel that supports data communication between the UE 101 and the target UE 101, such that the optimum path can handle data in the format(s) being supported by the NAT and firewall of both the UE 101 that initiates the communication, and the target UE 101 that joins the communication.
[0030] FIGs. 3a and 3b illustrate a block diagram which shows optimum path selection based communication in a local network, according to embodiments as disclosed herein. As depicted in Fig. 3a, all UEs 101 in a local network are behind the same NAT. Assume that the UE 101.a is trying to communicate with the UE 101.c. In this example, the UE 101.a functions as connecting device, and the UE 101.c functions as target device. The UE 101.a communicates with the registration server 102 and collects presence information pertaining to the UE 101.c. Further, by processing the collected presence information using the optimum path detector module 203, the UE 101.a identifies NAT type and firewall information pertaining to the UE 101.c. Further, the optimum path detector module 203 in the UE 101, by analyzing the NAT type and firewall information pertaining to the UE 101.c, identifies that the UE 101.c is in the same local network. The optimum path detector module 203, based on the collected NAT type and firewall information, identifies an optimum path for the UE 101.a to communicate with the UE 101.c.
[0031] Upon identifying that the UE 101.c is in the same local network, the UE 101.a initiates direct communication with the UE 101.c using the optimum path. The UE 101.a invites the UE 101.c for a D2D communication and sends data IP/Port information to the UE 101.c. The UE 101.c receives the D2D communication invite (communication invite) along with other data transmitted from the UE 101.a.
[0032] In a preferred embodiment, upon receiving the request and data from the UE 101.a, the UE 101.c collects presence information pertaining to the UE 101.a and by processing the collected presence information, identifies an optimum path to communicate with the UE 101.a. In response to the communication invite, the UE 101.c sends data IP/Port information to the UE 101.a, using the optimum path selected. By identifying the optimum path for communication based on the information collected from the registration server 102, the UE 101 can identify the optimum path which supports protocols and data type being supported by the NAT and firewall of the target UE; thereby eliminating need to try all communication protocols to identify the right one. This in turn eliminates/reduces communication set up latency and data latency.
[0033] FIG. 4 illustrates a block diagram which shows optimum path selection based communication between a UE and a target UE in different networks, according to embodiments as disclosed herein. Assume that the UE 101.a is trying to communicate with the UE 101.b. The UE 101.a communicates with the registration server 102 and collects presence information pertaining to the UE 101.c. Further, by processing the collected presence information using the optimum path detector module 203, the UE 101.a identifies NAT type and firewall information pertaining to the UE 101.b. Further, the optimum path detector module 203 in the UE 101.a, by analyzing the NAT type and firewall information pertaining to the UE 101.b, identifies that the UE 101.b is not locally reachable. The optimum path detector module 203, based on the collected NAT type and firewall information, further identifies an optimum path for the UE 101.a to communicate with the UE 101.b. Further, using the optimum path selected, UE 101.a invites the UE 101.b for a D2D communication and sends data IP/Port information to the UE 101.b. The UE 101.b receives the D2D communication invite along with other data transmitted from the UE 101.a.
[0034] Upon receiving the request and data from the UE 101.a, the UE 101.b collects presence information pertaining to the UE 101.a, and by processing the collected presence information, identifies an optimum path to communicate with the UE 101.a. In response to the communication invite, the UE 101.b sends data IP/Port information to the UE 101.a, using the optimum path selected. As the UE 101.a and UE 101.b are in different networks i.e. not locally reachable, the communication invite and accept messages are routed through the registration server 102. Once the UE 101.b accepts the communication request, the communication channels are established, and the UEs 101.a and 101.b communicates through the optimum paths.
[0035] FIG. 5 illustrates a flow diagram which shows various steps involved in the process of establishing a communication using the optimum path selection framework, according to embodiments as disclosed herein. For illustration purpose, consider that UE 101.a and UE101.b tries to establish communication each other.
[0036] Each UE 101 initially connects with and registers with the registration server 102. In this example, the UE A, connects with and registers (502) with the registration server 102. Similarly, the UE 101B connects with and registers (510) with the registration server 102. In a preferred embodiment, while registering with the registration server 102, the UE 101 may update with the registration server 102, certain data in the form of presence information, which may indicate NAT type and firewall associated with the UE 101. In this example, the UE 101 A (504) and the UE B (514) updates own presence information with the registration server 102. In an embodiment, the UE 101 may automatically update the presence information with the registration server during the registration process. In another embodiment, the registration server 102 may have to prompt the UE 101 to provide the presence information, by sending appropriate command(s).
[0037] In this example, we can consider two scenarios:
? Scenario 1: UE A initiates communication with UE B, and UE B accepts communication invite from UE A
? Scenario 2: UE B initiates communication with UE A, and UE A accepts communication invite from UE B
Scenario 1:
[0038] In this scenario, the UE A functions as the connecting device, and UE B functions as the target device. In order to connect with UE B, the UE A collects (506) presence information pertaining to UE B, from the registration server 102. In an embodiment, the registration server 102 may perform at least one authentication check to ensure that the UE A has sufficient access rights to collect presence information pertaining to UE B.
[0039] Further, by analyzing the presence information pertaining to UE B, UE A identifies NAT type and firewall the UE B is associated with, and selects (508) at least one optimum path based on presence information of UE B as well as own NAT type and firewall type. The optimum path thus selected can be used to communicate with the UE B. For example, the NAT type of UE A can be any of Full cone, Address restricted, Port restricted, or Symmetric. Similarly, NAT type of UE B can be any of Full cone, Address restricted, Port restricted, or Symmetric. Based on combination of NAT type of UE A and UE B, the optimum path may be selected. In a preferred embodiment, the optimum path that matches a given combination of NAT types may be specified in the rulebook, as given below.
User A NAT User B NAT Optimum path A-> B Optimum path B->A Method Adopted
Full Cone Full Cone Public IP Public IP Only Public IP is used for connection checks
Full Cone Address Restricted Public IP Public IP Only Public IP is used for connection checks
Full Cone Port Restricted Public IP Public IP Only Public IP is used for connection checks
Full Cone Symmetric Public IP Public IP Only Public IP is used for connection checks
Address Restricted Full Cone Public IP Public IP Only Public IP is used for connection checks
Address Restricted Address Restricted Public IP Public IP Only Public IP is used for connection checks
Address Restricted Port Restricted Public IP Public IP Only Public IP is used for connection checks
Address Restricted Symmetric Public IP Public IP Only Public IP is used for connection checks
Port Restricted Full Cone Public IP Public IP Only Public IP is used for connection checks
Port Restricted Address Restricted Public IP Public IP Only Public IP is used for connection checks
Port Restricted Port Restricted Public IP Public IP Only Public IP is used for connection checks
Port Restricted Symmetric Public IP Public IP Only Public IP is used for connection checks
Symmetric Full Cone Public IP Public IP Only Public IP is used for connection checks
Symmetric Address Restricted Public IP Public IP Only Public IP is used for connection checks
Symmetric Port Restricted Public IP Public IP Only Public IP is used for connection checks
Symmetric Symmetric Relay IP Relay IP Only Relay IP is used for connection checks

[0040] Further, the selected optimum path is used by the UE A for connection checks with the UE B. Upon receiving a connection invite from UE A, the UE B may collect presence information pertaining to UE A from the registration server 102, and identify an optimum path to communicate with UE A. Further, the UE A and UE B establishes (520) a Device to Device (D2D) communication each other, using the selected optimum paths.
Scenario 2:
[0041] In this scenario, the UE B functions as the connecting device, and UE A functions as the target device. In order to connect with UE A, the UE B collects (516) presence information pertaining to UE A, from the registration server 102. In an embodiment, the registration server 102 may perform at least one authentication check to ensure that the UE B has sufficient access rights to collect presence information pertaining to UE A.
[0042] Further, by analyzing the presence information pertaining to UE A, UE B identifies NAT type and firewall the UE A is associated with, and selects (518) at least one optimum path based on presence information of UE A as well as own NAT type and firewall type. The optimum path thus selected can be used to communicate with the UE A. For example, the NAT type of UE B can be any of Full cone, Address restricted, Port restricted, or Symmetric. Similarly, NAT type of UE A can be any of Full cone, Address restricted, Port restricted, or Symmetric. Based on combination of NAT type of UE A and UE B, the optimum path may be selected.
[0043] Further, the selected optimum path is used by the UE A for connection checks with the UE B. Upon receiving a connection invite from UE A, the UE B may collect presence information pertaining to UE A from the registration server 102, and identify an optimum path to communicate with UE A. Further, the UE A and UE B establishes a Device to Device (D2D) communication each other, using the selected optimum paths.
[0044] The various actions in method 500 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 5 may be omitted.
[0045] FIGs. 6a, 6b, and 6c illustrate example scenarios of establishing a communication using the optimum path selection framework for devices in a local, public, and symmetrical Network Address Translation (NAT) networks respectively, according to embodiments as disclosed herein. In Fig. 6a, the devices UE 101.a and 101.b are in same local network. In this scenario, the UE 101.a and UE 101.b collect presence information from the registration server 102, and initiates local signaling directly between the devices to establish the connection.
[0046] In Fig. 6b, the devices UE 101.a and 101.b are in different public networks. In this scenario, the UE 101.a and UE 101.b collects presence information from the registration server 102, and initiates public connectivity check directly between the devices to establish the connection, without attempting local connectivity check.
[0047] In Fig. 6c, the devices UE 101.a and 101.b are behind symmetric NAT networks. In this scenario, the UE 101.a and UE 101.b collect presence information from the registration server 102, and initiates relay connectivity check directly between the devices to establish the connection, without attempting local, and relay connectivity checks.
[0048] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the elements. The elements shown in Figs. 1, 2, 3a, 3b and 4 can be at least one of a hardware device, or a combination of hardware device and software module.
[0049] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.

CLAIMS
We claim:

1. A method for establishing dynamic connectivity for setting up Device-to-Device communication between a connecting device and a target device in a Device to Device (D2D) communication network, said method comprising:
collecting presence information pertaining to said target device, by said connecting device from a registration server;
identifying at least one optimum path to connect with said target device, based on said presence information, by said connecting device; and
establishing said dynamic connectivity with said target device using said optimum path, by said connecting device.
2. The method as claimed in claim 1, wherein said presence information further comprises at least one of a firewall information and a Network Address Translation (NAT) type information pertaining to said target device.
3. The method as claimed in claim 1, wherein identifying said at least one optimum path further comprises comparing at least one of a firewall information and a Network Address Translation (NAT) type information pertaining to said targeted device with a reference database, by said connecting device.
4. The method as claimed in claim 1, wherein said optimum path uses at least one of a User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and a Hyper Text Transfer Protocol (HTTP).
5. The method as claimed in claim 4, wherein using at least one of said UDP, TCP, and HTTP for said optimum path further comprises:
using said UDP if firewall of said target device supports said UDP, by said communicating device;
checking if said firewall of said target device supports said TCP if said firewall does not support UDP, by said communicating device;
using said TCP if firewall of said target device supports said TCP, by said communicating device; and
using said HTTP if said firewall of said target device does not support said TCP, by said communicating device.
6. The method as claimed in claim 1, wherein establishing said dynamic connectivity, when said connecting device and said target device are in same local network, further comprises:
identifying by performing a background connectivity check that said connecting device is in said same local network, by said target device;
identifying by performing a background connectivity check that said target device is in said same local network, by said connecting device; and
initiating a direct signalling to establish said dynamic connectivity using said at least one optimum path, by at least one of said connecting device and said target device, if said target device and said connecting device belong to said local network.
7. The method as claimed in claim 1, wherein establishing said dynamic connectivity, when said connecting device and said target device are in different public networks further comprises:
identifying by performing a background connectivity check that said connecting device is in a different public network, by said target device;
identifying by performing a background connectivity check that said target device is in a different public network, by said connecting device;
collecting presence information pertaining to said target device from said registration server, by said connecting device;
collecting presence information pertaining to said connecting device from said registration server, by said target device; and
initiating a public connectivity check using at least one optimum path, by at least one of said connecting device and target device.
8. The method as claimed in claim 1, wherein establishing said dynamic connectivity, when said connecting device and said target device are behind symmetric NAT networks further comprises:
identifying by performing a background connectivity check that said connecting device is behind a symmetrical NAT network, by said target device;
identifying by performing a background connectivity check that said target device is behind a symmetrical NAT network, by said connecting device;
collecting presence information pertaining to said target device from said registration server, by said connecting device;
collecting presence information pertaining to said connecting device from said registration server, by said target device; and
initiating a relay connectivity check using at least one optimum path, by at least one of said connecting device and target device.
9. The method as claimed in claim 1, wherein said presence information pertaining to said connecting device and target device is pre-stored in said registration server, wherein pre-storing said presence information with said registration server further comprises:
registering at least one of said connecting device and target device with said registration server;
collecting said presence information pertaining to said at least one connecting device and target device, by said registration server;
storing said collected presence information in at least one database, by said registration server; and
updating said presence information stored in said database, by said registration server.
10. A device for establishing dynamic connectivity with at least one target device using Device-to-Device (D2D) communication, wherein said device and said target device are associated with a D2D communication network, said device configured for:
collecting presence information pertaining to said target device from a registration server;
comparing said presence information with a reference database stored in a memory module; and
identifying at least one optimum path to communicate with said target device.
11. The device as claimed in claim 10, wherein said device is further configured to identify said optimum path based on at least one of a firewall and a network Address Translation (NAT) type information pertaining to said target device, wherein said device is configured to collect information pertaining to said firewall and NAT type from said presence information.
12. The device as claimed in claim 10, wherein said device is further configured to use at least one of a User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and a Hyper Text Transfer Protocol (HTTP) with said optimum path.
13. The device as claimed in claim 12, wherein said device is further configured for selecting at least one of said UDP, TCP, and HTTP for said optimum path by:
using said UDP if firewall of said target device supports said UDP;
checking if said firewall of said target device supports said TCP if said firewall does not support UDP;
using said TCP if firewall of said target device supports said TCP, by said communicating device; and
using said HTTP if said firewall of said target device does not support said TCP.
14. The device as claimed in claim 10, wherein said device is further configured for initiating said dynamic connectivity with said target device, wherein initiating said dynamic connectivity comprises sending a communication invite to said target device.
15. The device as claimed in claim 10, wherein said device is further configured to initiate a direct signalling with said target device if said device and said target device are in same local network, wherein said device is configured to identify by performing a background connectivity check that said target device is in said same local network.
16. The device as claimed in claim 10, wherein said device is configured to initiate a public connectivity check, if said device and said target device are in different public networks, wherein said device is configured to identify by performing a background connectivity check that said target device is in a different public network.
17. The device as claimed in claim 10, wherein said device is configured to initiate a relay connectivity check, if said device and said target device are in symmetric Network Address Translation (NAT) networks, wherein said device is configured to identify by performing a background connectivity check that said target device is behind said symmetric NAT network.
18. A device for establishing dynamic connectivity with at least one connecting device using Device-to-Device (D2D) communication, wherein said device and said connecting device are associated with a D2D communication network, said device configured for:
receiving a communication invite from said connecting device;
collecting presence information pertaining to said connecting device from a registration server;
comparing said presence information with a reference database stored in a memory module; and
identifying at least one optimum path to communicate with said connecting device.
19. The device as claimed in claim 18, wherein said device is further configured to identify said optimum path based on at least one of a firewall and a network Address Translation (NAT) type information pertaining to said connecting device, wherein said device is configured to collect information pertaining to said firewall and NAT type from said presence information.
20. The device as claimed in claim 19, wherein said device is further configured to use at least one of a User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and a Hyper Text Transfer Protocol (HTTP) with said optimum path.
21. The device as claimed in claim 20, wherein said device is further configured for selecting at least one of said UDP, TCP, and HTTP for said optimum path by:
using said UDP if firewall of said connecting device supports said UDP;
checking if said firewall of said connecting device supports said TCP if said firewall does not support UDP;
using said TCP if firewall of said connecting device supports said TCP, by said communicating device; and
using said HTTP if said firewall of said connecting device does not support said TCP.
22. The device as claimed in claim 18, wherein said device is further configured to initiate a direct signalling with said connecting device if said device and said connecting device are in same local network, wherein said device is configured to identify by performing a background connectivity check that said connecting device is in said same local network.
23. The device as claimed in claim 18, wherein said device is configured to initiate a public connectivity check, if said device and said connecting device are in different public networks, wherein said device is configured to identify by performing a background connectivity check that said connecting device is in a different public network.
24. The device as claimed in claim 18, wherein said device is configured to initiate a relay connectivity check, if said device and said connecting device are in symmetric Network Address Translation (NAT) networks, wherein said device is configured to identify by performing a background connectivity check that said connecting device is behind said symmetric NAT network.
25. A registration server for supporting dynamic connectivity between a connecting device and a target device, said registration server configured for:
establishing a connection with at least one device;
collecting presence information pertaining to said at least one device;
updating said collected presence information; and
providing said collected presence information to at least one other device upon receiving a request from said at least one other device.
26. The registration server as claimed in claim 25, wherein said registration server is further configured to update said presence information periodically.
27. The registration server as claimed in claim 25, wherein said registration server is further configured to update said presence information upon detecting occurrence of at least one trigger event.

Date: 26 February 2015 Signature:
Kalyan Chakravarthy

ABSTRACT
Disclosed herein are a method and a User Equipment (UE) for establishing dynamic connectivity in a Device to Device (D2D) network. The UE updates own presence information with a registration server, during a registration process, and the presence information is updated on a periodic basis or upon occurrence of any pre-defined trigger event. The UE can function as a connecting device as well as a target device. While trying to establish a connection with a target device, the connecting device collects and checks presence information of the target device, and collects Network Address Translation (NAT) type and firewall information pertaining to the target device. Further, based on the collected NAT type and firewall information, the connecting device identifies an optimum path to communicate with the target device. Further, the connecting device establishes a Device to Device (D2D) communication with the target device, using the optimum path.

FIG. 1