\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={Mesh Based and Hybrid Multicast Routing Protocols for Manets: Current State of the Art},
 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{2012-05-15 (revised: 15 May 2012)}
\def\TheID{\makeatother }
\def\TheDate{2012-05-15}
\title{Mesh Based and Hybrid Multicast Routing Protocols for Manets: Current State of the Art}
\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]{Dr. P.Prasanna Murali  Krishna}

             \author[2]{A.V.R.  Mayuri}

             \author[3]{Dr. K.Satya  Prasad}

             \affil[1]{  }

\renewcommand\Authands{ and }

\date{\small \em Received: 6 April 2012 Accepted: 3 May 2012 Published: 15 May 2012}

\maketitle


\begin{abstract}
        


This paper discusses various multicast routing protocols which are proposed in the recent past each having its own unique characteristic, with a motive of providing a complete understanding of these multicast routing protocols and present the scope of future research in this field. Further, the paper specifically discusses the current development in the development of mesh based and hybrid multicasting routing protocols. The study of this paper addresses the solution of most difficult task in Multicast routing protocols for MANETs under host mobility which causes multi-hop routing which is even more severe with bandwidth limitations. The Multicast routing plays a substantial part in MANETs.

\end{abstract}


\keywords{}

\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& 	 	 		 \par
literature is composed of several multicast routing protocol from various routing philosophies. A proactive multicast routing protocol pre-determines the routes between any two nodes even if no such route is required. In contrast, reactive multicast routing finds a route as per the requirement i.e. on-demand. In some of the protocols all available nodes are peers referred as flat network topology whereas in others a hierarchy is maintained among nodes and only nodes belonging to same level of hierarchy are considered as peers. Many of the protocols presume that every individual node is aware about its present location in the network and at the same time is competent enough to learn the locations of other nodes in the network. The literature also features some protocols which are even capable of co-relating the available energy from the battery and the required energy for packet data transfer. Even few multicast routing protocols discover and maintain multipaths for a given node pair, for which the utility of these multiple paths are a function of the features of the protocol. The work of this paper presents an up-to-theminute review of unique multicast routing protocols for MANETs. As it is a tedious job to comment on the applicable efficiency of a protocol in a given set of conditions, hence the motive of this paper is to classify these multicast routing protocol under various routing categories. As a fact of amazement, we have found that depending on their primary routing selection principle, all of these protocols can be categorized under either application independent-based multicast routing or application dependent-based multicast routing strategies. Correspondingly, the results presented in this survey can be utilized by the research community and this can lead to a new archetype for the evaluation of multicast routing protocols \hyperref[b3]{[4]}.\par
Even though several such surveys are already developed, of which some are even cited in this paper, most of them are not updated. The work of this paper is unique as it introduces new technical parameters as overlay multicast, network coding-based multicast, energy efficient multicast etc. and the classification of the multicast protocols is a authentic aspect of this article. This paper is composed by genuine methodology which does not co-relates with the classification methods of either the convention internet multicast or the methods of previous surveys, in the area and give sufficient in-depth knowledge about the present day advancements in the field. The primary objective of this paper is to generate a valuable classification of the field of multicast routing protocol, which is detailed and updated.\par
To achieve this objective, we have identified those fundamental components of a multicast routing protocol, disassembled them into the significant individual mechanisms, and classified features on the basis of mechanisms which we felt necessary to accomplish its function for the multicast routing protocol.\par
The paper is structured as follows: The Section II discovers preferred properties of the multicast routing; the categorization of multicast routing protocols for MANET was discovered in Section III. Section IV discusses the present state of the art in advancement of mesh based and hybrid multicast routing protocols for MANETs.\par
1. In order to avoid the sever cons such as packet dropping, robustness in adapting node mobility and unwarned changes in topology with limited control overhead must be the quality of multicast routing protocols. The control overhead minimization is particular in topologies with limited or low energy levels. 2. The transmission of control packets needs to be limited and related to the total number of data packets reaching their destination. 3. Energy saving techniques aimed at minimizing the total power consumption of all nodes in the multicast group (minimize the number of nodes used to establish multicast connectivity, minimize the number of overhead controls, etc.) and at maximizing the multicast life span should be considered. 4. Multicast routing protocols should be able to reserve different network resources to achieve QoS requirements such as, capacity, delay, delay jitter, and packet loss. 5. Due to ad-hoc infrastructure, wireless medium and broadcast nature MANETS are vulnerable to eavesdropping, interference, spoofing, and so forth. Hence it is obvious to provide security for any routing methodology that includes multicast routing also. 6. Consistency in Stability also referred as scalability need to be at its high that regardless of node count and infrastructure limits and variations.\par
Multicast routing protocols can be classified based on following properties: Layer: The network layer that routing protocol targeting Topology: The topology that used by protocol Routing scheme: The routing scheme selected for protocol Initialization: The node selected for initialization process.\par
Responsibilities of Network layers : Out of the IP layer and MAC layer, the former is liable for routing data between a source-destination pair (end-to-end), whereas the latter make sure that the packet data is delivered properly to the destination (reliability), this brings in role of the Application layer in order to buffer data locally until the acknowledgments (ACKs) have been received. The applicability criteria of the OMR model can be decided from the OMR protocols \hyperref[b16]{[16,}\hyperref[b47]{45,}\hyperref[b48]{46,}\hyperref[b49]{47,}\hyperref[b31]{30]} which have had been repeatedly quoted in literature, the following are the considerations for choice of OMR model: 1) As it does not require variations at the network layer, it is simple to deploy. 
\section[{Global Journal of Computer Science and Technology Volume XII Issue VI Version I March}]{Global Journal of Computer Science and Technology Volume XII Issue VI Version I March}\par
2) There is no requirement for the intermediate (forwarder) nodes to maintain their per group state for each multicast group which have always been a tedious task, even on the internet.\par
3) The various routing complication are overshadowed by the creation of a virtual (logical) topology, like the link failure conditions, which are left to be trouble shooted at the network layer itself. 4) At last, Overlay multicasting can deploy the capabilities of lower-layer protocols in providing flow control, congestion control, security, or reliability as per the requirements of the application.\par
Overlay multicasting can refer as multiple unicast routing paths, hence the transmission of all multicast data packets among the group members take place in the form of unicast packet, which raises the issue of packet collision and low resource utilization exclusively where group member location density is high.\par
MAC layer Multicast Routing MMR : The main objective of the MAC layer multicasting is enhancing the network efficiency through the enactment of positive ACK and retransmission policies for multicast data transmission. This sometimes result into considerable end-to-end dormancies in multicast data delivery, may cause significant end-to-end latencies in multicast data delivery, particularly when the source and destination are separated by a huge quantity of hops. Moreover, this method may enhance the node buffer size \hyperref[b50]{[48]}. The performance of multicast communication can be considerably enhanced by the use of a dependable and competent MAC layer multicast protocol. 
\section[{b) Classification by Routing Schemes}]{b) Classification by Routing Schemes}\par
Proactive or Reactive or On-Demand by source : As per the requirement of multicast routes to a multicast group by the source node, a route discovery process either local or global is initiated by the source node within the network. This results in an on-demand update about the multicast routing and group membership. In comparison with the table-driven multi-cast protocols this approach uses less power, capacity and low control overhead. But, this approach may result in rout acquisition latency.\par
Hybrid routing scheme : When connected nodes are grouped based on the topology in hierarchical way then each hierarchy can opt to either proactive or reactive to elevate the respective drawbacks. This approach is known as Hybrid Routing Scheme. But this model needs to tolerate route acquisition latency at hierarchy level that relies on reactive approach. The delay time at node joining to a multicast group is not tolerable and can claim as drawback of this model. 
\section[{c) Classification By Connection Initiation Process}]{c) Classification By Connection Initiation Process}\par
Connection Initiation by source : The source constructs a multicast mesh or tree by flooding the network with a Join Request message. Any receiver node wishing to join a multicast group replies with a Join Reply message.\par
Connection initiation by target : receiver node wishing to join a multicast group floods the network with a Join Request message searching for a route to a multicast group.\par
Connection initiation by source or target : Some multicast protocols may not fall strictly into either of these two types of approach when they do not distinguish between source and receiver for initialization of the multicast group. Initialization is achieved either by the source or by the receiver. This type can be identified as a hybrid approach. 
\section[{d) Classification by Route Construction Approach}]{d) Classification by Route Construction Approach}\par
Tree based Approaches : The multicast data is forwarded over a tree, on a tree-based protocol developed in a fixed multicast routing. The tree based approaches suffer from offering less stiffness to the network apart from mobility susceptible for link failure, even though they are appraised on the issue of their band-width efficiencies.\par
Source-Tree-based approach : In this approach each source node creates a single multicast tree spanning all the members in a group. Usually, the path between the source and each member is not the shortest.\par
Shared-Tree based approach : In this approach only one multicast tree is created for a multicast group which includes all the source nodes. This tree is rooted at a node referred as the core node. Each source uses this tree to initiate a multicast. Shared-Tree-based approach not considering the shortest path for routing, but it considers single point of failure, hence it maintains more routing information that leads to overhead. In addition, the traffic is aggregated on the shared tree rather than evenly distributed throughout the network, which gives it low throughput.\par
Mesh-based approach : This approach the source to all receivers communicates under mesh topology. This approach is good in terms of elimination of link failure situations and high packet delivery rate as it offers multiple paths between source and any connected node. But this approach suffers from the flaws like capacity wastage, power insufficiency and dismissed transmission of data packet leads to more overhead. As a conclusion it can be said with sufficient confidence that the Mesh-based approach is more advisable for MANETs than the Tree-based approach.\par
Hybrid approach : This approach provides a blend of mesh-based and tree-based approaches; as a result it provides robustness as well as efficiency.\par
Stateless Approach : This approach is good for only small multicast group. The methodology of this approach is instead of maintaining the routing information at every forwarding node; a source specifically mentions the destination list in the packet header. This stateless approach \hyperref[b14]{[14,}\hyperref[b31]{30,}\hyperref[b32]{31]} is optimal to avoid the overhead caused by mesh or tree construction. 
\section[{e) Classification by Group Maintenance Approach}]{e) Classification by Group Maintenance Approach}\par
There is a high-time need of efficient group maintenance in the MANETs as it suffers from frequent link breaks due to the lack of mobility of the nodes.\par
Proactive Soft State : Proactive soft state approach maintains the multicast group by refreshing the group membership and associated routes by flooding the control packets periodically Reactive Hard State : This approach sends control packets at the time of link failure and as a result routes are reconfigured.\par
Proactive Hard State : This approach with the aid of local prediction techniques based on GPS or signal strength reconfigures the routed prior to link failure.\par
However, on one hand the soft-state approach is good in terms of reliability i.e. high packet delivery ratio and whereas the hard-state approach is considerably efficient in terms of overhead. i.\par
Adaptive Shared-Tree Multicast (ASTM) Routing ASTM \hyperref[b5]{[6]} is a hybrid protocol that presents a wonderful blend of per source and shared tree and is based on the notation of the Rendezvous Point (RP). The receiver members create the RP-rooted multicast forwarding tree periodically sending Join Requests to the RP. The join request consists of the forward list, which is originally set to include all senders. Sources send their multicast data to the RP, and the RP forwards the multicast data to the receivers. However, depending on the protocol operation as in unicast sender mode the internal nodes in between the path of source and RP may or may not promote these packets to other nodes. But in case of multicast sender mode the packet can be forwarded to other nodes and that will be known to the source. Further, in case if the nodes are in vicinity the ASTM facilitates the source to send a packet directly to the receiver node eliminating the need to pass through the RP, this method is known as adaptive multicast (adaptive per source multicast routing).\par
Observation: : The dependence of the ASTM on the RP is considered to be a failure. Further the increase in the mobility results decrement in the output, because of the impotency of the routing and multicast protocol to maintain their pace at par with the node movements. In case of the adaptive multicast, the efficiency lowers because even though the source can directly transmit the destination but often the path is not the shortest.\par
ii.\par
On-Demand Multicast Routing Protocol (ODMRP) ODMRP \hyperref[b24]{[24]} is a source-initiated multicast routing protocol which introduces the concept of forwarding group in which only few nodes can forward the multicast packets. In certain cases where the multicast sources have data to send but they lack the routing or membership information, they transmit a JOIN DATA. When a node receives a genuine JOIN DATA packet, the same is restored in the upstream node ID and it retransmits the packet. In such situations when the JOIN DATA reaches the destination i.e. the multicast receiver it initiates the formation of a JOIN TABLE and sends it to the fellow nodes. Furthermore, at the reception of a JOIN TABLE packet the node it initiates the verification of the next node ID pursuant to its own ID. Based on the verification if the next ID matches to the ID of sender node, the later realizes that the former is in the path to the source and thus is a part of the forwarding group. It then broadcasts its own JOIN TABLE packet built upon matched entries. Hence in this way the JOIN TABLE packet is forwarded by each group member through the shortest possible path to the multicast source.\par
Observation: The primary flaw in the ODMRP is high control overhead while maintaining the current forwarder groups and all network request package flooding; the problem can be easily addressed by the measures suggested by Xiong et al. \hyperref[b37]{[36]}, the preemptive route maintenance. Further, the second disadvantage is the reduction in multicast efficiency due to the duplication of packets between the forwarding nodes and the destination source. Apart from these two flaws, this approach suffers a drawback due to scalability problem. Finally, the sources must be part of the group's multicast mesh, even when they are not interested in receiving multicast packets.\par
iii.\par
Adaptive Core Multicast Routing Protocol (ACMRP) ACMRP \hyperref[b8]{[9]} is an on-demand core based multicast routing protocol. A multicast mesh is shared by the sources of a group. A designated node, called a core, while not well known, adapts to the current Global Journal of Computer Science and Technology Volume XII Issue VI Version I March network topology and group membership status. A multicast mesh is created and maintained by the periodic flooding of a Join Request packet which is performed by the adaptive core. When a node receives a fresh JREQ, it inserts the packet into its jreq cache and updates the route to the core. Then, it changes the "upstream node address" field in the packet to its own address and retransmits the packet. Group members (including multicast receivers as well as sources) send a Join Reply (JREP) packet to their upstream node on receipt of a non duplicate JREQ packet. Upon receiving the JREP, the upstream node stores the group address, which will be used to forward multicast packets destined for the group in the future. This node is called a forwarding node. It inserts a (group address, source address) pair into the forwarding group table. Then, it sends a JREP to its own upstream node. Eventually, the JREP reaches the core. The backward propagations of JREPs construct multicast routes between group members and the core. Consequently, a multicast mesh is established. The adaptive core mechanism of ACMRP automatically handles any link failure, node failure, or network partition.\par
Observation: The advancement in the adaptivity of ACMRP decreases core dependency, thereby improving performance and robustness and making ACMRP manages to perform well dynamically changing networks. This approach fits well in the heavily loaded ad hoc network as well as it scales brilliantly to large number of group members. The major problem with this approach is the path between the nodes and the destination source is not the shortest, apart from this the selection of core is complicated. The location of the core position is of primary importance, while positioning the core it should be considered that it is placed with the least hop counts of routes toward group members and assure that it has sufficient residual power for support until the election of the new core. iv. 
\section[{Dynamic Core-Based Multicast Routing Protocol (DCMP)}]{Dynamic Core-Based Multicast Routing Protocol (DCMP)}\par
The DCMP \hyperref[b15]{[15]} is an advanced version of the ODMRP and it addresses the issue of minimizing the number of senders flooding JREQ packets by choosing specific senders as cores. This further decreases the control overhead and hence enhances the efficiency of the ODMRP multicast protocol. In terms of the working methodology the DCMP generates a similar mesh as that of the ODMRP. It classifies the sources into three group of reducing the flooding, as: active, passive and core active; among which only the active and core active sources flood the JREQ. Packets generated at the passive sources are transmitted to the core active sources, which further forwards them to the mesh. A healthy operation is carried out by keeping a restriction on the number of core active sources aiding the passive sources, whereas to keep the packet delivery ratio high the distance or number of hops between a passive sources and a core active source should not be limited.\par
Observation: Even though the DCMP is incapable to address all the issues of ODMRP but is widely appraised for its enhanced scalability. Moreover, in the situation of failure of a core active source, multiple multicast sessions fails. v.\par
Multicast for Ad Hoc Networks with Swarm Intelligence (MANSI) MANSI \hyperref[b6]{[7]}, employs swarm intelligence to outlast the flaws of multicast routing in MANETs. Swarm intelligence refers to complex behaviors that arise from very simple individual behaviors and interactions, which are often observed in nature, especially among social insects such as ants and honey bees. Although each individual (an ant, e.g.,) has little intelligence and simply follows basic rules using local information obtained from the environment, global optimization objectives emerge when ants work collectively as a group. In this context MANSI segregates minute control packets which collect the information at the nodes visited by them. MANSI's methodology is core-based approach under which to establish multicast connectivity between the member nodes it employs the designated node (core), it makes the core the leader in the multicast session. It initiates a session by announcing its presences by flooding the network with a CORE ANNOUNCE packet. This is followed by transmission of a JREQ packet by the member nodes, as an act of reaction for the establishment of a connection, the JREQ packets flood back to the core by the reverse path. In this way this approach nullifies the event of duplication of packet data since only those nodes act as forwarders which have had received the JREQ addressed to themselves. Further these forwarding nodes are responsible for accepting and retransmitting the packets. To maintain connectivity and allow new members to join, the core floods CORE ANNOUNCE periodically, as long as there are more data to be sent. As a consequence, these forwarding nodes form a mesh structure that connects the group members, while the core serves as a focal point for forwarding set creation and maintenance.\par
Observation: The addition of swarm intelligence in MANSI reduces the number of nodes used to establish the multicast connectivity, however, the path between the multicast member and forwarding node sets can't be referred as shortest. Further, this approach increases the probability of successful delivery of the packets as due to the mesh-based methodology enhances the redundancy. In MANSI, group connectivity can be made more efficient by having some members share common paths to the core with other members in order to further reduce the total cost of forwarding data packets. Since a node's cost is abstract and may be defined to represent different metrics, MANSI can be applied to many variations of multicast routing problems for ad hoc networks, such as load balancing, secure routing, and energy conservation. vi. 
\section[{Forward Group Multicast Protocol (FGMP)}]{Forward Group Multicast Protocol (FGMP)}\par
FGMP \hyperref[b16]{[16]} is a multicast routing protocol that creates a multicast mesh on demand, and is based on the forwarding group concept. FGMP keeps track not of links but of groups of nodes which participate in multicast packet forwarding.\par
Observation: The FGMP keeps a check on flooding by keeping a cap over the GS nodes, and hence it decreases channel and overhead storage overhead. . But the protocols efficiency can suffer heavily in the cases of highly mobile environment due to the repeated variations in FG. The FGMP addresses the issues only accepted in small networks and specifically only when the number of receivers is less than the number of senders. The usage of FGMP-SA is proved to considerably efficient in the networks with more number of sources than the multicast nodes, else in the viceversa circumstances FGMP-RA is more efficient than FGMP-SA. vii. 
\section[{CAMP : Core-Assisted Mesh Protocol}]{CAMP : Core-Assisted Mesh Protocol}\par
This approach, CAMP \hyperref[b13]{[13]} is the next generation core based trees CBT \hyperref[b38]{[37]} which were made known for Internet multicasting into multicasting meshes and further which possess higher connectivity than the conventional trees. In cases of repeated movement of the network routers, to facilitate better connectivity this approach defines a shared multicast group. CAMP establishes and maintains a multicast mesh, which is a subset of the network topology, which provides multiple paths between a source-receiver pair and ensures that the shortest paths from receivers to sources (called reverse shortest paths) are part of a group's mesh. One or multiple cores are defined per multicast group to assist in join operations; therefore, CAMP eliminates the need for flooding. CAMP uses a receiver-initiated approach for receivers to join a multicast group. A node sends a JREQ toward a core if none of its neighbors is a member of the group; otherwise, it simply announces its membership using either reliable or persistent updates. If cores are not reachable from a node that needs to join a group, the node broadcasts its JREQ using an ERS, which eventually reaches some group member. In addition, CAMP supports an alternate way for nodes to join a multicast group by employing simplex mode.\par
Observation: CAMP needs an underlying proactive unicast routing protocol (the Bellman-Ford routing scheme) to maintain routing information about the cores, in which case considerable overhead may be incurred in a large network. Link failures have a small effect in CAMP, so, when a link fails, breaking the reverse shortest path to a source, the node affected by the break may not have to do anything, because the new reverse shortest path may very well be part of the mesh already. Moreover, multicast data packets keep flowing along the mesh through the remaining paths to all destinations. However, if any branch of a multicast tree fails, the tree must reconnect all components of the tree for packet forwarding to continue to all destinations. viii.\par
Source Routing-Based Multicast Protocol (SRMP) SRMP \hyperref[b28]{[27]} is an on-demand multicast routing protocol. It constructs a mesh topology to connect each multicast group member, thereby providing a richer connectivity among members of a multicast group or groups. To establish a mesh for each multicast group, SRMP uses the concept of FG nodes. SRMP applies the source routing mechanism defined in the Dynamic Source Routing (DSR) \hyperref[b39]{[38]} protocol to avoid channel overhead and to improve scalability. Also, SRMP addresses the concept of connectivity quality. Moreover, it addresses two important issues in solving the multicast routing problem: the path availability concept and higher battery life paths.\par
Observation: SRMP selects the most stable paths among multicast group members. This not only maximizes the lifetime of the routes but also offers more reliability and robustness, thus results in the consumption of less power In addition it minimizes channel and storage overhead (improving the scalability of the protocol) by the means of route discovery and link failure detection on demand, as well as saving bandwidth and network resources The value of the four metrics used in selecting the paths may not be globally constant, however. They probably vary with different network load conditions. For this very reason the four metrics must be made to be adaptive to the network load conditions. ix.\par
Neighbor-Supporting Multicast Protocol (NSMP) NSMP \hyperref[b22]{[22]} is a source-initiated multicast routing protocol, and is an extension to ODMRP \hyperref[b24]{[24]}. A mesh is created by a source, which floods a request throughout the network. Intermediate nodes cache the upstream node information contained in the request and forward the packet after updating this field. When a route discovery packet is discovered by any node present in the network, a reply to its upstream nodes is sent. Intermediate nodes receiving these replies make an entry in their routing tables and forward the replies upstream toward the source in the case where multiple route discovery packets are received by the receiver, it makes use of relative weight metric (which depends on the number of forwarding and non-forwarding nodes on the path from the source to the receiver)for selecting one route out of multiple routes. A path which holds the lowest relative weight is chosen.\par
Observation: the aim of NSMP is to reduce the flood of control packets to a subset of the entire network. Node locality utilization technique is applied to reduce the control overhead while it also maintains a high delivery ration which increases the overall Global Journal of Computer Science and Technology Volume XII Issue VI Version I March performance. NSMP favors paths with a larger number of existing forwarding nodes to reduce the total number of multicast packets transmitted. It is preferable to make the relative weight metric adaptive to variations in the network load conditions.\par
x.\par
On-Demand Global Hosts for Ad Hoc Multicast (OGHAM) OGHAM \hyperref[b23]{[23]} constructs two-tier architecture by selecting backbone hosts (BHs) on demand for multicast services. Each multicast member must be attached to a BH. In order to obtain shorter multicast routes, the hosts with a minimal number of hops to the other hosts are adopted as BHs in order to obtain shorter multicast routes., rather than those with a maximum no. of neighbors. BHs are responsible for determining multicast routes, forwarding data packets, handling dynamic group membership (the nodes can dynamically join or leave the group), and updating multicast routes due to host movement.\par
Observation: OGHAM minimizes transmission time and lost packets because BHs aims at minimizing the total number of hops to all the hosts (receivers) in OGHAM firstly the infrastructure for a particular multicast group is constructed, the selected BHs are made globally available for the other ad hoc multicast groups .Therefore, it is not necessary for follow up multicast groups to flood again for constructing an additional infrastructure. Hence the ratio of control packets declines (very scalable) with the increment in the group size or the group number. 
\section[{xi.}]{xi.}\par
Agent-Based Multicast Routing Scheme (ABMRS) ABMRS \hyperref[b41]{[40]} employs a set of static and mobile agents in order to find the multicast routes, and to create the backbone for reliable multicasting, as a result of which the packet delivery ratio is improved. The including steps of the ABMRS are the following: reliable node identification, reliable node interconnection, reliable backbone construction, multicast group creation, and network and multicast group management. The Reliability Factor (RF, which depends on various parameters such as power ratio, bandwidth ratio, memory ratio, and mobility ratio) is computed by the Route Manager Agent (RMA) present at each node and this RF is advertised to each of its neighbors. The Network Initiation Agent (NIA) at each node receives the advertised packet and determines who has the highest RF. The node with the highest RF will announce itself as a reliable node and inform its RMA.\par
Observation: ABMRS computes multicast routes in a distributed manner, which provides good scalability. ABMRS is more reliable, that is, it has a higher packet delivery ratio, than MAODV \hyperref[b19]{[19]}.this is because ABMRS uses reliable nodes to create multicast tree. However a significant control overhead is observed compared to MAODV, especially when mobility and the multicast group size are increased. The reason for this is that more agents are generated to find a route to reliable nodes. ABMRS assumes the availability of agent platform at all mobile nodes. However, if the agent platform is somehow unavailable, the traditional message exchange mechanism can be used for agent communication. This results in incurring more control overhead. In addition, ABMRS uses Dijkstra's algorithm for computing routes between two reliable nodes, and, therefore, it needs the network topology in advance. As a result, ABMRS has a scalability issue and a significant overhead will be incurred as well.\par
xii.\par
Optimized Polymorphic Hybrid Multicast Routing Protocol (OPHMR) OPHMR \hyperref[b42]{[41]} is built using the reactive behavior of ODMRP \hyperref[b24]{[24]} and the proactive behavior of the MZRP \hyperref[b21]{[21]} protocol. In addition, the Multipoint Relay (MPR) based mechanism of the OLSR \hyperref[b43]{[42]} protocol is used to perform an optimization forwarding mechanism. OPHMR attempts to incapacitate the three desired routing characteristics, namely, hybridization (the ability of mobile nodes (MNs) to behave either proactively or reactively, depending on the conditions), adaptability (the ability of the protocol to adapt its behavior for the best performance when mobility and vicinity density levels are changed), and power efficiency. To enable hybridization and adaptability, that is, polymorphism, OPHMR introduces different threshold values, namely, power, mobility, and vicinity density. OPHMR is empowered with various operational modes which are either proactive or reactive, based on an MN's power residue, mobility level, and/or vicinity density level. In a route, According to its own strategy each MN tries to determine the destination node. Thus, the MNs maintain their own routing tables in order to try to find the next forwarding nodes, these routing tables are established in the background for proactive stations, or by using broadcasting for reactive stations. This feature ensures the avoidance of any hysterical behavior.\par
Observation: OPHMR is, in the long run, enhances the survivability of the mobile ad hoc nodes and is able to extend the battery life of the mobile ad hoc nodes. As a result, the end-to-end delay is decreased and the packet delivery ratio is increased, in comparison with other protocols, such as ODMRP \hyperref[b24]{[24]},while the control packet overhead remains at an acceptable rate. OPHMR follows the proactive Hard-State approach to maintain the multicast topology. Hence, the packet delivery ratio decreases as the mobility of the nodes increases. 
\section[{xiii.}]{xiii.}\par
Ad Hoc Multicasting Routing Protocol (AMRoute) AMRoute \hyperref[b44]{[43]} creates a multicast shared-tree over mesh. It uses the unicast tunnels in creating bidirectional shared multicast tree to provide connections between multicast group members. At least one logical core that is responsible for group members and tree maintenance is presented in each group.\par
Initially every group members declares itself as a core for its own group of size 1. Each core discovers others disjoint mesh segments for the group by periodically flooding JREQs (using an ERS).\par
Observation: AMRoute aims at creating an efficient and robust shared tree for each group. It helps in keeping the multicast delivery tree unchanged with changes of network topology, as long as there exists a path between tree members and core nodes via mesh links. Amroutes suffers from loop formation and nonoptimal tree creation, and requires higher overhead in assigning a new core, when there is mobility present. Amroutes also suffers from a single point of failure of the core node.\par
xiv.\par
Progressively Adapted Sub-Tree in Dynamic Mesh (PASTDM) PASTDM \hyperref[b48]{[46]} is an overlay multicast routing protocol that creates a virtual mesh spanning all the members of a multicast group. PASTDM \hyperref[b48]{[46]} employs standard unicast routing and forwarding in order to fulfill multicast functionality. A multicast session is started with the construction of a virtual mesh, on top of the physical links, spanning all group members. A neighbor discovery process is started, using the ERS technique \hyperref[b36]{[35]} by each of the member node. For this purpose, Group REQ messages are periodically exchanged among all the member nodes.\par
Observation: PASTDM constructs a virtual mesh topology, which has the advantage of scaling very well, since this topology can hide the real network topology, regardless of the network dimension. In addition, it uses unicast routing to carry the packets. Moreover, in the existence of the change of the underlying topology, PASTDM alleviates the redundancy in data delivery. However, since PASTDM does not explicitly consider node mobility prediction in the computation of the adaptive cost, the link cost calculation may be incorrect. In addition, it constructs the overlay and maintains even if no source has multicast data to transmit. Exchanging link state information with neighbors and the difficulty of preventing different unicast tunnels from sharing the same physical links may affect the efficiency of the protocol. Simulations \hyperref[b48]{[46]} show that PASTDM is more efficient than AMRoute.\begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}IP}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{Driven} \par 
\begin{longtable}{P{0.7999244712990936\textwidth}P{0.05007552870090635\textwidth}}
\tabcellsep : The name itself\\
\multicolumn{2}{l}{indicates the routing information sustains at every}\\
\multicolumn{2}{l}{individual node by one or more tables. The event driven}\\
\multicolumn{2}{l}{table update model or periodical table update model}\\
\multicolumn{2}{l}{can be used for the table update mechanism. Such}\\
\multicolumn{2}{l}{protocols require table updates repeatedly that are}\\
\multicolumn{2}{l}{pursuant to topology variations. The table updates does}\\
\multicolumn{2}{l}{not depends on the need of a topology chance, further}\\
\multicolumn{2}{l}{which displays a flaw of high power consumption and}\\
pertaining more capacity\tabcellsep and sufficient control\\
\multicolumn{2}{l}{overhead, particularly in the situations of highly mobile}\\
\multicolumn{2}{l}{environment where topology variations are more}\\
\multicolumn{2}{l}{frequent. In contrast, this approach results in minimal}\\
route acquisition latency.\tabcellsep \end{longtable} \par
 
