DESC:FIELD OF INVENTION
[001] The present invention relates to the field of communication networks and more particularly to communication networks, specially using Multipath-Transmission Control Protocol (MP-TCP).
BACKGROUND OF INVENTION
[002] When using MPTCP, the receive window is shared by multiple subflows. However, the parameters are typically fixed and do not vary with the availability of networks and their conditions. In an example, current MPTCP and TCP implementations do not consider the bandwidth-delay product (BDP) of multiple interfaces present, which in turn causes a low throughput (if the receive window size is too small) and packet loss (if the receive window size is too large).
OBJECT OF INVENTION
[003] The principal object of the embodiments herein is to disclose systems and methods to calculate at least one tuned user space parameter for multiple communication paths depending on current operational conditions in the networks corresponding to the communication paths.
[004] Another object of the invention is to disclose systems and methods to calculate at least one tuned user space parameter for multiple communication paths depending on current network operational conditions, which can handle fluctuations in the networks corresponding to the communication paths.
SUMMARY
[005] Accordingly the invention provides a method for managing a User Equipment (UE), the method comprising determining a current operational state of the UE and current conditions of at least one communication interface present in the UE, wherein the current operation state comprises of MPTCP and TCP status; and determining at least one tunable parameter by the UE based on the current operation state of the UE and current conditions of the at least one communication interface.
[006] Accordingly the invention provides a User Equipment (UE) configured for determining a current operational state of the UE and current conditions of at least one communication interface present in the UE, wherein the current operation state comprises of MPTCP and TCP status; and determining at least one tunable parameter by the UE based on the current operation state of the UE and current conditions of the at least one communication interface.
[007] 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
[008] 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:
[009] FIG. 1 depicts a UE configured for determining at least one optimal parameter, according to embodiments as disclosed herein;
[0010] FIG. 2 is a flowchart depicting a process of determining at least one optimal tunable parameter, according to embodiments as disclosed herein; and
[0011] FIG. 3 is a flowchart depicting an example process of determining the optimal buffer size, according to embodiments as disclosed herein.
DETAILED DESCRIPTION OF INVENTION
[0012] 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.
[0013] The embodiments herein disclose systems and methods to calculate at least one tunable user space parameter for multiple communication paths depending on current conditions of the networks corresponding to the communication paths. Referring now to the drawings, and more particularly to FIGs. 1 through 3, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments.
[0014] The User Equipment (UE), as disclosed herein can be a device that can use Multipath-Transmission Control Protocol (MP-TCP) for communication using at least one communication interface. Examples of the UE can be, but not limited to, mobile phones, smart phones, laptops, computers, tablets, Internet of Things (IoT) devices, wearable computing devices, imaging devices, vehicle infotainment systems, location devices/trackers, and so on.
[0015] Embodiments herein disclose systems and method to determine at least one optimal tunable parameter to be set in the UE, if the UE operates in TCP and/or MPTCP accordingly. The optimal tunable parameter can be for any user space parameter that can be tuned such as buffer size, initial congestion window size (initcwnd), initial receive window size (initrwnd), congestion control (coupled/uncoupled), TCP memory (tcp_mem), tcp_limit_output_bytes, tcp_no_metrics_save, tcp_low_latency, packet packing factor, interrupt binding, window scaling, timestamping, sack or other ack methodology, memory per socket, window size, and so on. The optimal tunable parameter can also comprise of parameters related to Central Processing Unit (CPU) boosting (such as cpuinfo_min_freq, cpuinfo_max_freq, min/max operating frequency the CPU can run, scaling_governor, bios_limit scaling_min_freq, scaling_max_freq, and so on). The tunableparameter can depend on current network conditions and operational conditions, such as number of interfaces, type of interfaces and also interface specific parameters such as interface current Round Trip Time (RTT), packet loss/jitter in the interface. It also may include other operational dynamic parameters such as data rate, Received Signal Strength Indicator (RSSI), Signal to Noise Ratio (SNR), antenna gain, location, and so on.
[0016] Consider an example, wherein the UE calculates the buffer size (also referred to herein as optimal bandwidth-delay product (BDP)) for multiple paths depending on the current network conditions and operational conditions. As the optimal buffer size depends on current network conditions and operational conditions, fluctuations in the network can be handled.
[0017] FIG. 1 depicts a UE configured for estimating at least one optimal parameter. The UE 101, as depicted, comprises of an estimation block102, a MPTCP tuner 103, a connectivity manager 104, a plurality of communication interfaces 105, and a CPU governor 106. The connectivity manager 104 can use one or more of the communication interfaces 105, using MPTCP or TCP. The connectivity manager 104 can determine the current operational state of the UE 101. The current operational state can be in terms of MPTCP statuses, TCP statuses, and so on and the operational condition of the communication interfaces 105 (comprising of information such as buffer size, maximum buffer size, interface current Round Trip Time (RTT), packet loss/jitter in the interface data rate, Received Signal Strength Indicator (RSSI), Signal to Noise Ratio (SNR), antenna gain, location, and so on)). Based on the detected operation state, the estimation block 102 can determine at least one tuned user space parameter and the MPTCP tuner 103 can tune the MPTCP/TCP, according to the determined user space parameter. Based on the detected operation state, the CPU governor 106 can determine at least one parameter related to the CPU, based on the status of the communication interfaces and indications received from the connectivity manager 104. The CPU as referred to herein can comprise of at least one processing unit present in the UE 101. The CPU can also include graphic processing units present within the UE 101.
[0018] In an example, the connectivity manager 104 can monitor the communication interfaces 105 for at least one pre-defined event that can affect the traffic flow (operational and/or network event), such as addition of an interface, removal/disabling of an interface, a change in the speed/connectivity of an interface, and so on. On detecting at least one event, the connectivity manager 104 can send an indication to the MPTCP tuner 103, and the estimation block 102. The indication can also comprise of the currently active communication interfaces, information related to each of the currently active communication interfaces (such as buffer size, maximum buffer size, interface current Round Trip Time (RTT), packet loss/jitter in the interface data rate, Received Signal Strength Indicator (RSSI), Signal to Noise Ratio (SNR), antenna gain, location, and so on).
[0019] The estimation block 102 determines an optimalbuffer size for the active buffer size. Initially, the estimation block 102 can determine an intermediate buffer size by summing the available buffer sizes (n(y)) for all the active communication interfaces (y), as depicted in equation (1).
?? ?? = ?? ?? , ??=1 ?? ?? , ??>1????=1 (1)
where x is the number of active communication interfaces.
[0020] The estimation block 102 can then compare the intermediate buffer (f(x)) with a maximum threshold buffer parameter (max_buff)and considering the minimum parameter (from the intermediate buffer and the maximum threshold buffer parameter) as the optimum buffer size (F(x)) (as depicted in equation (2)).
?? ?? =min(?? ?? ,max_????????) (2)
[0021] In an example herein, consider that there are two technologies: 3ca and 5GHz Wi-Fi. The total send/receive buffer size would be
?? ?? =?? 3???? + ??(5 ?????? ????-????)
[0022] Based on the determined optimum buffer size, the MPTCP tuner 103 can set send/receive window size limits.
[0023] In an example herein, the estimation block 102 can set the congestion control algorithm to be used for connections. The estimation block 102 can consider a coupled congestion algorithm (such as Balia, Linked Increases Algorithm (LIA), Opportunistic Linked Increases Algorithm (OLIA), and so on), if MPTCP is being used. The estimation block 102 can consider an uncoupled congestion algorithm (such as Cubic, Binary Increase Congestion (BIC), RENO, and so on), if TCP is being used. The estimation block 102 can consider an uncoupled congestion algorithm if MPTCP is being used if aggressive performance is required.
[0024] As MPTCP uses multiple subflows, the initial congestion window (CWND) parameter can be too high. In an example herein, the estimation block 102 can determine suitable parameters for the initcwnd and initrwnd. In an embodiment herein, the estimation block 102 can determine a minimum parameter, such that the fairness is safeguarded. In an embodiment herein, the estimation block 102 can determine an aggressive parameter, based on operational conditions.
[0025] tcp_mem parameter refers to the number of pages allowed for queuing by all TCP sockets. In an example herein, as MPTCP uses more sockets, the estimation block 102 can increase this parameter according to the number of connections or number of sockets created.
[0026] tcp_limit_output_bytes controls the queue limit per TCP socket. In an example herein, as MPTCP uses more sockets, the estimation block 102 can increase this parameter according to the number of connections or number of sockets created.
[0027] In another example, the CPU governor 106 can determine parameters related to CPU boosting. CPU boosting can including tuning of one or more the parameters such as such as cpuinfo_min_freq, cpuinfo_max_freq, min/max operating frequency the processor can run, scaling_governor, bios_limit scaling_min_freq, scaling_max_freq, and so on. Further, the CPU governor 106 can determine the policy of CPUfreq from one of the available schemes such as performance, power save, user space, on demand, and so on. The selected policy can depend on whether TCP or MPTCP is being used. If MPTCP "performance" governor is set, the CPU governor 106 can set the TCP "On demand" policy.
[0028] FIG. 2 is a flowchart depicting a process of determining at least one optimal parameter. The connectivity manager 104 determines (201) the current operational state of the UE 101. The current operational state can be in terms of MPTCP statuses, TCP statuses, and so on and the operational condition of the communication interfaces 105. The connectivity manager 104 sends (202) information related to the current operational state of the UE 101to the other blocks such as MPTCP tuner 103, the estimation block 102, the CPU governor 106, and so on. The estimation block 102 determines (203) at least one tunable user space parameter, based on the received indication. The estimation block 102 sends (204) the determined user space parameter(s) to the MPTCP tuner 103. The MPTCP tuner 103 accordingly sets (205) the determined user space parameter(s). Similarly, the CPU governor 106 determines (206) parameters related to CPU boosting, based on the received indication and the CPU accordingly sets (207) the determined parameters. The various actions in method 200 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 2 may be omitted.
[0029] FIG. 3 is a flowchart depicting an example process of determining the optimal buffer size. The connectivity manager 104 monitors (301) the communication interfaces 105 for at least one pre-defined event that can affect the traffic flow to/from the UE 101. On detecting at least one event, the connectivity manager 104 sends (302) an indication to the MPTCP tuner 103, and the estimation block 102. The estimation block 102 determines (303)the intermediate buffer size by summing the available buffer sizes for all the active communication interfaces. The estimation block 102 then compares (304) the intermediate buffer with the maximum threshold buffer parameter and considers (305) the minimum parameter (from the intermediate buffer and the maximum threshold buffer parameter) as the optimum buffer size. The estimation block 102 sends (306) the determined optimum buffer size to the MPTCP tuner 103. The MPTCP tuner 103 accordingly sets (307) send/receive window size limits. The various actions in method 300 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 3 may be omitted.
[0030] Embodiments herein can provide more stable throughput over varied network conditions. Embodiments herein can provide better utilization of available network resources and bandwidth. Embodiments herein can provide better data transfer to battery consumption ratio when using multiple communication interfaces for download and upload. Embodiments herein can enable throughput enhancement by more than 30%.
[0031] 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 Fig. 1can be at least one of a hardware device, or a combination of hardware device and software module.
[0032] 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:CLAIMS
We claim:
1. A method for managing a User Equipment (UE) (101), the method comprising
determining a current operational state of the UE (101) and current conditions of at least one communication interface (105) present in the UE (101), wherein the current operation state comprises MPTCP status and TCP status; and
determining at least one tunable parameter by the UE (101) based on the current operation state of the UE (101) and current conditions of the at least one communication interface (105).

