Claims:WE CLAIM:

1. A scheduler (101) for multipath data transmission in a communication network (100), comprising:
a memory module (201) storing a plurality of instructions;
one or more communication interfaces (203); and
one or more hardware processors (202) coupled to the memory module via the one or more communication interfaces, wherein the one or more hardware processors are caused by the plurality of instructions to:
receive (302) a plurality of data packets to be transmitted to at least one destination, from at least one source, wherein a first path and at least one alternate path exist between the at least one source and the at least one destination;
collecting (304) a channel state information pertaining to the first path and the at least one alternate path, using a cross layer model, wherein the channel state information is represented using a Received Signal State Information (RSSI) value of the first path and the at least one alternate path;
collecting (306) information pertaining to value of Round Trip Time (RTT) of at least the first path and the at least one alternate path;
determining one of the first path and the at least one alternate path as a target path for data transmission, at each time instance considered, by:
comparing value of absolute difference between RTT value of the first path (RTT1) and RTT value of the at least one alternate path (RTT2) with a threshold of difference of RTT (RTTdiffTH);
if the value of absolute difference between RTT1 and RTT2 exceeds the RTTdiffTH:
selecting (318) the first path as the target path if RTT1 < RTT2; and
selecting (320) the at least one alternate path as the target path if RTT2 < RTT1;
if the value of absolute difference between RTT1 and RTT2 is less than the RTTdiffTH:
selecting (318) the first path as the target path if RSSI2 < RSSI1; and
selecting (320) the at least one alternate path as the target path if RSSI1 < RSSI2; and
transmitting at least one of the plurality of data packets to the at least one destination, via the target path.

2. The scheduler as claimed in claim 1, wherein the RTTdiffTH is pre-defined.
3. The scheduler as claimed in claim 1, wherein the scheduler uses a Multipath TCP (MPTCP) protocol for the multipath data transmission.
4. The scheduler as claimed in claim 3, wherein the cross layer model collects the channel state information from a Data Link Layer (DLL) of the MPTCP protocol and makes the collected channel state information available to the scheduler.
5. A processor implemented method for multipath data transmission in a communication network, comprising:
receiving (302) a plurality of data packets to be transmitted to at least one destination, from at least one source, by a scheduler of the communication network, wherein a first path and at least one alternate path exist between the at least one source and the at least one destination;
collecting (304) a channel state information pertaining to the first path and the at least one alternate path, using a cross layer model by the scheduler, wherein the channel state information is represented using a Received Signal State Information (RSSI) value of the first path and the at least one alternate path;
collecting (306) information pertaining to value of round trip time (RTT) of at least the first path and the at least one alternate path by the scheduler;
determining one of the first path and the at least one alternate path as a target path for data transmission, at each time instance considered, by the scheduler, comprising:
comparing value of absolute difference between RTT value of the first path (RTT1) and RTT value of the at least one alternate path (RTT2) with a threshold of difference of RTT (RTTdiffTH);
if the value of absolute difference between RTT1 and RTT2 exceeds the RTTdiffTH:
selecting (318) the first path as the target path if RTT1 < RTT2; and
selecting (320) the at least one alternate path as the target path if RTT2 < RTT1;
if the value of absolute difference between RTT1 and RTT2 is less than the RTTdiffTH:
selecting (318) the first path as the target path if RSSI2 < RSSI1; and
selecting (320) the at least one alternate path as the target path if RSSI1 < RSSI2; and
transmitting at least one of the plurality of data packets to the at least one destination, via the target path, by the scheduler.
6. The method as claimed in claim 5, wherein the RTTdiffTH is pre-defined.
7. The method as claimed in claim 5, wherein the scheduler uses a Multipath TCP (MPTCP) protocol for the multipath data transmission.
8. The method as claimed in claim 7, wherein the cross layer model collects the channel state information from a Data Link Layer (DLL) of the MPTCP protocol and makes the collected channel state information available to the scheduler.
, Description:TECHNICAL FIELD
[001] The disclosure herein generally relates to communication networks, and, more particularly, to a cross layer multipath scheduler in the communication networks.