\caption{\label{tab_0}Table Driven}\end{figure}
 			\footnote{© 2012 Global Journals Inc. (US)} 			\footnote{© 2012 Global Journals Inc. (US) Global Journal of Computer Science and Technology Volume XII Issue VI Version I} 			\footnote{© 2012 Global Journals Inc. (US)} 			\footnote{© 2012 Global Journals Inc. (US)} 		 		\backmatter  			 
\subsection[{Protocol}]{Protocol}\par
Routing   {\ref 1}: Tabular representation of the mesh based and hybrid multicast routing protocols and their properties\par
In this article we provide descriptions of several mesh based and hybrid multicast routing schemes proposed for ad hoc mobile networks. We also provide a classification of multicast routing schemes according to network layer, topology used, initiation strategy and maintenance strategy. Finally we have concluded that it is not clear that any particular algorithm or class of algorithm is the best one for all scenarios, every protocol is enriched with definite advantages and disadvantages, and is well suited only for certain situations. Ad hoc mobile networking field is rapidly growing and changing and with this advancement there are still many challenges that need to be met.			 			  				\begin{bibitemlist}{1}
\bibitem[Das et al. ()]{b15}\label{b15} 	 		‘A dynamic core based multicast routing protocol for ad hoc wireless networks’.  		 			S K Das 		,  		 			B S Manoj 		,  		 			C S R Murthy 		.  	 	 		\textit{Proceedings of the International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc '02)},  				 (the International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc '02))  		2002. p. .  	 
\bibitem[Wang et al. ()]{b20}\label{b20} 	 		‘A multicast routing algorithm based on mobile multicast agents in ad-hoc networks’.  		 			X Wang 		,  		 			F Li 		,  		 			S Ishihara 		,  		 			T Mizuno 		.  	 	 		\textit{IEICE Transactions on Communications}  		2001.  (8)  p. .  	 
\bibitem[Law et al. ()]{b40}\label{b40} 	 		‘A novel adaptive protocol for lightweight efficient multicasting in ad hoc networks’.  		 			L K Law 		,  		 			S V Krishnamurthy 		,  		 			M Faloutsos 		.  	 	 		\textit{Computer Networks}  		2007. 51  (3)  p. .  	 
\bibitem[Sisodia et al. ()]{b25}\label{b25} 	 		‘A preferred link based multicast protocol for wireless mobile ad hoc networks’.  		 			R S Sisodia 		,  		 			I Karthigeyan 		,  		 			B S Manoj 		,  		 			C S R Murthy 		.  	 	 		\textit{Proceedings of the IEEE International Conference on Communications (ICC '03)},  				 (the IEEE International Conference on Communications (ICC '03))  		2003. 3 p. .  	 
\bibitem[Sisodia et al. ()]{b35}\label{b35} 	 		‘A preferred link based routing protocol for wireless ad hoc networks’.  		 			R S Sisodia 		,  		 			B S Manoj 		,  		 			C S R Murthy 		.  	 	 		\textit{Journal of Communications and Networks}  		2002. 4  (1)  p. .  	 
\bibitem[Toh et al. ()]{b10}\label{b10} 	 		‘ABAM: ondemand associativity-based multicast routing for ad hoc mobile networks’.  		 			C.-K Toh 		,  		 			G Guichal 		,  		 			S Bunchua 		.  	 	 		\textit{Proceedings of the IEEE Vehicular Technology Conference (VTC '00)},  				 (the IEEE Vehicular Technology Conference (VTC '00))  		2000. 3 p. .  	 
\bibitem[Shen and Jaikaeo ()]{b6}\label{b6} 	 		‘Ad hoc multicast routing algorithm with swarm intelligence’.  		 			C.-C Shen 		,  		 			C Jaikaeo 		.  	 	 		\textit{Mobile Networks and Applications}  		2005. 10  (1)  p. .  	 
\bibitem[Perkins ()]{b36}\label{b36} 	 		\textit{Ad Hoc On Demand Distance Vector (AODV) Routing},  		 			C E Perkins 		.  		1997.  	 	 (Internet-Draft, draft-ietf-manetaodv-00.txt) 
\bibitem[Wu et al. ()]{b7}\label{b7} 	 		\textit{Ad hocMulticast Routing protocol utilizing Increasing id-numberS (AMRIS)," draftietf-manet-amris-spec-00.txt},  		 			C W Wu 		,  		 			Y C Tay 		,  		 			C.-K Toh 		.  		2000.  	 
\bibitem[Park and Park ()]{b8}\label{b8} 	 		‘Adaptive core multicast routing protocol’.  		 			S Park 		,  		 			D Park 		.  	 	 		\textit{Wireless Networks}  		2004. 10  (1)  p. .  	 
\bibitem[Jetcheva and Johnson ()]{b9}\label{b9} 	 		‘Adaptive demand-driven multicast routing in multi-hop wireless ad hoc networks’.  		 			J G Jetcheva 		,  		 			D B Johnson 		.  	 	 		\textit{Proceedings of the 2nd ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc '01)},  				 (the 2nd ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc '01))  		2001. p. .  	 
\bibitem[Chiang et al. ()]{b5}\label{b5} 	 		‘Adaptive shared tree multicast in mobile wireless networks’.  		 			C.-C Chiang 		,  		 			M Gerla 		,  		 			L Zhang 		.  	 	 		\textit{Proceedings of the IEEE Global Telecommunications Conference (GLOBECOM '98)},  				 (the IEEE Global Telecommunications Conference (GLOBECOM '98))  		1998. 3 p. .  	 
\bibitem[Xie et al. ()]{b44}\label{b44} 	 		‘AMRoute: ad hoc multicast routing protocol’.  		 			J Xie 		,  		 			R R Talpade 		,  		 			A Mcauley 		,  		 			M Liu 		.  	 	 		\textit{Mobile Networks and Applications}  		2002. 7  (6)  p. .  	 
\bibitem[Annual IEEE International Conference on Local Computer Networks (LCN '04) ()]{b46}\label{b46} 	 		\textit{Annual IEEE International Conference on Local Computer Networks (LCN '04)},  				2004. p. .  	 
\bibitem[Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM'01) ()]{b12}\label{b12} 	 		\textit{Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM'01)},  				2001. 2 p. .  	 
\bibitem[Biswas and Nandy]{b45}\label{b45} 	 		‘Application layer multicasting for mobile ad-hoc networks with network layer support’.  		 			J Biswas 		,  		 			S K Nandy 		.  	 	 		\textit{Proceedings of the 29th},  				 (the 29th)  		 	 
\bibitem[Ge et al. ()]{b47}\label{b47} 	 		‘Application versus network layer multicasting in ad hoc networks: the ALMA routing protocol’.  		 			M Ge 		,  		 			S V Krishnamurthy 		,  		 			M Faloutsos 		.  	 	 		\textit{Ad Hoc Networks}  		2006. 4  (2)  p. .  	 
\bibitem[Ozaki et al.]{b11}\label{b11} 	 		‘Bandwidthefficient multicast routing for multihop, ad-hoc wireless networks’.  		 			T Ozaki 		,  		 			J B Kim 		,  		 			T Suda 		.  	 	 		\textit{Proceedings of the 20th},  				 (the 20th)  		 	 
\bibitem[Sivakumar et al. ()]{b34}\label{b34} 	 		‘CEDAR: a coreextraction distributed ad hoc routing algorithm’.  		 			R Sivakumar 		,  		 			P Sinha 		,  		 			V Bharghavan 		.  	 	 		\textit{IEEE Journal on Selected Areas in Communications}  		1999. 17  (8)  p. .  	 
\bibitem[Computer Science and Technology Volume XII Issue VI Version I 21 2012 March announcements (PUMA) Proceedings of the IEEE International Conference onMobile Ad-Hoc and Sensor Systems (MASS '04) ()]{b27}\label{b27} 	 		‘Computer Science and Technology Volume XII Issue VI Version I 21 2012 March announcements (PUMA)’.  	 	 		\textit{Proceedings of the IEEE International Conference onMobile Ad-Hoc and Sensor Systems (MASS '04)},  				 (the IEEE International Conference onMobile Ad-Hoc and Sensor Systems (MASS '04))  		2004.  	 
\bibitem[Ballardie et al. ()]{b38}\label{b38} 	 		‘Core based trees (CBT)’.  		 			T Ballardie 		,  		 			P Francis 		,  		 			J Crowcroft 		.  	 	 		\textit{ACM SIGCOMM Computer Communication Review}  		1993. 23 p. .  	 
\bibitem[Ji and Corson ()]{b14}\label{b14} 	 		‘Differential destination multicast MANET multicast routing protocol for small groups’.  		 			L Ji 		,  		 			M S Corson 		.  	 	 		\textit{Proceedings of the 20th Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM'01)},  				 (the 20th Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM'01))  		2001. 2 p. .  	 
\bibitem[Johnson and Maltz (ed.) ()]{b39}\label{b39} 	 		\textit{Dynamic source routing in ad hoc wireless networks},  		 			D B Johnson 		,  		 			D A Maltz 		.  		Mobile Computing, T. Imielinski and H. Korth (ed.)  		1996. 5 p. .  	 
\bibitem[Chen and Nahrstedt ()]{b31}\label{b31} 	 		‘Effective location-guided tree construction algorithms for small group multicast in MANET’.  		 			K Chen 		,  		 			K Nahrstedt 		.  	 	 		\textit{Proceedings of the Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM'02)},  				 (the Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM'02))  		2002. 3 p. .  	 
\bibitem[Gui and Mohapatra ()]{b48}\label{b48} 	 		‘Efficient overlay multicast for mobile ad hoc networks’.  		 			C Gui 		,  		 			P Mohapatra 		.  	 	 		\textit{Proceedings of the IEEE Wireless Communications and Networking Conference (WCNC '03)},  				 (the IEEE Wireless Communications and Networking Conference (WCNC '03))  		2003. 2 p. .  	 
\bibitem[Guo and Yang (2007)]{b2}\label{b2} 	 		‘Energy-aware multicasting in wireless ad-hoc networks: A survey and discussion’.  		 			S Guo 		,  		 			O Yang 		.  	 	 		\textit{Computer Commun}  		June 2007. 30  (9)  p. .  	 
\bibitem[Chiang et al. ()]{b16}\label{b16} 	 		‘Forwarding Group Multicast Protocol (FGMP) for multihop, mobile wireless networks’.  		 			C.-C Chiang 		,  		 			M Gerla 		,  		 			L Zhang 		.  	 	 		\textit{ACM-Baltzer Journal of Cluster Computing}  		1998. 1  (2)  p. .  	 
\bibitem[Sajama and Haas ()]{b17}\label{b17} 	 		‘Independent-tree ad hoc multicast routing (ITAMAR)’.  		 			Z J Sajama 		,  		 			Haas 		.  	 	 		\textit{Mobile Networks and Applications}  		2003. 8  (5)  p. .  	 
\bibitem[Jain and Das ()]{b50}\label{b50} 	 		‘MAC layer multicast in wireless multihop networks’.  		 			S Jain 		,  		 			S R Das 		.  	 	 		\textit{Proceedings of the 1st International Conference on Communication System Software and Middleware (Comsware '06)},  				 (the 1st International Conference on Communication System Software and Middleware (Comsware '06))  		2006. p. .  	 
\bibitem[Prasunsinha and Bharghavan ()]{b18}\label{b18} 	 		‘MCEDAR: multicast core-extraction distributed ad hoc routing’.  		 			R S Prasunsinha 		,  		 			V Bharghavan 		.  	 	 		\textit{Proceedings of the Wireless Communications and Networking Conference},  				 (the Wireless Communications and Networking Conference)  		1999. 3 p. .  	 
\bibitem[Royer and Perkins ()]{b19}\label{b19} 	 		‘Multicast ad hoc on demand distance vector (MAODV) routing’.  		 			E M Royer 		,  		 			C E Perkins 		.  		 draft-ietfdraft-maodv-00.txt.  	 	 		\textit{Internet-Draft}  		2000.  	 
\bibitem[Jacquet et al. ()]{b43}\label{b43} 	 		‘Multicast optimized link state routing’.  		 			P Jacquet 		,  		 			P Minet 		,  		 			A Laouiti 		,  		 			L Viennot 		,  		 			T Clausen 		,  		 			C Adjih 		.  		 draft-ietf-manet-olsr- molsr-01.txt.  	 	 		\textit{Internet Draft}  		2002.  	 
\bibitem[Manvi and Kakkasageri ()]{b41}\label{b41} 	 		‘Multicast routing in mobile ad hoc networks by using a multiagent system’.  		 			S S Manvi 		,  		 			M S Kakkasageri 		.  	 	 		\textit{Information Sciences}  		2008. 178  (6)  p. .  	 
\bibitem[Chen and Wu ()]{b3}\label{b3} 	 		\textit{Multicasting techniques in mobile ad-hoc networks},  		 			X Chen 		,  		 			J Wu 		.  		2003. p. .  	 	 (The Handbook of Ad-hoc Wireless Networks) 
\bibitem[Zhang and Jacob ()]{b21}\label{b21} 	 		‘MZRP: an extension of the zone routing protocol for multicasting in MANETs’.  		 			X Zhang 		,  		 			L Jacob 		.  	 	 		\textit{Journal of Information Science and Engineering}  		2004. 20  (3)  p. .  	 
\bibitem[Lee and Kim ()]{b22}\label{b22} 	 		‘Neighbor supporting ad hoc multicast routing protocol’.  		 			S Lee 		,  		 			C Kim 		.  	 	 		\textit{Proceedings of the ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc '00)},  				 (the ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc '00))  		2000. p. .  	 
\bibitem[Hu et al. ()]{b23}\label{b23} 	 		‘OGHAM: ondemand global hosts for mobile ad-hocmulticast services’.  		 			C.-C Hu 		,  		 			EH 		,  		 			.-K Wu 		,  		 			G.-H Chen 		.  	 	 		\textit{Ad Hoc Networks}  		2006. 4  (6)  p. .  	 
\bibitem[Lee et al. ()]{b24}\label{b24} 	 		‘On-demand multicast routing protocol in multihop wireless mobile networks’.  		 			S.-J Lee 		,  		 			W Su 		,  		 			Gerla 		.  	 	 		\textit{Mobile Networks and Applications}  		2002. 7  (6)  p. .  	 
\bibitem[Stanze and Zitterbart ()]{b49}\label{b49} 	 		‘On-demand overlay multicast in mobile ad hoc networks’.  		 			O Stanze 		,  		 			M Zitterbart 		.  	 	 		\textit{Proceedings of the IEEE Wireless Communications and Networking Conference (WCNC '05)},  				 (the IEEE Wireless Communications and Networking Conference (WCNC '05))  		2005. 4 p. .  	 
\bibitem[Mnaouer et al. ()]{b42}\label{b42} 	 		‘OPHMR: an optimized polymorphic hybrid multicast routing protocol for MANET’.  		 			B Mnaouer 		,  		 			L Chen 		,  		 			C H Foh 		,  		 			J W Tantra 		.  	 	 		\textit{IEEE Transactions on Mobile Computing}  		2007. 6  (5)  p. .  	 
\bibitem[Pompili and Vittucci ()]{b30}\label{b30} 	 		‘PPMA, a probabilistic predictive multicast algorithm for ad hoc networks’.  		 			D Pompili 		,  		 			M Vittucci 		.  	 	 		\textit{Ad Hoc Networks}  		2006. 4  (6)  p. .  	 
\bibitem[Xiong et al. ()]{b37}\label{b37} 	 		‘Preemptive multicast routing in mobile ad-hoc networks’.  		 			X Xiong 		,  		 			U T Nguyen 		,  		 			H L Nguyen 		.  	 	 		\textit{Proceedings of the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies (ICN/ICONS/MCL'06)},  				 (the International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies (ICN/ICONS/MCL'06))  		2006. p. .  	 
\bibitem[Vaishampayan and Garcia-Luna-Aceves ()]{b26}\label{b26} 	 		‘Protocol for unified multicasting through ©’.  		 			R Vaishampayan 		,  		 			J J Garcia-Luna-Aceves 		.  	 	 		\textit{Global Journals Inc}  		2012. US.  	 
\bibitem[Junhai and Danxia (2008)]{b4}\label{b4} 	 		‘Research on routing security in MANET’.  		 			L Junhai 		,  		 			Y Danxia 		.  	 	 		\textit{Application Research of Computers}  		Jan. 2008. 25  (1)  p. .  	 
\bibitem[Deng and Li (2002)]{b0}\label{b0} 	 		‘Routing security in wireless adhoc networks’.  		 			H Deng 		,  		 			W Li 		,  		 			DP 		.  	 	 		\textit{IEEE Commun. Mag}  		Oct. 2002. 40  (10)  p. .  	 
\bibitem[Gui and Mohapatra ()]{b32}\label{b32} 	 		‘Scalable multicasting in mobile ad hoc networks’.  		 			C Gui 		,  		 			P Mohapatra 		.  	 	 		\textit{Proceedings of the Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '04)},  				 (the Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '04))  		2004. 3 p. .  	 
\bibitem[Moustafa and Labiod (2002)]{b28}\label{b28} 	 		‘SRMP: a mesh-based protocol for multicast communication in ad hoc networks’.  		 			H Moustafa 		,  		 			H Labiod 		.  	 	 		\textit{Proceedings of the International Conference on Third Generation Wireless and Beyond 3Gwireless},  				 (the International Conference on Third Generation Wireless and Beyond 3Gwireless)  		May 2002. p. .  	 
\bibitem[Garcia-Luna-Aceves and Madruga ()]{b13}\label{b13} 	 		‘The coreassisted mesh protocol’.  		 			J J Garcia-Luna-Aceves 		,  		 			E L Madruga 		.  	 	 		\textit{IEEE Journal on Selected Areas in Communications}  		1999. 17  (8)  p. .  	 
\bibitem[Haas and Pearlman ()]{b33}\label{b33} 	 		\textit{The Zone Routing Protocol (ZRP) for Ad Hoc Networks," draft-zonerouting-protocol-00.txt},  		 			Z J Haas 		,  		 			M R Pearlman 		.  		1997.  	 
\bibitem[Das et al. ()]{b29}\label{b29} 	 		‘Weight based multicast routing protocol for ad hoc wireless networks’.  		 			S K Das 		,  		 			B S Manoj 		,  		 			C S R Murthy 		.  	 	 		\textit{Proceedings of the IEEE Global Telecommunications Conference (GLOBECOM '02)},  				 (the IEEE Global Telecommunications Conference (GLOBECOM '02))  		2002. 1 p. .  	 
\bibitem[Younis and Ozer (2006)]{b1}\label{b1} 	 		‘Wireless ad-hoc networks: Technologies and challenges’.  		 			M Younis 		,  		 			S Z Ozer 		.  	 	 		\textit{Wireless Commun. Mobile Computing}  		Nov. 2006. 6  (7)  p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