2. The method, as claimed in claim 1, wherein the at least one tunable parameter comprises buffer size, initial congestion window size (initcwnd), initial receive window size (initrwnd), congestion control algorithm, TCP memory (tcp_mem), tcp_limit_output_bytes,tcp_no_metrics_save, tcp_low_latency, packet packing factor, interrupt binding, window scaling, timestamping, ack methodology, memory per socket, window size, cpuinfo_min_freq of a Central Processing Unit (CPU), cpuinfo_max_freq of the CPU, min/max operating frequency of the CPU, scaling_governor of the CPU, bios_limit of the CPU, scaling_min_freq of the CPU, and scaling_max_freq of the CPU.

3. The method, as claimed in claim 2, wherein the method of determining the buffer size comprises:
determining an intermediate buffer size by summing all available buffer sizes for all active communication interfaces by an estimation block (102) in the UE (101), on a connectivity manager (104) detecting at least one pre-defined event; and
determining the buffer size as a minimum parameter from the estimated intermediate buffer size and a maximum threshold buffer parameter by the buffer estimation block (102).

4. The method, as claimed in claim 3, wherein the method further comprises setting send/receive window size limits using the determined buffer size.

5. The method, as claimed in claim 2, wherein the method of determining the congestion algorithm comprises
using a coupled congestion algorithm by the UE (101), if the UE (101) is using MPTCP for communication;
using an uncoupled congestion algorithm by the UE (101), if the UE (101) is using TCP for communication; and
using an uncoupled congestion algorithm by the UE (101), if the UE (101) is using MPTCP for communication and aggressive performance is required.

