\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={We TCP-AP: Wireless Enhanced TCP-AP},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2016-01-15 (revised: 15 January 2016)}
\def\TheID{\makeatother }
\def\TheDate{2016-01-15}
\title{We TCP-AP: Wireless Enhanced TCP-AP}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Luis  Barreto}

             \affil[1]{  Instituto Politecnico de Viana do Castelo}

\renewcommand\Authands{ and }

\date{\small \em Received: 11 December 2015 Accepted: 3 January 2016 Published: 15 January 2016}

\maketitle


\begin{abstract}
        


Congestion control in wireless networks is strongly dependent on the dynamics and instability of wireless links. It is known that TCP experiences serious performance degradation problems in wireless networks. New approaches based on TCP try to overcome these problems but, although their performance is increased, they incur in congestion control errors, since they do not evaluate accurately the capacity and available link bandwidth in wireless networks. This is also the case of TCP-AP (Adaptive Pacing) that, although presenting clear advantages in wireless networks when compared to other TCP-based approaches, its performance is still lower than rate-based approaches. In this paper we propose a new congestion control protocol based in TCP-AP, the Wireless Enhanced TCP-AP (WE TCPAP).This protocol relies on the MAC layer information gathere by a new method to accurately estimate the available bandwidth and the path capacity over a wireless network path. The new congestion control mechanism is evaluated in different scenarios in wireless mesh and ad-hoc networks, and compared against several approaches for wireless congestion control. It is shown that the new WE TCP-AP outperforms the base TCP-AP, with a more stable behavior and better channel utilization, and its performance gets close to the one of ratebased protocols. This is a very important result, as we show that TCP-based approaches are still able to have good performance in wireless mesh and ad-hoc networks.

\end{abstract}