BACKGROUND
[002] Most of the communication devices of the new era are equipped with multiple radio interfaces for communication, and appropriate protocols have been developed to facilitate communication through the multiple radio interfaces. Multipath Transmission Control Protocol (MPTCP) is one such protocol that has been developed to support the multipath communication.
[003] Such devices capable of multipath communications are connected with a destination via multiple paths, and one or more of the paths can be used by the device to communicate with the destination. For example, consider a smartphone that needs to upload data to a cloud server. The device may be connected with the cloud server via mobile network and through a Wi-Fi connection. Either of the networks can be used for the data transmission from the mobile device to the cloud server.
[004] Selection of at least one of the available paths for the data transmission is handled during scheduling of the packets. Conventional schedulers are designed to identify path having best channel quality and to transmit the packets. However one disadvantage of this approach is that forwarding all/majority of the packets to the channel having best quality increases queue waiting time, i.e., even though the packets are in best quality channel, they may have to wait, which in turn delays the data transmission. Further, channel quality of wireless networks degrades at a faster rate in comparison with that of a wired network. As the conventional schedulers are not designed to consider such characteristics of the wireless networks which indicate the real-time performance, the communication is affected.
SUMMARY
[005] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, a scheduler for multipath data transmission in a communication network is provided. The scheduler includes a memory module storing a plurality of instructions, one or more communication interfaces, and one or more hardware processors coupled to the memory module via the one or more communication interfaces. The one or more hardware processors are caused by the plurality of instructions to receive a plurality of data packets to be transmitted to at least one destination, from at least one source, wherein a first path and at least one alternate path exist between the at least one source and the at least one destination. Further a channel state information pertaining to the first path and the at least one alternate path is collected. Here, the channel state information of a path is collected as channel state information of the link associated with the source of the corresponding path. Each path may consist of one or more links and out of those links the first link is always a wireless link. The channel state information of only the first link is collected not of the entire path. These channel states information collected at the source are passed to the upper layer (i.e. transport layer) using cross layer model. The channel state information is represented using a Received Signal State Information (RSSI) value of the first path and the at least one alternate path. Further, information pertaining to value of round trip time (RTT) of at least the first path and the at least one alternate path are collected. Further, one of the first path and the at least one alternate path is decided as a target path for data transmission, at each time instance considered, by comparing value of absolute difference between RTT value of the first path (RTT1) and RTT value of the at least one alternate path (RTT2) with a threshold of difference of RTT (RTTdiffTH). If the value of absolute difference between RTT1 and RTT2 exceeds the RTTdiffTH, then the first path is selected as the target path if RTT1 < RTT2, and the at least one alternate path is selected as the target path if RTT2 < RTT1. If the value of absolute difference RTT1 and RTT2 is less than the RTTdiffTH, then the first path is selected as the target path if RSSI2 < RSSI1 and the at least one alternate path is selected as the target path if RSSI1 < RSSI2. Further, at least one of the plurality of data packets is transmitted to the at least one destination, via the target path.
[006] In another aspect, a method for multipath data transmission in a communication network is provided. In this method, a scheduler of the communication network receives a plurality of data packets to be transmitted to at least one destination, from at least one source, wherein a first path and at least one alternate path exist between the at least one source and the at least one destination. Further a channel state information pertaining to the first path and the at least one alternate path is collected. Here, the channel state information of a path is collected as the channel state information of the link associated with the source of the corresponding path. Each path may consist of one or more links and out of those links the first link is always a wireless link. The channel state information of only the first link is collected not of the entire path. These channel states information collected at the source are passed to the upper layer (i.e. transport layer) using cross layer model. The channel state information is represented using a Received Signal State Information (RSSI) value of the first path and the at least one alternate path. Further, information pertaining to value of Round Trip Time (RTT) of at least the first path and the at least one alternate path are collected. Further, one of the first path and the at least one alternate path is decided as a target path for data transmission, at each time instance considered, by comparing value of absolute difference between RTT value of the first path (RTT1) and RTT value of the at least one alternate path (RTT2) with a threshold of difference of RTT (RTTdiffTH). If the value of absolute difference between RTT1 and RTT2 exceeds the RTTdiffTH, then the first path is selected as the target path if RTT1 < RTT2, and the at least one alternate path is selected as the target path if RTT2 < RTT1. If the value of absolute difference RTT1 and RTT2 is less than the RTTdiffTH, then the first path is selected as the target path if RSSI2 < RSSI1 and the at least one alternate path is selected as the target path if RSSI1 < RSSI2. Further, at least one of the plurality of data packets is transmitted to the at least one destination, via the target path.
[007] In yet another aspect, a non-transitory computer readable medium for multipath data transmission in a communication network is provided. In this method, the non-transitory computer readable medium uses a scheduler of the communication network receives a plurality of data packets to be transmitted to at least one destination, from at least one source, wherein a first path and at least one alternate path exist between the at least one source and the at least one destination. Further a channel state information pertaining to the first path and the at least one alternate path is collected. Here, the channel state information of a path is collected as channel state information of the link associated with the source of the corresponding path. Each path may consist of one or more links and out of those links the first link is always a wireless link. The channel state information of only the first link is collected not of the entire path. These channel states information collected at the source are passed to the upper layer (i.e. transport layer) using cross layer model. The channel state information is represented using a Received Signal State Information (RSSI) value of the first path and the at least one alternate path. Further, information pertaining to value of round trip time (RTT) of at least the first path and the at least one alternate path are collected. Further, one of the first path and the at least one alternate path is decided as a target path for data transmission, at each time instance considered, by comparing value of absolute difference between RTT value of the first path (RTT1) and RTT value of the at least one alternate path (RTT2) with a threshold of difference of RTT (RTTdiffTH). If the value of absolute difference between RTT1 and RTT2 exceeds the RTTdiffTH, then the first path is selected as the target path if RTT1 < RTT2, and the at least one alternate path is selected as the target path if RTT2 < RTT1. If the value of absolute difference RTT1 and RTT2 is less than the RTTdiffTH, then the first path is selected as the target path if RSSI2 < RSSI1 and the at least one alternate path is selected as the target path if RSSI1 < RSSI2. Further, at least one of the plurality of data packets is transmitted to the at least one destination, via the target path.
[008] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[009] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
[010] FIG. 1 illustrates an exemplary communication network in which multipath communication between a source device and a destination device is provided, according to some embodiments of the present disclosure.
[011] FIG. 2 is a functional block diagram depicting components of a scheduler, according to some embodiments of the present disclosure.
[012] FIGS. 3A, 3B, and 3C (collectively referred to as FIG. 3 and method 300) illustrate steps involved in the process of determining target path for communication, using the scheduler of FIG.2, in accordance with some embodiments of the present disclosure.
[013] FIG. 4 is an example diagram depicting cross layer mechanism used by the scheduler for collecting channel state information, according to some embodiments of the present disclosure.
[014] FIGS. 5A, 5B, and 5C illustrate experimental values of different parameters for the scheduler of FIG.2, according to some embodiments of the present disclosure.
[015] FIGS. 5D, 5E, and 5F illustrate experimental values of different parameters for a reference scheduler, according to some embodiments of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS
[016] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims.
[017] Referring now to the drawings, and more particularly to FIG. 1 through FIG. 5F, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[018] FIG. 1 illustrates an exemplary communication network in which multipath communication between a source device and a destination device is provided, according to some embodiments of the present disclosure. In FIG.1, one source device 101.a (alternately referred to as ‘source’) is communicating with (or is involved in data transfer with) a destination device 101.b (alternately referred to as ‘destination’). The source device 101.a and the destination device 101.b may be any type of communication device with capability to perform multipath communication. For example, the source device 101.a and the destination device 101.b are smartphones. In another example, the source device 101.a is a smartphone and the destination device 101.b is a central server that may be hosted in a local network or in a cloud based platform. It is to be noted that the number of source devices 101.a and the destination devices 101.b may vary according to implementation standards and from one communication network to another. Similarly the number of paths that exist between the source device 101.a and the destination device 101.b also can vary. In an example, the number of paths that exist between the source device 101.a and the destination device 101.b is two, i.e., the first path and one alternate path. In another example, the number of paths that exist between the source device 101.a and the destination device 101.b is three, i.e., the first path and two alternate paths. Similarly any number of paths may be used as per requirements. For illustration and explanation purpose, one source device 101.a and one destination device 101.b are considered. When there is more than one source device 101.a and corresponding destination devices 101.b in the communication network 100 at a particular instance, for each source device – destination device pair, steps in the method 300 (as in FIG. 3) are executed so as to find the target path(s). Further, each path may have one or more links, wherein the number of links that form a path may vary. For example, a path between the source device 101.a and the destination device 101.b may have a first link between the source device 101.a and an access point, a second link between the access point and a router, and a third link between the router and the destination device 101.b.
[019] The source device 101.a can transmit data packets to the communication through the communication paths. A scheduler 102 at the source device 101.a receives and processes all packets to be transmitted to the destination device 101.b. The scheduler 102 determines at least one of the available paths as a target path, and then transmits the data packets through the target path(s). Working details of the scheduler 102 for the purpose of identifying the target path(s) is explained with description of FIG. 2.
[020] FIG. 2 is a functional block diagram depicting components of a scheduler, according to some embodiments of the present disclosure. The scheduler 102 includes at least one memory module 201, at least one hardware processor 202, and at least one communication interface 203.
[021] The one or more hardware processors 202 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, graphics controllers, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the hardware processor(s) 202 are configured to fetch and execute computer-readable instructions stored in the memory module 201, which causes the hardware processor(s) 102 to perform actions depicted in FIG. 3 for the purpose of determining one or more of the available paths as target path(s), in turn causing the scheduler 102 to perform scheduling involving determining the target path(s) and transmitting data packet(s) through the determined target path(s). In an embodiment, the scheduler 102 can be implemented in a variety of computing systems, such as laptop computers, notebooks, hand-held devices, workstations, mainframe computers, servers, a network cloud and the like.
[022] The communication interface(s) 203 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the communication interface(s) 203 can include one or more ports for connecting a number of devices to one another or to another server.
[023] The memory module(s) 201 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, one or more modules (not shown) of the scheduler 102 can be stored in the memory 201. The memory module(s) 201 stores a plurality of instructions which when executed, cause the one or more hardware processors 202 to perform the to perform the actions depicted in FIG. 3 for the purpose of determining one or more of the available paths as target path(s). For explaining working of the scheduler 102 and the process of identifying the target path(s) for communication, a communication network 100 including one source device 101.a and one destination device 101.b is selected.
[024] Upon receiving a plurality of data packets to be transmitted to the destination device 101.b, the scheduler 102 in the source device 101.a collects (received Signal Strength Indicator) RSSI value of each of the available paths (i.e. the first path and the at least one alternate path) as channel state information pertaining to the corresponding path. In an embodiment, RSSI value of a first link (i.e. link connected to a source 101.a to which the path is connected) is collected as RSSI value of the path, and represents channel state information of the path. In an embodiment, a cross layer mechanism (as depicted in FIG. 4) is used by the scheduler 102 to collect the channel state information pertaining to each of the paths being considered. In an embodiment, the channel state information of each path may be different at different instances of time. In order to take into consideration latest channel state information, real-time RSSI value data is collected by the scheduler 102 through the feedback channels provided by the cross layer mechanism, for each of the data packets received. The cross layer mechanism collects the RSSI values at Data Link Layer (DLL) and makes it available to the scheduler. The cross layer mechanism considers each individual path as discrete, time varying, and block faded. An assumption made here is that the channel state information for an instance/time-slot does not change during the complete time slot. For simplicity purpose, a two-state block fading model is considered. In this model, {h[n] = Good (G)} for a path indicates that the path is in good condition in nth time slot which in turn means that the channel gain is more and fading is less. Whereas {h[n] = Bad (B)} for a path indicates that the path is in bad condition in nth time slot which in turn means that the channel gain is less than a threshold.
[025] The scheduler 102 then collects information pertaining to a Round Trip Time (RTT) of each of the channels. The RTT value of a channel is time taken by a data packet to travel from the source device 101.a to the destination device 101.b and back, and represents/indicates congestion in the path. For example, a high value of RTT for a path indicates that there is congestion in the path and a lower value of RTT represents that the path is relatively free of traffic.
[026] The scheduler 102 is configured to consider the channel state information (represented by the RSSI values) and the RTT values together to determine/identify the target path for data transmission. In certain scenarios, even though channel quality (as indicated by the corresponding RSSI value) may be comparatively low for a path, the congestion along the path (as indicated by the RTT value) may be less. If a data packet is to reach the destination device 101.b without much delay, the path having the least RTT value is to be selected. However the RSSI value should not be very low that the transmission of the data packet is adversely affected. The scheduler 102 considers both the RSSI values and the RTT values, in order to determine the target path(s), such that probability of a data packet reaching the destination device 101.b when transmitted through each path is assessed based on the RTT and RSSI values. Determining the target path(s) based on the RSSI and RTT values of the available paths is depicted in FIG.3 and is explained below (by considering a single source device – single destination device – and a two path scenario (a first path and one alternate path)):
[027] The scheduler 102 calculates absolute difference between the RTT values of the first path (RTT1) and the alternate path (RTT2) and compares the value of absolute difference between the RTT1 and RTT2 with a threshold of difference of RTT (RTTdiffTH). If the value of absolute difference between RTT values of the first path and the alternate path i.e. |RTT1 – RTT2| exceeds the RTTdiffTH, that implies that there is a considerable difference between RTT values of the first path and the alternate path. If |RTT1 – RTT2| > RTTdiffTH, then the scheduler 102 picks the path (from the first path and the alternate path) having least value of RTT as the target path.
i.e. if RTT1> RTT2, then select the second path as the target path
if RTT2> RTT1, then select the first path as the target path
[028] If the absolute difference between RTT values of the first path and the alternate path i.e. |RTT1 – RTT2| is less than the RTTdiffTH, that implies that there is not considerable difference between RTT values of the first path and the alternate path. In this scenario, as the congestion in the first path and that in the alternate path are pretty much the same, the scheduler 102 considers channel state information as well (in terms of RSSI value of each path) so as to improve reliability of delivery of the data packets. If |RTT1 – RTT2| > RTTdiffTH, then the scheduler 102 compares the RSSI values of the first path and that of the alternate path, and selection of the target path is based on the following criteria:
if RSSI1> RSSI2, then channel quality of the first path is better than that of the alternate path, and hence the first path is selected as the target path
if RSSI2> RSSI1, then channel quality of the alternate path is better than that of the first path, and hence the alternate path is selected as the target path
[029] If the number of paths exceeds two (i.e. the first path and multiple alternate paths), then the RTT values and RSSI values of the paths are compared in the similar manner as explained above, to determine the target path(s). For example, if three paths are available (i.e. the first path, a first alternate path, and a second alternate path), then the scheduler 102 may compare RTT and RSSI values of the first path and the first alternate path first, and one of the first path and the first alternate path is selected, which in turn is compared with the second alternate path to determine the target path(s). If multiple paths exist, then the selection of two paths at each stage for the comparison may be at a random order or may be based on a pre-defined order.
[030] After determining the target path, the scheduler 102 transmits the data packets to the destination device 101.b through the determined target path.
[031] FIGS. 3A, 3B, and 3C (collectively referred to as FIG. 3 and method 300) illustrate steps involved in the process of determining target path for communication, using the scheduler of FIG.2, in accordance with some embodiments of the present disclosure. The scheduler 102 at the source device 101.a receives (302) a plurality of data packets to be transmitted to at least one destination device 101.b. The data packets received may be temporarily stored in a buffer in the memory module 201.
[032] The scheduler 102 then collects (304) RSSI values representing channel state information of a first path and at least one alternate path that exist between the source device 101.a and the destination device 101.b, using a cross layer mechanism, for every data packet received. The scheduler 102 further collects (306) information pertaining to RTT values of the first path and the at least one alternate path, and checks (308) if the absolute difference between the RTT values of the first path and the at least one alternate path exceeds a threshold of difference of RTT (RTTdiffTH). RTTdiffTH is a measure of relative congestion of different paths between a pair of source and destination. The value of RTTdiffTH indicates relative usability of the paths for packet transmission. The value of RTTdiffTH can be decided by Quality of Service (QoS) requirement of the type of applications used, whose packets are to be transmitted between the source and the destination using the MPTCP. QoS requirement can be a measure of the delay guarantee of the application and RTTdiffTH provides a mechanism to decide when it is better to choose the path based on RTT only.
[033] If |RTT1 – RTT2| > RTTdiffTH, then the scheduler 102 picks the path (from the first path and the alternate path) having least value of RTT as the target path.
i.e. if RTT1> RTT2, then select (320) the alternate path as the target path
if RTT2> RTT1, then select (318) the first path as the target path
[034] If the absolute difference between RTT values of the first path and the alternate path i.e. |RTT1 – RTT2| is less than the RTTdiffTH then the scheduler 102 compares (314) RSSI value (for the corresponding wireless links available at the source, wherein these wireless links are a part of corresponding end-to-end paths between the source and the destination) of the first path with that of the alternate path, so as to improve reliability of delivery of the data packets, and at this stage the selection of the target path is based on the following criteria:
if RSSI1> RSSI2, then channel quality of the first path is better than that of the alternate path, and hence the first path is selected (318) as the target path
if RSSI2> RSSI1, then channel quality of the alternate path is better than that of the first path, and hence the alternate path is selected (320) as the target path
Example implementations:
[035] The communication network 100 may comprise ‘n’ number of devices. Out of the ‘n’ devices, in certain scenarios only one device may be acting as the source device 101.a. In some other situations, more than one source device 101.a may be present at a given time, which means more than one of the ‘n’ devices are in communication with corresponding destination device 101.b. Multiple paths may exist for each source device 101.a – destination device 101.b pair. The scheduler 102 of the communication network 100 is configured to perform the method 300 simultaneously for each source device 101.a – destination device 101.b pair, so as to identify the target path corresponding to each pair. Similarly, in an alternate embodiment, one source device 101.a may be communicating with more than one destination device 101.b at a time. In this scenario, for each source device 101.a – destination device 101.b pair, corresponding target path is identified by the scheduler 102.
Experimental results and simulation results:
[036] So as to study MPTCP behavior under various wireless channel conditions, RSSI value of every received data packet (packet) from physical layer is passed to transport layer. Modulation Error Ratio (MER) was used to determine the RSSI values of the packets received, wherein MER is defined as a measure of the Signal to Noise Ratio (SNR) in digital modulation applications. The MER calculated for two separate paths is depicted in Fig. 5A. Similarly, RTT and Cumulative Distribution Function (CDF) also were calculated. The RTT and the CDF are depicted in Fig. 5B and Fig. 5C respectively.
[037] To compare results of the target path identification being carried out by the scheduler 102 with another scheduler, the parameters MER, RTT, and CDF are plotted in Fig. 5D, Fig. 5E, and Fig. 5F. A condition here is that |RTT1 – RTT2| does not exceed RTTdiffTH. Also, value of RTTdiffTH was assumed as 5 ms for the simulation. However the value of RTTdiffTH can be varied based on the application and requirements.
[038] Consider region (a) and region (b) in Fig. 5C. In region (a), no packets have been transmitted through path 2 even though RTT is smaller than that of path 1 unlike region (a) in Fig. 5F. This is because even though the MER value for the Link1 is much higher than the Link2, but the absolute difference of RTT for path1 and path2 crosses the given threshold value, i.e. RTTdiffTH = 5ms. Here the value ‘5’ was decided by Quality of Service (QoS) requirement of the type of application for which the data packets are to be transmitted through the target path(s) being determined. Hence, sending packets overpath1 may lead to much higher packet loss leading to the reduced throughput. At the same time during Fig. 5C-region (b), the scheduler 102 causes to transmit packets through the path2 because during this period the MER values of Link2 are better than that of Link1 and also the value of |RTT1-RTT2| is below the threshold RTTdiffTH. This is in contrast with that of Fig. 5F-region (b) where the transmission path is chosen only based on RTT values. The corresponding packet losses for different noise levels for the two scheduling algorithms (i.e. method 300 and another one) plotted in Fig. 5G indicate that the scheduling (target path selection) being carried out by the scheduler 102 has advantage over the other scheduling mechanism considered.
[039] In another experiment, wireless link conditions for both the links (link1 and link2) were kept as constant, link2 having more error rate than link1 with noise variance 0.2 and 1 respectively. The simulation results under this scenario indicated that the cross-layer model used by the scheduler 102 succeeds in keeping RTT of each path below some given threshold. At the same time the packets are pushed onto the link having higher SNR as long as the RTTdiffTH constraint is maintained. As shown in the Table.1, in case of the Cross-Layer model used by the scheduler 102, the RTT of each path remain less than the given threshold value and also the absolute difference between the RTTs of path1 and path2 also remain under the RTTdiffTH, irrespective of the links conditions, as opposed to the practice of pushing data packets through path having lesser RTT value irrespective of the link conditions.
Link1 noise variance Cross layer model used by scheduler 102 State of art scheduler
RTT1 RTT2 RTT1 RTT2
0.2 0.1 1.97 0.01 3.2
0.4 0.01 0.62 1.97 3.1
0.6 2.07 2.71 0.01 3.6
0.8 1.97 0.77 0.01 7.6
1 2.7 2.6 0.01 7.8
1.2 2.71 2.71 1.97 7.4

Table. 1
[040] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[041] The embodiments of present disclosure herein addresses unresolved problem of selection of target path for communication in a multipath scenario. The embodiment, thus provides a mechanism to identify reliability of channels based on RSSI and RTT values together. Moreover, the embodiments herein further provides a mechanism to determine at least one of the available paths as a target path, for data transmission.
[042] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[043] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[044] The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[045] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[046] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.