6. A User Equipment (UE) (101) configured for
determining a current operational state of the UE (101) and current conditions of at least one communication interface (105) present in the UE (101), wherein the current operation state comprises of MPTCP and TCP status; and
determining at least one tunable parameter by the UE (101) based on the current operation state of the UE (101) and current conditions of the at least one communication interface (105).

7. The UE, as claimed in claim 6, wherein the at least one tunable parameter comprises buffer size, initial congestion window size (initcwnd), initial receive window size (initrwnd), congestion control algorithm, TCP memory (tcp_mem), tcp_limit_output_bytes,tcp_no_metrics_save, tcp_low_latency, packet packing factor, interrupt binding, window scaling, timestamping, ack methodology, memory per socket, window size, cpuinfo_min_freq of a Central Processing Unit (CPU), cpuinfo_max_freq of the CPU, min/max operating frequency of the CPU, scaling_governor of the CPU, bios_limit of the CPU, scaling_min_freq of the CPU, and scaling_max_freq of the CPU.

8. The UE, as claimed in claim 7, wherein the UE (101) is configured for determining the buffer size by
determining an intermediate buffer size by summing all available buffer sizes for all active communication interfaces by an estimation block (102) in the UE (101), on a connectivity manager (104) detecting at least one pre-defined event; and
determining the buffer size as a minimum parameter from the estimated intermediate buffer size and a maximum threshold buffer parameter by the buffer estimation block (102).

9. The UE, as claimed in claim 8, wherein the UE (101) comprises a MPTCP tuner (103) configured for setting send/receive window size limits using the determined buffer size.

10. The UE, as claimed in claim 7, wherein the UE (101) is configured for determining the congestion algorithm by
using a coupled congestion algorithm, if the UE (101) is using MPTCP for communication;
using an uncoupled congestion algorithm, if the UE (101) is using TCP for communication; and
using an uncoupled congestion algorithm, if the UE (101) is using MPTCP for communication and aggressive performance is required.

Dated this 22nd of February, 2017
Signature:
Name of the Signatory: Dr. Kalyan Chakravarthy