\keywords{CP-AP congestion control available bandwidth path capacity node count fair share performance wireless networks. cp-ap congestion control available ban}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{I. Introduction}]{I. Introduction}\par
ireless networks have major factors that limit their performance, such as limited capacity and available bandwidth \hyperref[b3]{[5]}. This results in severe congestion collapses. The support of a congestion control scheme that provides an efficient and accurate sharing of the underlying network capacity among multiple competing applications is crucial to the efficiency and stability of wireless networks. Actively using link capacity and available bandwidth for congestion control will surely make these networks more efficient. Link capacity can vary due to a variety of factors, such as handoffs, channel allocation and, of course, channel quality. In \hyperref[b23]{[25]} we proposed a new mechanism for measuring wireless link capacity and available bandwidth, called rt-Winf. rt-Winf uses the information already present in the network and available at the MAC layer to accurately determine the link capacity and available bandwidth. Another important characteristic of rt-Winf is that it can be used by any existing wireless equipment through a cross-layer shared database.\par
To address the congestion control problems of wireless networks, new congestion control techniques have been proposed, through TCP-based (AIMD -Additive Increase Multiplicative Decrease) and Ratebased schemes. In \hyperref[b10]{[12]} we proposed new rate based congestion control protocols, based on eXplicit Congestion Protocol (XCP) \hyperref[b18]{[20]} and Rate Control Protocol (RCP) \hyperref[b14]{[16]}, with link capacity and available bandwidth estimation through rt-Winf. The performance of these protocols is increased when compared to available wireless-enabled congestion control approaches. Although these protocols can work together with TCP, they are not able to inter-operate in an end-to-end system. Therefore, it is very important to develop a TCP-based approach that is able to efficiently work in wireless based environments, and that can provide comparable performance to rate-based approaches.\par
The Transmission Control Protocol with Adaptive Pacing (TCP-AP) \hyperref[b15]{[17]} is a congestion control mechanism based on TCP \hyperref[b21]{[23]}, specifically designed for ad-hoc multi-hop wireless networks, being one of the wireless-enabled TCP protocols with better performance. TCP-AP uses a hybrid scheme between a pure rate-based transmission control and TCP's use of the congestion window. However, TCP-AP, as studied in \hyperref[b10]{[12]}, is very conservative and does not use very efficiently the medium. TCP-AP relies only on a 4-hop propagation delay technique to evaluate the link available bandwidth and capacity, not taking into consideration all the factors that influence link evaluation. New simulation results, presented in this paper, conducted in wireless ad-hoc scenarios, clearly show that TCP-AP lacks of efficiency and is not using correctly the medium; it is not evaluating correctly the parameters that are real constraints in such networks.\par
In this paper, an enhanced version of the work in \hyperref[b8]{[10]}, we propose a new approach to improve TCP-AP behavior, based on the integration of the on-line capacity and available bandwidth estimation technique, rt-Winf, with TCP-AP through a cross layer approach. Simulation results show that the rt-Winf integration is improving TCP-AP performance. However, it still reflects some of TCP-AP flaws, especially concerning fairness and the fact that it does not use the entire network information, as it relies on the knowledge of only 4 hop propagation delay. Thus, it is also important to improve its operations with the knowledge of all nodes along the path contending for available bandwidth and capacity, introducing the fairness factor and the network interaction behavior. Therefore, we propose a new approach to take this information into account. New simulation results show that the consideration of the node path effect and the integration of rt-Winf clear improve base TCP-AP performance. The simulation results were conducted on both ad-hoc and mesh wireless networks. These considerations represent a significant step towards congestion control in wireless networks, as they show that TCP-based schemes are able to efficiently work in these wireless adverse environments.\par
The remaining of this paper is organized as follows. Next section, section II, briefly presents the related work on congestion control mechanisms for wireless networks. Section III briefly describes the rt-Winf mechanism. Section IV presents a first evaluation of TCP-AP and addresses main TCP-AP problems. Then, section V describes how rt-Winf is integrated with TCPAP, and section VI presents a new approach for the node path contention count effect. Section VII depicts and discusses the results obtained through simulation, using mesh and adhoc scenarios with different characteristics. Finally, section VIII presents the conclusions and future work. 
\section[{II. Related Work}]{II. Related Work}\par
New efforts have been made to improve congestion control in wireless networks. The Wireless Control Protocol (WCP) \hyperref[b22]{[24]}, WCP with Capacity Estimation (WCPCap) \hyperref[b22]{[24]}, Cooperative Neighborhood Airtime-limiting (CNA) \hyperref[b17]{[19]}, HOP \hyperref[b19]{[21]}, EZ-Flow \hyperref[b7]{[9]} and Neighborhood Random Early Detection (NRED) \hyperref[b26]{[28]} are some examples.\par
TCP, as the most used congestion control protocol, has also been the underlying development for some congestion mechanisms in wireless environments, such as TCP-AP \hyperref[b15]{[17]}. More recent developments, based on rate based congestion protocols, like the eXplicit Control Protocol (XCP) \hyperref[b18]{[20]} and the Rate Control Protocol (RCP) \hyperref[b14]{[16]}, are XCP-b \hyperref[b2]{[4]}, XCP-Winf \hyperref[b9]{[11]} and RCP-Winf \hyperref[b9]{[11]}.\par
WCP is an AIMD-based rate-control protocol for multi-hop wireless networks. WCP was designed with the goal to be used on networks with arbitrary traffic pattern. During congestion, WCP signals all flows in a neighborhood of congestion and sets the control interval to the maximum Round Trip Time (RTT) of any flow in the neighborhood. WCP explicitly exchanges congestion information within a neighborhood, and all nodes within the neighborhood mark packets with congestion indicators, triggering rate reductions at the source. neighborhood, and divides this capacity to contending flows. With WCPCap it is evident that considering wireless congestion collectively over a neighborhood of a link is essential to any future design of wireless congestion control. WCPCap uses a sophisticated stochastic model for estimating the achievable rate region, given packet loss rates, topology, and flow information. It then allocates the achievable capacity fairly across flows, sending feedback to the sources.\par
CNA is a hybrid approach, in that it explicitly allocates the channel resources, but provides only imprecise feedback to the source. CNA achieves efficient airtime allocation by distributing available airtime within a wireless neighborhood, then monitoring the air utilization and dynamically redistributing unused airtime to improve overall airtime usage. The authors of CNA claim that it achieves transparency, low overhead, and responsiveness. CAN considers airtime to be the fraction of the time that a wireless link can occupy the shared channel; it does not consider, however, the time a node is waiting to transmit.\par
HOP is a clean-slate design of hop-by-hop congestion control. HOP tries to use reliable per-hop block transfer as a building block. HOP is referred by its authors as: fast, because it eliminates many sources of overhead as well as noisy end-to end rate control; robust to partitions and route changes, because of hopby-hop control as well as in-network caching; and simple, because it obviates complex end-to-end rate control as well as complex interactions between the transport and link layers.\par
EZ-Flow is a back-pressure congestion control mechanism which does not require explicit signaling. A back-pressure mechanism flow control allows loss-free transmission by having gateways verify that the next gateway has sufficient buffer space available before sending data, thus EZ-Flow is a cooperative congestion control. EZ-flow operates by adapting the minimum congestion window parameter at each relay node, based on an estimation of the buffer occupancy at its successor node in the mesh.\par
NRED identifies a subset of flows which share channel capacity with flows passing through a congested node. However, it identifies only a subset of contending flows: it misses flows that traverse 2-hop neighbors of a node without traversing its 1-hop neighbors. Moreover, the mechanism to regulate the traffic rates on these flows is quite a bit complex (it involves estimating a neighborhood queue size and using RED-style marking on packets in this queue). NRED has an important disadvantage, being intimately tied to a particular queue management technique (RED) and requires special hardware for channel monitoring.\par
TCP-AP uses a 4-hop propagation delay technique, and it considers a hybrid scheme between a  
\section[{E}]{E}\par
WCPCap is a distributed rate controller that estimates the available capacity within each pure rate-based transmission control and TCP's use of the congestion window to trigger new data packets to be sent into the network. A TCP sender adaptively sets its transmission rate using an estimate of the current 4hop propagation delay and the coefficient of variation of recently measured round-trip times. The 4-hop propagation delay describes the time elapsed between transmitting a TCP packet by the TCP source node, and receiving the packet at the node which lies 4 hops apart from the source node along the path to the destination.\par
XCP-b is a XCP based congestion control mechanism, as it tries to extend XCP for shared-access, multi-rate wireless networks by calculating, using very complex heuristics, the available bandwidth of the wireless channel. XCP-b uses indirect parameters such as queue sizes and the number of link layer retransmissions to obtain the desired measurements. XCP-b major drawback is that it becomes inefficient over highly dynamic wireless networks. In wireless environments with few nodes and less mobility, XCP-b can obtain good performance results in terms of stability, fairness, and convergence.\par
XCP-Winf and RCP-Winf are two new congestion control mechanisms that use MAC layer information through a cross layer communication process. The rt-Winf algorithm performs link capacity and available bandwidth calculations without interfering in the network dynamics, and without increasing network overhead; these parameters are then passed to the congestion control mechanisms based on explicit congestion notifications, XCP and RCP, to accurately determine the network status and act accordingly. The evaluation results of XCP-Winf and RCPWinf, obtained through ns2 \hyperref[b0]{[1]} simulations, show that the rt-Winf algorithm improves significantly XCP and RCP behavior making them more efficient and stable. In \hyperref[b10]{[12]} it was shown that these rate-based approaches have better performance in wireless scenarios when compared to TCP-based approaches. In this paper we will work on the enhancement of TCP-based approaches to target a Table \hyperref[tab_1]{I} qualitatively compares the previous referred mechanisms along some dimensions. We will then work with TCPAP protocol, being the one TCPbased, and providing good performance when compared to other similar approaches. 
\section[{III. Rt-Winf Description}]{III. Rt-Winf Description}\par
The rt-Winf mechanism has been inspired by IdleGap \hyperref[b5]{[7]}, but with the purpose to mitigate IdleGap main issues and problems, and also with the intention to be compatible with all systems and being able to determine both the link capacity and available bandwidth without overloading the network. rt-Winf does not introduce any change to the OSI Model, as opposed to IdleGap, being able to obtain all the necessary times to obtain the path capacity and the available bandwidth. Another important aspect of rt-Winf, relatively to IdleGap \hyperref[b5]{[7]}, is that it does not use the DataRate value of the IEEE802.11 header \hyperref[b1]{[3]} as the link capacity estimation.\par
This mechanism can be used with the Carrier Sense Multiple Access -Collision Avoidance (CSMA-CA) \hyperref[b11]{[13]} Request To Send (RTS)/ Clear To Send (CTS) handshake enabled in the wireless communication or with probe packets when RTS/CTS packets are not present. The usage of RTS/CTS handshake is optional, but it is nowadays widely supported by all wireless equipments. Its usage, in a traditional wireless network, represents a negligible cost in terms of overhead \hyperref[b6]{[8]}. a) RTS/CTS Packets rt-Winf with RTS/CTS control packets enabled relies on this handshake to correctly retrieve the NAV values.\par
In order to evaluate the accuracy of the duration field on the IEEE802.11 header, we performed a large number of captures ( 200). We concluded that the duration value on data packets is not reliable, because different sized packets have always the With the obtained captures, it was possible to realize how each state managed the received packets. In the case of the Sender state, the node was able to capture the CTS, DATA and ACK packets. A node in the Receiver state was able to capture the RTS and the DATA packets, while a node in the Onlooker state was able to capture the complete set of packets: RTS, CTS, DATA and ACK. This different knowledge implied the conception of different algorithms for each state. Then, we proposed that each node state uses a different method to determine the Idle Rate. In the case of the Sender, it is considered the NAV of the CTS packets on the available bandwidth calculation. For the capacity calculation, it is considered the time that the channel is busy, that is, the difference between ACK time, CTS time and the duration of the occurred Short Inter-Frame Spacing -SIFS (where ACK time is the actual clock time when the ACK packet is Received, and CTS time is the clock time when CTS packet is received). The Receiver uses the NAV of the RTS packets to obtain the Idle Rate and the difference between the DATA time, RTS time and 3 times SIFS to obtain the capacity (where DATA and RTS times are, respectively, the clock time when DATA packet is received and RTS packet is received). The On looker uses the NAV value according to the existence, or not, of the RTS packet to obtain both the available bandwidth and capacity. If a node in the Onlooker state captures a CTS packet of a communication without capturing the RTS packet, this implies that the communication is suffering from the hidden nodes problem. Thus, the algorithm will only use the NAV from the CTS packet to retrieve the correct values. The total elapsed time represents the difference between the last captured ACK time and the initial time. The packet size considered is the DATA packet size. Figure  {\ref 1} shows the different approaches for each state while Figure  {\ref 2} represents the state diagram of the rt-Winf tool. It is possible to observe each state's transitions. When a CTS packet is captured by the Sender, it starts to evaluate the available bandwidth and capacity, while the Receiver starts this process when a RTS packet is received. The Receiver sends the calculated available bandwidth and capacity in an ACK packet to the Sender. When the Sender receives the ACK packet with that information, from the Receiver, compares it with the available bandwidth and capacity that it has previously calculated. If the information received through the ACK packet is lower than the obtained, the sender will use the available bandwidth and capacity received in the ACK packet. Otherwise, the sender will transmit using the available bandwidth and capacity calculated before. This cooperation is a great improvement when compared to IdleGap. 
\section[{b) Probe Packets}]{b) Probe Packets}\par
If RTS/CTS packets are not present, rt-Winf can use probe packets in order to retrieve the transfer time values. Probe packets can be sent between nodes. These must be UDP generated packets with altered Frame Control IEEE 802.11 header: Type Data and Subtype Reserved. We used packets with Frame Control Type set to 10 (data) and Subtype to 1001 (Reserved). This way the Sender and the Receiver can successfully differentiate these packets from the ordinary data packets. IEEE802.11 standard defines that, for each successfully received packet, it must be sent a MAC ACK packet \hyperref[b1]{[3]}. The whole process is very similar to the one with the RTS/CTS handshake.\par
The generated packets are used to retrieve the capacity and available bandwidth values, according to Equation 1 and Equation 2. These packets are only sent before a node wants to start a transmission and in the absence of traffic. This allows the system to initially determine the available bandwidth and capacity. Then, the existing traffic and the MAC layer ACK will be used to trigger the calculations. As NAV values are not correctly defined in DATA packets, rt-Winf uses clock time information to determine the busy time. So, NAV values are not considered in this specific implementation with probe packets. To be fully operational, both Sender and Receiver must be running the rt-Winf mechanism. \hyperref[b0]{(1)} where TransferTime is equal to ACKTime?DataTime.\par
In a normal VoIP call using G.711 codec [2], the overhead introduced by this mechanism is \textunderscore  1:66\%. For a flow with more than 1Mbps, the overhead is less than \textunderscore  0:15\%.\par
IV.\par
As TCP-AP tries to retain the end-to-end semantics of TCP, without any modifications on the link and routing layers or the need of cross layer information, as opposed to other proposals such as XCP-Winf or XCP-b, it is important to understand how it reacts under high density and high dynamic environments. TCPAP was developed with the main purpose to improve congestion control in ad-hoc wireless networks.\par
TCP-AP is a hybrid scheme that introduces the concept of a 4-hop propagation delay, which is the estimated elapsed time between the transmission of a packet by the source and its reception by a node that is 4-hops away. This estimation uses the Round Trip Time (2)\par
We TCP-AP: Wireless Enhanced TCP-AP TCP-AP EvaluationC = PacketSize Trans f erTime AB = 1 ? ? Trans f erTime TotalElapsedTime * C\par
control beyond the 4 hops. This is why TCP-AP is considered as a hybrid approach, since it is rate based as well as congestion window based.\par
In this section, we compare the TCP-AP approach, using ns-2 \hyperref[b0]{[1]} simulations, against XCP-b, XCP-Winf and WCP. As WCP is also an AIMD and rate based approach, it is a good baseline for comparison purposes. The network scenario used is an adhoc network with nodes varying from 8 to 256 nodes \hyperref[b6]{(8,}\hyperref[b14]{16,} {\ref 32,} {\ref 64,} {\ref 128,} {\ref 256)}. Nodes are distributed randomly throughout the simulation area.\par
Flows also vary according to the number of nodes: with 8 nodes we have 4 flows, with 16 nodes we have 8 flows, and so on. The routing protocol used is the Destination-Sequence Distance-Vector (DSDV) \hyperref[b20]{[22]}. The configured default transmission range is 250 meters, the default interference range is 500 meters, and the channel data rate is 11 Mbps. The performance metrics used are: the throughput, the delay of the transmitted packets, and the number of received packets. Each flow presents a FTP application simulating a large file download. The mobility is emulated through the ns-2 setdest tool to provide a random node movement pattern. We configure setdest with a minimum speed of 10 m/s, a maximum speed of 30 m/s and a topology boundary of 1000x1000 meters. All results were obtained from ns-2 trace files, with the help of trace2stats \hyperref[b16]{[18]} scripts adapted to our own needs. All simulations last 300 seconds and the simulations are repeated 30 times with different ns-2 seed values. The mean and 95\% confidence intervals are presented in the results. From Figure \hyperref[fig_2]{3}, Figure \hyperref[fig_3]{4} and Figure \hyperref[fig_4]{5} we can observe that TCP-AP is the one with the worst results, with a poor performance when compared to the other approaches. From the Figures it is possible to observe that TCP-AP presents lower performance results in terms of delay, throughput and received packets. This is due to the fact that TCP-AP is not obtaining correctly the network's maximum capacity, thus not avoiding congestion and not using efficiently the medium. TCPAP is over-estimating the available rate producing congestion,   As TCPAP rate estimation technique is not using a reliable technique to evaluate the medium, the sender is generating more traffic than the medium supports, resulting in more packets queued, less packets in transit, hence its throughput is decreased, the delay is increased, and the number of received packets is also decreased. Another characteristic of TCP-AP is that it uses the standard AIMD process. This process is not suitable for wireless networks as it overloads the wireless channel. This behavior in conjunction with the estimation technique of TCP-AP results in inaccurate available bandwidth estimations and higher delays.\par
We can then conclude that TCP-AP is not evaluating correctly and not using efficiently the available bandwidth along the path, obtaining poor throughput and behaving very conservatively, resulting in a low number of received packets and high delay. TCP-AP is also not considering a fair share of the bandwidth to all flows, not using correctly the medium and having a significant degradation of performance.\par
From Figure \hyperref[fig_2]{3} it is possible to conclude that XCP-Winf is using accurately the available bandwidth and link capacity information from the MAC layer, improving significantly network performance: it uses more efficiently the medium, resulting in better delay values. XCP-Winf, being a rate-based protocol, where bandwidth and capacity estimation is based on the MAC layer information, and providing node cooperation, it can effectively and quickly adapt to the links conditions, thus, improving network performance and making the network behave more fairly.\par
From the presented results, it is also possible to observe that WCP has better overall results than TCP-AP. WCP has a rate control mechanism that reacts explicitly to congestion, and a cooperative communication process between neighbor nodes that make WCP to react more efficiently to the network conditions, allowing to have a better medium usage.\par
XCP-b results are better than the ones obtained by TCPAP. However, its results are worse than the ones obtained by XCP-Winf and WCP. XCP-b, although a rate-based congestion control scheme, it uses complex heuristics based on measuring indirect quantities like queue sizes and the number of link layer retransmissions, to estimate the available capacity. Those direct measures are overestimating the available capacity and bandwidth, specially when the network is heavily utilized, resulting in performance degradation and instable behavior. This is shown by the good XCP-b results when the number of flows is relatively small.\par
Although TCP-AP scheme is a hybrid scheme of sender rate control and congestion control, TCP-AP is based on two assumptions: the rate control mechanism is efficient and the contention and spatial reuse is accurate. These assumptions may not be effective in some network topologies. This assumption is clearly not effective in high mobility wireless scenarios. The conservativeness of TCP-AP is observed in its throughput (Figure \hyperref[fig_2]{3}) results and received packets (Figure \hyperref[fig_4]{5}). While having good throughput results, they are obtained with less received packets. This is a consequence of using the hybrid scheme for congestion control.\par
TCP-AP is not using information from the MAC layer: it relies on the transmission of packets at the transport layer. This principle is failing effectively to transmit packets at the MAC layer, making it reacting with poor performance in terms of received packets. As TCP-AP is not relying in an effective available bandwidth and link capacity estimation mechanisms at the MAC layer, the sender assumes that the bandwidth of all links in the path is the same and the medium usage is clearly not efficient. Due to its 4 hop propagation delay assumption, TCP-AP available bandwidth and link capacity estimation is not considering the nodes along the route path, which are the nodes that contend from the available bandwidth along the path. This is specially relevant when we are dealing with a high density and high mobility network, introducing inaccuracy and lack of fairness on the TCP-AP performance. 
\section[{V. Tcp-ap with Rt-Winf}]{V. Tcp-ap with Rt-Winf}\par
The base TCP-AP considers network and transport layer information (RTT values) for its capacity and available bandwidth estimations. This technique is not very accurate introducing inefficiency to the congestion control process. This was already shown in wired networks, in works \hyperref[b13]{[15]} and \hyperref[b4]{[6]}, which introduced packet dispersion to analyze the capacity and available bandwidth estimations. This problem is even increased when dealing with wireless networks, since their variation and instability increase.\par
We claim that it is important to have a crosslayer approach for bandwidth and link capacity estimation: using information provided by several layers, including the MAC layer, it is expected that the congestion control mechanism is more reliable and effective. Therefore, we propose TCP-AP with rt-Winf, which relies on the main functioning principles of TCP-AP, but uses information provided by rt-Winf \hyperref[b23]{[25]} to determine the link capacity and available bandwidth.\par
As rt-Winf obtains the link capacity and available bandwidth in the MAC layer, this information has to be accessed by TCPAP through a cross-layer communication process. One example of such crosslayer communication process is the MobileMan \hyperref[b12]{[14]} cross-layered network stack. This communication system uses a shared database architecture, with a set of methods to get/insert information from/in the database accessible by all protocol layers.\par
Our approach, when compared to the base TCP-AP, changes the way each node calculates the 4hop delay (FHD) and the average packet queuing delay per node (t q ), with the rt-Winf link capacity and available bandwidth values. Thus, \hyperref[b1]{(3)} where T RTT represents the RTT value, h represents the number of hops between the sender and receiver, Sdata is the size of the data packet and Sack is the size of the ACK packet. Finally, CWin f corresponds to the rt-Winf link capacity. The previous equation allows to update the 4-hop delay (FHD) by: \hyperref[b2]{(4)} where AB Winf is the rt-Winf available bandwidth.\par
Considering that a high density and high mobility network suffers from a large number of collisions, rt-Winf mechanism was updated with the effect of collision probability. Notice that rt-Winf works on the IEEE 802.11 \hyperref[b1]{[3]} MAC layer that uses the Distribution Coordination Function (DCF) as the access method. This function is based on the CSMA-CA principle, in which a host wishing to transmit senses the channel, waits for a period of time, and then transmits if the medium is still free. If the packet is correctly received, the receiving host sends an ACK frame after another fixed period of time. If the ACK frame is not received by the sending host, a collision is assumed to have occurred. Therefore, to improve efficiency and reliability of TCPAP with rt-Winf, collision probability is accounted for. When a sender cannot transmit due to collision, the back off mechanism is activated. This mechanism is also consuming bandwidth that is not really used by the channel. This unused channel contention bandwidth can be allocated as an extra bandwidth. This extra bandwidth, C extra , is defined by: 
\section[{Global Journal of Computer Science and Technology}]{Global Journal of Computer Science and Technology}\par
Volume XVI Issue VI Version I 7 Year 2016 ( )E\par
We TCP-AP: Wireless Enhanced TCP-APt q = 1 2 ( T RT T h ? S data ? S ack C Win f ) FHD = 4 × (t q + S data AB Win f ) (5)\par
where T DIFS is the IEEE 802.11 DCF Inter frame Space, T backo f f is the medium backoff time, T m is the time between the transmission of two packets and W is the channel bit rate. The collision probability (P c ) can then be defined as 1-C extra . Applying this result to the rt-winf inference mechanism, the available bandwidth (AB) becomes:\par
(6) 
\section[{VI.}]{VI.}\par
In a wireless network, nodes along a multi-hop path (NP) contend among themselves for access to the medium, i.e, they contend for available bandwidth. To obtain the contention of nodes along the path, it is important to know the contention count of each node. The contention count at a node is the number of nodes on the multi-hop path that are located within carrier sensing range of the given node, and can be obtained as described in \hyperref[b24]{[26]}. Considering that TCP-AP only implements adaptive pacing at the sender side, available bandwidth and capacity estimation must take into consideration nodes along the path between the source and the sink, that is, the bandwidth contending successors and predecessors on the route path. However, this is not true in TCP-AP, since it is considering only 4-hop neighborhood for these contending estimations. Therefore, to eliminate this inaccuracy, we changed TCP-AP with rt-Winf to use a coefficient (R is the unused bandwidth) that represents the proportion of bandwidth contention among other nodes on the path, thus, maximizing the throughput while guaranteeing fairness. If we consider NP as all nodes along the path and if NP?1 is equal or less than 4, then TCP-AP with rt-Winf is kept unchanged; if NP?1 is higher than 4, then the FHD equation, now called the hop delay (HD) is updated to: Where then,\par
Algorithm 1 shows the pseudo-code of an WE TCP-AP source node.\par
As R represents the unused bandwidth due to node contention and queue management along the path, it introduces the fairness factor allowing an improved fair share of the available bandwidth among all contending nodes, not only the ones within the 4-hop propagation delay, improving WE TCP-AP behavior and making it behave more accurately. 
\section[{VII. Simulation Results}]{VII. Simulation Results}\par
This section presents simulation results of our proposed congestion control mechanism. The results are obtained using the ns-2 simulator \hyperref[b0]{[1]}. The underlying rt-Winf mechanism is configured with enabled RTS/CTS/ACK handshake packets. The proposed mechanism is evaluated against the base TCP-AP protocol, WCP and XCP-Winf. Two different scenarios were used: the same ad-hoc scenario presented in section V, and a wireless mesh topology scenario that is presented to understand how the new proposals behave under different conditions. This scenario is \par
AP. Again, all simulations last 300 seconds and the simulations are repeated 30 times with different ns-2 seed values. The mean and 95\% confidence intervals are presented in the results.\par
We TCP-AP: Wireless Enhanced TCP-AP Wireless Enhanced TCP-AP -we TCP-APAB = P c × AB Win f ? AB = ( 1 ?C extra W ) × AB Win f HD = FHD × R R = 1 + 1 NP W HD = 4 × ( NP + 1 NP ×W ) × (t q + S data AB Win f )\par
a) TCP-AP with rt-Winf Figure \hyperref[fig_6]{6}, Figure \hyperref[fig_8]{7} and Figure \hyperref[fig_7]{8} show the performance metrics for the mesh topology scenario. From the observation of the results, it is possible to conclude that TCP-AP with rt-Winf integrated clearly improves TCP-AP performance behavior, but its performance is still below the one of XCP-Winf. TCP-AP with rt-Winf is only taking into consideration rt-Winf information for the last 4 hop nodes; TCP-AP, as opposed to XCP-Winf, uses the standard behavior of TCP for the other hops of the network, considering that all links have the same bandwidth.\par
Another important drawback of TCP-AP with rt-Winf is the fact that it does not have a fairness module, resulting in a more conservative and less fair operation. The fairness module is a native mechanism used by XCP-Winf. As TCP-AP with rt-Winf uses, in most of its functioning, the standard AIMD process of TCP and is not entirely using the available information between the source and the sink, its results are not similar to the ones of XCP-Winf. XCP-Winf also relies on the overall node path interaction, using a cooperative approach to obtain the best available bandwidth and link capacity usage. In TCP-AP with rt-Winf, as the number of nodes or flows increases, it uses conservative mechanisms, reducing its performance especially concerning received packets.\par
WCP obtains better results than TCP-AP with rt-Winf. WCP uses explicit congestion information between nodes that trigger rate changes, making it behave with good efficiency and fairly. As XCP-Winf uses the rt-Winf mechanism as its base estimation tool, it has a precise feedback communication mechanism between all the nodes along the path using total network cooperation, and it is able to better use the channel with less losses, resulting in a more efficient and accurate behavior.\par
Figure  {\ref 9}, Figure  {\ref 10} and Figure \hyperref[fig_10]{11} show the results for the ad-hoc topology scenario. In this scenario, we can see that rt-Winf clearly improves TCP-AP performance, compared to TCPAP and WCP. However, TCP-AP with rt-Winf still reflects some With the increase of the number of flows, TCP-AP with rt-winf becomes less efficient, as it is only relying on the 4-hop propagation delay and the AIMD process, not considering the entire network topology for its rate changes. This is shown by being able to obtain good throughput results, compared to XCP-Winf, when the network is not heavily loaded. When increasing the number of nodes, number of flows and the mobility density, TCP-AP with rt-Winf becomes more inefficient, reducing significantly its throughput and the number of received packets when compared to the other approaches. TCP-AP with rt-Winf is also more fair than TCP-AP to mobility changes, but it still shows an unstable behavior. WCP has overall good results: although being an hybrid approach, it uses a more effective congestion and control interval, as all nodes within the congestion neighborhood mark packets with congestion indicators, triggering rate reductions more efficiently at the source. 
\section[{b) WE TCP-AP}]{b) WE TCP-AP}\par
This section presents the simulation results of WE TCP-AP in both mesh and ad-hoc scenarios.\par
Figure  {\ref 12}, Figure \hyperref[fig_2]{13} and Figure \hyperref[fig_12]{14} show the performance metrics. In terms of received packets, as observed in Figure \hyperref[fig_12]{14}, it is possible to see that WE TCP-AP is able to use more efficiently  TCP-AP has a very conservative behavior, as it allows a good throughput with less received packets. This behavior is clearly improved with WE TCP-AP. The delay values, in Figure \hyperref[fig_2]{13}, are also reduced reinforcing the fact that this new proposal is much more efficient and fair, with better medium usage, than the base protocol. The better results are still obtained by XCP-Winf, but it is closely followed by WE TCP-AP: it is clear that the use of MAC layer information and the node path contention count is making WE TCP-AP to react more efficiently to the network dynamics.\par
Figure \hyperref[fig_13]{15}, Figure \hyperref[fig_14]{16} and Figure \hyperref[fig_8]{17} show WE TCP-AP results in the ad-hoc network scenarios, as defined before. the medium, as it can transmit more packets increasing overall throughput results. More received packets means that more transmissions are allowed, thus WE TCP-AP is behaving more fairly. With these improvements, the network can transmit with a higher rate and incurring less losses. As more packets are transmitted, more throughput is obtained and the medium is better and more efficiently used. This allows node path contention clearly improves base TCP-AP performance behavior. It is possible to conclude that, with more nodes and flows in the network, WE TCP-AP is more efficient than the standard TCP-AP proposal. XCP-Winf uses an explicit congestion control notification mechanism for an accurate rate change and relies in the link capacity at the MAC layer information; in this scenario, it is also able to operate more efficiently than WE TCP-AP, specially concerning the number of received packets. WE TCP-AP is not a pure rate-based congestion control mechanism with explicit feedback, thus it is not reacting quickly to network changes. The AIMD process of WE TCP-AP still introduces some instability and behavior problems.\par
WE TCP-AP, as opposed to TCP-AP, is considering a fair share of the unused bandwidth, that results from the use of the node path contention count, making it behave more efficiently and  For a better understanding of how the factor R is influencing WE TCP-AP behavior, a central network chain scenario was defined. It must be noted that the standard TCP-AP 4-hop propagation delay assumes that "every fourth node can transmit in a multi-hop chain topology". On this scenario, it was used the proposed version of WE TCP-AP and the TCP-AP with rt-Winf version. The chain scenario consists of a network divided in three parts. Figure \hyperref[fig_16]{18} depicts the network topology with four chains of nodes. The application used simulates a FTP transfer. The results are shown in Figure \hyperref[fig_15]{19}, Figure  {\ref 20} and Figure  {\ref 21}. The presented results clearly show that, with the increase of the chain nodes, TCP-AP with rt-Winf has worse results: it becomes less efficient an less accurate, as it is not considering the unused share of bandwidth. WE TCP-AP, on the other hand, is more accurate, since the available bandwidth and capacity   As TCP is the most used and deployed congestion control protocol on the Internet, it is important, as described on \hyperref[b25]{[27]}, to analyze how WE TCP-AP flows interact and compete with TCP. To analyze how friendly WE TCP-AP is, we use the average data rate over time for each flow, thus allowing to observe how bandwidth is being managed between TCP and the WE TCPAP proposal. This is called the utility of a congestion control mechanism against TCP.\par
The evaluation scenarios consist of a 1000mx1000m area, divided in three distinct parts. In the left side area, with 250mx250m, we have two mobile source nodes: one source node is configured to use only the standard TCP, and the other source  We have defined two evaluation scenarios. One scenario contains each source generating 8 FTP flows, with packets of 1500 bytes. In the other scenario we have each source generating sixteen FTP flows. The simulations last 120 seconds. The obtained results are shown in Figure \hyperref[fig_17]{22} and Figure \hyperref[fig_18]{23}.\par
From the utility results, it is possible to observe that, on both situations, the TCP flow grows faster and gains more bandwidth on the beginning. However, as WE TCP-AP is a hybrid approach, keeping unchanged the AIMD process of TCP and being updated with an evaluation and measurement process, it quickly adjusts to TCP behavior, thus, allowing a fair share of network resources. 
\section[{VIII.}]{VIII.}\par
This paper proposed a new approach to congestion control, based on TCP-AP and a new wireless inference mechanism, rt-Winf. rt-Winf measures the wireless capacity and the available bandwidth of wireless links, and feeds this information to TCPAP, through a cross-layer communication process. Two different improvements were also considered on the new approach: the awareness of collision probability on the available bandwidth approach, and the node path contention count on the 4-hop propagation delay approach.\par
The performance evaluation study of the proposed congestion control mechanism shows that the integration of rt-Winf and the proposed enhancements allow to make TCP-AP behavior more efficient, resulting in better overall network performance. Using rt-Winf, that works in the MAC layer, it is possible to perform link capacity and available bandwidth calculations without interfering in the network dynamics, allowing to significantly improve TCPAP performance. The node path contention also significantly improves TCP-AP performance, with more noticeable results for larger chains of nodes. This congestion control mechanism is denoted as WE TCP-AP.\par
As future work, we plan to work on the wider evaluation of the congestion control approach, using for example, new comparison baselines and protocols. An effort will also be made in creating a future test bed for understanding how the proposed mechanism is affected by different conditions and parameters, in a real environment. Year 2016 ( )\begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-3.png}
\caption{\label{fig_1}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3}\includegraphics[]{image-4.png}
\caption{\label{fig_2}Figure 3 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4}\includegraphics[]{image-5.png}
\caption{\label{fig_3}Figure 4 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{5}\includegraphics[]{image-6.png}
\caption{\label{fig_4}Figure 5 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{6}\includegraphics[]{image-7.png}
\caption{\label{fig_6}Figure 6 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{8}\includegraphics[]{image-8.png}
\caption{\label{fig_7}Figure 8 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{7}\includegraphics[]{image-9.png}
\caption{\label{fig_8}Figure 7 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{910}\includegraphics[]{image-10.png}
\caption{\label{fig_9}Figure 9 :Figure 10 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{11}\includegraphics[]{image-11.png}
\caption{\label{fig_10}Figure 11 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-12.png}
\caption{\label{fig_11}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{14}\includegraphics[]{image-13.png}
\caption{\label{fig_12}Figure 14 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{15}\includegraphics[]{image-14.png}
\caption{\label{fig_13}Figure 15 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{16}\includegraphics[]{image-15.png}
\caption{\label{fig_14}Figure 16 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{19}\includegraphics[]{image-16.png}
\caption{\label{fig_15}Figure 19 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{18}\includegraphics[]{image-17.png}
\caption{\label{fig_16}Figure 18 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{22}\includegraphics[]{image-18.png}
\caption{\label{fig_17}Figure 22 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{23}\includegraphics[]{image-19.png}
\caption{\label{fig_18}Figure 23 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{I} \par 
\begin{longtable}{P{0.34531249999999997\textwidth}P{0.010625\textwidth}P{0.12218749999999999\textwidth}P{0.0053125\textwidth}P{0.035416666666666666\textwidth}P{0.035416666666666666\textwidth}P{0.16645833333333332\textwidth}P{0.0425\textwidth}P{0.08677083333333332\textwidth}}
\tabcellsep \tabcellsep \multicolumn{4}{l}{We TCP-AP: Wireless Enhanced TCP-AP}\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep Year 2016\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep 3\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep Volume XVI Issue VI Version I\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep )\\
\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep (\\
\multicolumn{4}{l}{similar performance than rate-based in end-to-end TCP compatible approaches. Cross-Layer Control Param. TCP based NRED Yes Buffer XCP-Winf RCP-Winf Yes Rate WCP Rate}\tabcellsep AIMD based Yes\tabcellsep Rate based Yes\tabcellsep ? Inter. Node Feed-back Yes Yes Yes\tabcellsep MAC Multi Rate Yes\tabcellsep Global Journal of Computer Science and Technology\\
WCPCap\tabcellsep \tabcellsep Rate\tabcellsep \tabcellsep Yes\tabcellsep Yes\tabcellsep Yes\\
CNA\tabcellsep \tabcellsep Window\tabcellsep \tabcellsep \tabcellsep \tabcellsep Yes\tabcellsep Yes\\
EZ-Flow\tabcellsep Yes\tabcellsep Buffer\tabcellsep \tabcellsep \tabcellsep \tabcellsep Yes\\
HOP\tabcellsep \tabcellsep Window\tabcellsep \tabcellsep \tabcellsep \tabcellsep Yes\tabcellsep Yes\\
TCP-AP\tabcellsep \tabcellsep Window\tabcellsep Yes\tabcellsep Yes\tabcellsep Yes\tabcellsep Yes\\
XCP-b\tabcellsep Yes\tabcellsep Buffer\tabcellsep \tabcellsep \tabcellsep \tabcellsep Yes\end{longtable} \par
  {\small\itshape [Note: same duration. The RTS/CTS packets have accurate duration values, which can be used in the calculations.]} 
\caption{\label{tab_1}Table I :}\end{figure}
 			\footnote{© 2016 Global Journals Inc. (US)} 			\footnote{\& \& \& \&'(\& ) *)) ' +} 			\footnote{© 2016 Global Journals Inc. (US) 1} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Fiore ()]{b16}\label{b16} 	 		\textit{},  		 			M Fiore 		.  		 \url{http://www.tlc-networks.polito.it/fiore/index.html}  		2009. p. e2.  	 
\bibitem[11 -IEEE standard for information technology -telecommunications and information exchange between systems -local and metropolitan area networks specific requirements. part 11: Wireless LAN medium access control (MAC) and physical layer (PHY) specifications IEEE std ()]{b1}\label{b1} 	 		‘11 -IEEE standard for information technology -telecommunications and information exchange between systems -local and metropolitan area networks specific requirements. part 11: Wireless LAN medium access control (MAC) and physical layer (PHY) specifications’.  		 \url{http://standards.ieee.org/getieee802/download/802.11-2007.pdf}  	 	 		\textit{IEEE std}  		2007. 802.  	 
\bibitem[Abrantes and Ricardo ()]{b2}\label{b2} 	 		‘A simulation study of XCP-b performance in wireless multi-hop networks’.  		 			F Abrantes 		,  		 			M Ricardo 		.  	 	 		\textit{Proceedings of the 3rd ACM workshop on QoS and security for wireless and mobile networks, Q2S Winet '07},  				 (the 3rd ACM workshop on QoS and security for wireless and mobile networks, Q2S Winet '07)  		2007. ACM.  	 
\bibitem[Brenner ()]{b11}\label{b11} 	 		\textit{A technical tutorial on the IEEE 802},  		 			P Brenner 		.  		 \url{http://sss-mag.com/pdf/802n11tut.pdf}  		1997.  	 
\bibitem[Bandwidth estimation in wireless LANs for multimedia streaming services Advances in Multimedia ()]{b5}\label{b5} 	 		‘Bandwidth estimation in wireless LANs for multimedia streaming services’.  	 	 		\textit{Advances in Multimedia}  		2007. 2007.  (1)  p. .  	 
\bibitem[Barreto ()]{b8}\label{b8} 	 		 			L Barreto 		.  		 \xref{http://dx.doi.org/10.5296/npa.v7i2.7677}{10.5296/npa.v7i2.7677}.  		\textit{TCP-AP enhanced behaviour with rt-Winf and node count: boosted-TCP-AP. Network Protocols and Algorithms},  				2015. 7.  	 
\bibitem[Li et al. ()]{b19}\label{b19} 	 		‘Blockswitched networks: A new paradigm for wireless transport’.  		 			M Li 		,  		 			D Agrawal 		,  		 			D Ganesan 		,  		 			A Venkataramani 		.  	 	 		\textit{6th ACM/USENIX Symposium on Networked Systems Design and Implementation},  				2009. 2009.  	 
\bibitem[Katabi et al. ()]{b18}\label{b18} 	 		\textit{Congestion control for high bandwidth-delay product networks},  		 			D Katabi 		,  		 			M Handley 		,  		 			C Rohrs 		.  		2002. ACM SIGCOMM.  	 
\bibitem[Conti et al. ()]{b12}\label{b12} 	 		‘Crosslayering in mobile ad hoc network design’.  		 			M Conti 		,  		 			G Maselli 		,  		 			G Turi 		,  		 			S Giordano 		.  		 \xref{http://dx.doi.org/10.1109/MC.2004.1266295}{10.1109/MC.2004.1266295}.  		 \url{DOIhttp://doi.Ieeecomputersociety.org/10.1109/MC.2004.1266295}  	 	 		\textit{Computer}  		2004. 37 p. .  	 
\bibitem[Sanzgiri et al. ()]{b24}\label{b24} 	 		‘Determining intraflow contention along multihop paths in wireless networks’.  		 			K Sanzgiri 		,  		 			I Chakeres 		,  		 			E Belding-Royer 		.  	 	 		\textit{Proceedings. First International Conference on},  				 (First International Conference on)  		2004. 2004. 2004. p. .  	 	 (Broadband Networks) 
\bibitem[Xu et al. ()]{b26}\label{b26} 	 		‘Enhancing TCP fairness in ad hoc wireless networks using neighbor hood red’.  		 			K Xu 		,  		 			M Gerla 		,  		 			L Qi 		,  		 			Y Shu 		.  	 	 		\textit{Proc. ACM MobiCom},  				 (ACM MobiCom)  		2003. ACM Press. p. .  	 
\bibitem[Aziz et al. ()]{b7}\label{b7} 	 		‘Ez-Flow: Removing turbulence in IEEE 802.11 wireless mesh networks without message passing’.  		 			A Aziz 		,  		 			D Starobinski 		,  		 			P Thiran 		,  		 			A E Fawal 		.  	 	 		\textit{5th International Conference on emerging Networking EXperiments and Technologies},  				2009.  	 
\bibitem[Perkins and Bhagwat ()]{b20}\label{b20} 	 		\textit{Highly dynamic destination-sequenced distance-vector routing (DSDV) for mobile computers},  		 			C E Perkins 		,  		 			P Bhagwat 		.  		1994. ACM SIGCOMM.  	 
\bibitem[Incentive compatible medium access control in wireless networks ()]{b6}\label{b6} 	 		\textit{Incentive compatible medium access control in wireless networks},  		2006. ACM GAMENETS.  	 
\bibitem[Dovrolis et al. ()]{b13}\label{b13} 	 		‘Packetdispersion techniques and a capacity-estimation methodology’.  		 			C Dovrolis 		,  		 			P Ramanathan 		,  		 			D Moore 		.  	 	 		\textit{IEEE/ACMTrans. Netw}  		2004. 12 p. .  	 
\bibitem[Res et al.]{b23}\label{b23} 	 		‘rt-winf: Real time wireless inference mechanism’.  		 			B Res 		,  		 			L Barreto 		,  		 			S Sargento 		.  	 	 		\textit{IEEE Globecom 2010 Workshop on Mobile Computing and Emerging Communication Networks (MCECN2010)},  				 	 
\bibitem[Young Jang et al. ()]{b17}\label{b17} 	 		‘Simple yet efficient,transparent airtime allocation for tcp in wireless mesh networks’.  		 			K Young Jang 		,  		 			K Psounis 		,  		 			R Govindan 		.  		 \url{URLhttp://www-bcf.usc.edu/\$nsim\$kpsounis/Papers/cna.pdf}  	 	 		\textit{6th International Conference on emerging Networking Experiments and Technologies (CoNEXT)},  				2010.  	 
\bibitem[Elrakabawy et al. ()]{b15}\label{b15} 	 		‘TCP with pacing for multihop wireless networks’.  		 			S M Elrakabawy 		,  		 			A Klemm 		,  		 			C Lindemann 		.  	 	 		\textit{Proceedings of the 6th ACM international symposium on Mobile ad hoc networking and computing MobiHoc '05},  				 (the 6th ACM international symposium on Mobile ad hoc networking and computing MobiHoc '05)  		2005. ACM. p. .  	 
\bibitem[Xu ()]{b25}\label{b25} 	 		\textit{TCP-friendly CBR-like Rate Control. Network Protocols},  		 			J F L Xu 		.  		 \xref{http://dx.doi.org/10.1109/ICNP.2008.4697036}{10.1109/ICNP.2008.4697036}.  		2008. 2008. 2008. p. .  	 
\bibitem[The network simulator -ns-2 ()]{b0}\label{b0} 	 		\textit{The network simulator -ns-2},  		 \url{http://www.isi.edu/nsnam/ns/}  		2001.  	 
\bibitem[Postel ()]{b21}\label{b21} 	 		‘Transmission Control Protocol’.  		 			J Postel 		.  		 \url{URLhttp://www.rfc-editor.org/rfc/rfc793.txt}  	 	 		\textit{RFC}  		1981. 793.  	 
\bibitem[Rangwala et al. ()]{b22}\label{b22} 	 		‘Understanding congestion control in multi-hop wireless mesh networks’.  		 			S Rangwala 		,  		 			A Jindal 		,  		 			K Y Jang 		,  		 			K Psounis 		,  		 			R Govindan 		.  	 	 		\textit{Proceedings of the 14th ACM international conference on Mobile computing and networking, MobiCom '08},  				 (the 14th ACM international conference on Mobile computing and networking, MobiCom '08)  		2008. ACM. p. .  	 
\bibitem[What do packet dispersion techniques measure? ()]{b4}\label{b4} 	 		\textit{What do packet dispersion techniques measure?},  		2001. IEEE INFOCOM.  	 
\bibitem[Dukkipati and Mckeown ()]{b14}\label{b14} 	 		\textit{Why flow-completion time is the right metric for congestion control},  		 			N Dukkipati 		,  		 			N Mckeown 		.  		2006. ACM SIGCOMM.  	 
\bibitem[Akyildiz et al. ()]{b3}\label{b3} 	 		‘Wireless mesh networks: a survey’.  		 			I F Akyildiz 		,  		 			X Wang 		,  		 			W Wang 		.  	 	 		\textit{Computer Networks}  		2005. 47  (4)  p. .  	 
\bibitem[Barreto and Sargento ()]{b10}\label{b10} 	 		\textit{XCP-winf and RCP-winf: A new approach for wireless congestion control},  		 			L Barreto 		,  		 			S Sargento 		.  		 \url{URLhttp://plataformas.esce.ipvc.pt/lbarreto/XCPwinf.pd}  		2014.  		 			Submitted to Springer Journal of Network and Systems Management 		 	 
\bibitem[Barreto and Sargento ()]{b9}\label{b9} 	 		‘XCP-winf and RCP-winf: Congestion control techniques for wireless mesh networks’.  		 			L Barreto 		,  		 			S Sargento 		.  	 	 		\textit{IEEE International Conference on Communications},  				 (Kyoto, Japan)  		2011. 2011.  	 
\end{bibitemlist}
 			 		 	 
\end{document}
