Accepted Manuscript. DMMS: A Flexible Architecture for Multicast Listener Support in a Distributed Mobility Management Environment

Transcription

1 Accptd Manuscript DMMS: A Flxibl Architctur for Multicast Listnr Support in a Distributd Mobility Managmnt Environmnt Tin-Thinh Nguyn, Christian Bonnt PII: S (15)00448-X DOI: /j.comnt Rfrnc: COMPNW 5759 To appar in: Computr Ntworks Rcivd dat: 4 Fbruary 2015 Rvisd dat: 26 May 2015 Accptd dat: 11 Novmbr 2015 Plas cit this articl as: Tin-Thinh Nguyn, Christian Bonnt, DMMS: A Flxibl Architctur for Multicast Listnr Support in a Distributd Mobility Managmnt Environmnt, Computr Ntworks (2015), doi: /j.comnt This is a PDF fil of an unditd manuscript that has bn accptd for publication. As a srvic to our customrs w ar providing this arly vrsion of th manuscript. Th manuscript will undrgo copyditing, typstting, and rviw of th rsulting proof bfor it is publishd in its final form. Plas not that during th production procss rrors may b discovrd which could affct th contnt, and all lgal disclaimrs that apply to th journal prtain.

2 DMMS: A Flxibl Architctur for Multicast Listnr Support in a Distributd Mobility Managmnt Environmnt Tin-Thinh Nguyn a,1,, Christian Bonnt a Abstract a Dpartmnt of Mobil Communications EURECOM 450 Rout ds Chapps, Biot, Franc Th mobil ntwork oprators ar bing challngd by th xplosion of mobil data traffic in trms of ntwork prformanc and gnratd rvnu. On on hand, fficint mobility managmnt plays a crucial rol to support mobil usrs, howvr, th currnt mobility protocols hav svral major limitations from thir cntralizd and hirarchical natur (.g., sub-optimal routing, scalability and rliability issus). Distributd Mobility Managmnt (DMM) is a nw, vry promising trnd to ovrcom ths limitations by flattning th ntwork architctur and dynamically providing th mobility support. Basd on th fact that th mobil Intrnt traffic will b dominatd by th mobil vido, th scalability and bandwidth fficincy from multicast routing maks th IP multicast plays a crucial rol. Howvr, on of th main challngs for multicast support is th mobility of a multicast nod, lading to svral issus for both multicast srvic and ntwork oprator such as long srvic disruption, high nd-to-nd dlay, non-optimal routing and traffic rplication. Drivn from th fact that diffrnt multicast flows hav vry diffrnt charactristics and ach ntwork oprator has diffrnt policis for multicast support, w propos a dynamic multicast support schm (DMMS), taking into account both th usr and ntwork oprator point of viw. DMMS allows to dynamically provid th appropriat multicast support mod basd on a st of contxts such as th srvic s charactristics, mobility of th nod and ntwork contxt to adapt to th srvic s rquirmnts as wll as oprator s policis. Kywords: IP Multicast, IP Mobility, Ntwork-basd Mobility Managmnt, Distributd Mobility Managmnt, Multicast Listnr Mobility. 1. Introduction Tchnology has now drivn us in th mobil ra in which mobil traffic gnratd by mobil phons has xcdd that from mobil PCs, tablts and mobil routrs. Estimats say that global mobil broadband subscriptions grw by around 30 prcnt yar-on-yar and rachd 2.5 billion in th third quartr of 2014 [1]. Additionally, this trnd dos not show any sign of slowing down. Global mobil broadband subscriptions ar prdictd to rach 8.4 billion by 2020, accounting for mor than 90 prcnt of all mobil subscriptions. Th incrasing numbr Corrsponding author addrsss: tin-thinh.nguyn@urcom.fr (Tin-Thinh Nguyn), christian.bonnt@urcom.fr (Christian Bonnt) 1 Phon numbr: (+33) of subscriptions has bn drivn by a varity of rasons such as th incrasing numbr of mobil dvics which bcom mor and mor powrful and intllignt (spcially, in th low- and mid-rang pric); th nhancmnt of wirlss accss tchnology in trms of covrag, spd and quality; as wll as th xplosion of mobil applications [1, 2, 3]. As a rsult, mobil data traffic will incras around 8 tims btwn 2014 and 2020, to rach 17 xabyts pr month by Howvr, dspit th incrasing volum of traffic, mobil data rvnu pr usr is falling down [4]. On th othr hand, th currnt mobil ntworks ar volving towards all-ip architctur. In this contxt, th mobility natur of th mobil nods (MNs) maks IP mobility managmnt play a crucial rol in th mobil ntwork. In fact, today s mobility managmnt protocols (.g., Mobil IPv6 (MIPv6) and Proxy Mobil IPv6 (PMIPv6)) Prprint submittd to Wirlss Ntwork Novmbr 20, 2015

3 hav svral major limitations from thir cntralizd and hirarchical natur. Cntralizing both th control and data plan functions at th cntral mobility anchor introducs scalability and rliability issus [5, 6]. Also, it lads to sub-optimal paths btwn th MNs and thir corrsponding nods (CNs). Th mobil ntwork oprators ar bing challngd by th xplosion of mobil data traffic (spcially th vido traffic) and th nw rquirmnts.g., providing connctivity anywhr and at any tim with consistncy of usr xprinc, whil prsrving th conomics of thir ntworks and crating nw opportunitis for rvnu growth. Facd with ths challngs, th oprators ar sking for innovativ solutions to improv thir ntwork prformanc and fficincy, as wll as to rduc th costs xpndd on ntwork opration and maintnanc. On possibl solution is to incras th radio capacity of mobil broadband by dploying nw wirlss tchnologis such as Evolvd High Spd Packt Accss (HSPA+), Long Trm Evolution (LTE) and LTE-Advancd (LTE-A). Howvr, th radio spctrum for oprators is both limitd and xpnsiv. Consquntly, th ntwork oprators ar looking at diffrnt mthods to incras th systm capacity such as dploying fmto and pico clls, togthr with simplifying th ntwork architctur as wll as optimizing th data transmission costs. Accordingly, th mobil ntwork topologis ar currntly volving towards a flat architctur. Th Third Gnration Partnrship Projct (3GPP) 2 also proposs such traffic offloading tchniqus as Local IP Accss/Slctd IP Traffic Offload (LIPA/SIPTO) and IP Flow Mobility (IFOM) [7]. Following th sam ida, th Intrnt Enginring Task Forc (IETF) has rcntly chartrd th Distributd Mobility Managmnt (DMM) Working Group 3 which spcifis th solutions to addrss th problms and limitations of th currnt cntralizd mobility managmnt (CMM) such as suboptimal routing, scalability, and rliability issus (th anchor rprsnts a bottlnck and singl point of failur) [5, 6]. On th othr hand, IP multicast is rgardd as a ky tchnology for improving traffic dlivry fficincy whn data is snt to svral rcivrs at th 2 Third Gnration Partnrship Projct, 3 IETF DMM Working Group: 2 sam tim, for xampl, in such aras as multimdia distribution, gaming and softwar updat. Th rason is that IP multicast can provid significant advantags compard to unicast communication rgarding ovrall rsourcs consumption (.g., bandwidth, srvr load and ntwork load) and dploymnt cost to dlivr th traffic [8, 9, 10]. Howvr, aftr mor than a dcad of rsarchs and dvlopmnt fforts, IP multicast dploymnt, in gnral, has bn sluggish on th global Intrnt, mainly du to th practical, scurity and businss concrns [11, 12]. Howvr, th nw businss modls, a hug traffic dmand (spcially multimdia traffic), th rvnu pr data rducing phnomnon in th mobil oprator ntworks, as wll as th advantags of nw multicast modl (Sourc-Spcific Multicast - SSM) bring again th strong intrst of IP multicast from both acadmia and industry [13]. As a rsult, IP multicast is xpctd to play mor important rol in th futur ntworks. Altogthr, to dal with a hug numbr of dvics and traffic, whil DMM is xpctd to b an ffctiv solution in trms of IP mobility managmnt, IP multicast can b considrd as a valuabl solution from srvic point of viw. But on of th major challngs for multicast support is whn mobility is considrd. It is du to th fact that th multicast protocols wr dsignd for fixd ntworks. As a rsult, th intraction btwn th IP multicast and IP mobility protocols raiss svral issus from both multicast srvic and ntwork oprator point of viw such as srvic disruption (and packt loss), routing non-optimization, packt duplication, and wast of ntwork rsourc [9, 12]. Howvr, a rlativly limitd work has bn don considring IP multicast in a ntwork-basd DMM nvironmnt. At this stag, following th DMM concpt, th multicast traffic is routd dirctly from th nativ multicast infrastructur via th currnt accss routr (Mobility Accss Routr or MAR) for th nw flow. For th flow aftr handovr, th multicast traffic is tunnld from th MAR whr th flow is initiatd to th currnt on via th mobility tunnl btwn thm, lik unicast traffic [14, 15]. Thus, th MAR whr th flow is initiatd plays th rol of th multicast mobility anchor (MMA) which is a logical ntity from whr th MN rcivs th ongoing multicast flow whil on th mov; and is idntical with th unicast mobility anchor. Th multicast flow will b anchord at th initially assignd MMA during its liftim. Thrfor, vn whn th MN movs far away from its

4 anchor, th multicast traffic still travrss th anchor. As a rsult, it not only causs svral issus to th ongoing multicast flow such as srvic disruption and nd-to-nd dlay, but also lads to th non-optimal routing and tunnl convrgnc problm. Ths problms bcom srious whn considring th intrruption- and dlay-snsitiv srvics. Bsids, to addrss th tunnl convrgnc and nonoptimal routing problm, th MAR can obtain th multicast traffic of th ongoing flow dirctly from its upstram MR. Howvr, it may caus a significant srvic disruption du to th tim ndd to join th multicast dlivry tr and dlivr th traffic to th currnt MAR [16]. In addition, th distribution of mobility anchors will not hlp to balanc th traffic btwn thm [17]. On th othr hand, th oprator may do not want to dploy th tunnl btwn th accss routrs, or in som situations, dsirs applying a spcific policy for a particular multicast channl. Altogthr, a multicast support mod may not b always good rgarding diffrnt rquirmnts. That is th rason why a flxibl mannr to support multicast mobility in DMM should b providd. In this documnt w propos a solution, namly Dynamic Multicast Mobility Support - DMMS, which allows to provid a suitabl multicast support mchanism in DMM from both usr and ntwork oprator point of viw. Th multicast support schm can b providd in a flxibl mannr basd on th collctd contxts to mt a st of rquirmnts. From usr prspctiv, it hlps satisfy th rquirmnts in trms of srvic disruption and dlay, spcially whn considring ral-tim srvics. From ntwork oprator prspctiv, it provids a mchanism to bttr distribut th load among th ntwork ntitis and sav ntwork rsourc by prvnting th packt duplication and shortning th lav latncy. This mchanism not only taks into account th multicast srvic contxt (.g., intrruption- and dlay-snsitiv srvics) but also th mobil nod s mobility and th ntwork contxt (such as th load of MARs and th multicast channl policy), thus nabling a pr-flow multicast support. DMMS prformanc was thn validatd not only by th numrical rsults, but also via a proof-of-concpt with prliminary rsults. Th rst of this documnt is organizd as follows. Sction 2 introducs background information rlatd to IP mobility managmnt, th issus and diffrnt approachs for th multicast support in DMM. A dtaild dscription of DMMS is givn in Sction 3, whil Sction 4 prsnts th prformanc analysis rgarding diffrnt mtrics as srvic disruption, nd-to-nd dlay, signaling cost and packt loss. Th numrical rsults ar givn in Sction 5, whil Sction 6 shows th currnt status of th implmntation and th prliminary rsults. Sction 7 discusss th scnario in which th multicast routr is dployd at th accss routr and th multicast sourc mobility support. Finally, Sction 8 concluds this documnt. 2. Rlatd Work 2.1. IP Mobility Managmnt Cntralizd Mobility Managmnt Today s mobility managmnt protocols rly on a cntral ntity such as Hom Agnt (HA) in Mobil IPv6 (MIPv6) [18], and Local Mobility Anchor (LMA) in Proxy Mobil IPv6 (PMIPv6) [19] to maintain th mobil nod s rachability whn it is away from hom. In MIPv6, it is don by using a tunnling mchanism btwn th HA and th MN for rdircting packts from/to th currnt location of th MN. Howvr, as a host-basd protocol, an additional componnt is rquird at th MN to prform th th mobility-rlatd signaling. Th additional componnt is considrd as th main obstacl for th dploymnt of MIPv6 in rality. For this rason, PMIPv6 has bn introducd as a ntworkbasd protocol. PMIPv6 introducs a nw ntity calld MAG to prform mobility rlatd signalling on bhalf of MNs. Accordingly, MN s traffic is always ncapsulatd and tunnlld btwn th LMA and th corrsponding MAG. Additionally, whil moving insid a PMIPv6 domain, th MN rmains its IPv6 addrss. Consquntly, th MN can b kpt simpl and is unawar of mobility as wll. In othr words, mobility can b transparntly providd to all lgacy dvics. On th othr hand, MIPv6 and PMIPv6 ar two typical xampls of th currnt mobility managmnt protocols which hav svral major limitations from thir cntralizd and hirarchical natur. Cntralizing both th control and data plan functions at th cntral mobility anchor introducs scalability and rliability issus (th cntral ntity rprsnts a bottlnck and singl point of failur) [5]. Cntralizd approach also suffrs from triangl routing problm. Thrfor, it affcts ntwork prformanc in trms of routing fficincy and ndto-nd dlay transmission [5]. 3

5 To addrss th limitations of th currnt mobility managmnt protocols, Distributd Mobility Managmnt (DMM) solutions hav bn proposd [5]. Th ky concpt of DMM is that instad of having a cntralizd mobility anchor, th mobility anchors ar distributd among ntwork ntitis and placd as clos as possibl to th MN.g., at th routr dg of th accss ntwork. In othr words, th MAR whr a flow is initiatd plays th rol of th mobility anchor for this flow. DMM also offrs dynamic mobility faturs (pr prfix granularity). As DMM is prsntly an activ topic, th prformanc valuation of DMM has bn xtnsivly analysd using diffrnt approachs and ntwork mtrics [6, 14]. Th rsults from ths analysis showd that DMM hlps to sav th rsourcs in th ntwork sinc th mobility support is nabld whn it is ncssary and th traffic is bttr distributd among th ntwork ntitis, thus improving th scalability and rliability of th ntwork. Among th proposals, th ntwork-basd solution proposd in [20] appars to b th most promising schm Ntwork-basd Distributd Mobility Managmnt This papr follows th concpt of th ntworkbasd DMM [20] proposd by th IETF DMM Working Group. Th cntral ntity, namly Cntral Mobility Databas (CMD), still xist but for th control plan only. Th CMD stors th information of mobility sssions of all mobil nods in th domain. Th bas ntity, Mobility Accss Routr (MAR), basically ncompasss th functionality of a plain accss routr, an MAG, and an LMA. In a DMM domain, ach MAR owns a pool of IPv6 prfix. An MN obtains diffrnt prfixs whn it changs its attachmnt points (MARs). In cas of mobility, th MN s flows ar anchord (if ncssary) at th MAR in which its prfix in us is allocatd (calld anchor MAR or amar). Hnc, th packts can b rdirctd via th mobility tunnl from th anchor to th currnt MAR (cmar). Fig. 1 rprsnts an xampl of how DMM works. Onc th MN ntrs a DMM domain (attachs to MAR1), it configurs an IPv6 addrss (prf1::mn1/64) basd on th prfix allocatd at th currnt MAR (prf1::/64) and can us its addrss to initiat a flow with a CN (say flow1). Flow1 is routd in a standard routing mannr without any tunnling mchanism. Aftr moving to MAR2, th MN can start a nw flow (say flow2) using th MAR1 4 CN1 MN CMD MAR2 CN2 MN Figur 1: DMM architctur. MAR3 MN nw allocatd prfix (prf2::/64). If flow1 is kpt aliv, it will b rdirctd via th mobility tunnl btwn MAR1 and MAR2. Th tunnl stablishmnt is don thanks to th coordination btwn CMD, MAR1, and MAR2. Similarly, whn th MN movs to MAR3, flow1 and flow2 ar anchord at MAR1 and MAR2, rspctivly. From flow1 point of viw, MAR1, MAR2, and MAR3 ar th anchor (amar), th prvious (pmar) and th currnt MAR (cmar), rspctivly. For flow2, MAR2 is both th anchor and th prvious MAR IP Multicast Mobility: From Cntralizd to Distributd Mobility Managmnt As th multicast protocols (including th group managmnt and routing protocols) ar originally dsignd for a fixd ntwork, considring a multicast nod in a mobil nvironmnt brings svral challngs to both th multicast srvic and th ntwork oprator. Th mobility of th multicast nod has diffrnt impacts on th multicast srvic upon such factors as: i) th rol of th nod in th multicast sssion (sourc or listnr); ii) th considrd multicast modl (Any-Sourc Multicast (ASM) or Sourc-Spcific Multicast (SSM)); iii) th multicast routing and multicast group managmnt protocols in us; iv) th mobility managmnt protocol; and v) th wirlss accss tchnology [14]. Accordingly, th mobility-rlatd issus can b dividd into 4 main groups as th gnral multicast problms (du to multicast protocols), th spcific mobil listnr problms, th spcific mobil sourc problms and th dploymnt issus [9, 12, 21]. In th contxt of this documnt, w focus on th issus causd by th mobility of a multicast listnr

6 MN MAR CMD Addrss configuration Attachmnt vnt Routr Solicitation Routr Advrtismnt MLD proxy configuration MN attachs to MAR Prfix allocation PBU PBA MN joins a multicast flow MLD Rport Figur 2: Initial oprations. Updat BCE Multicast Infrastructur including long srvic disruption and high numbr of lost packts, packt duplication (or tunnl convrgnc problm), sub-optimal routing, high ndto-nd dlay, and wast of ntwork rsourc [9, 12] Multicast Listnr Mobility in a Ntworkbasd DMM Paradigm Sinc DMM is still in th prliminary stag of standardization, thr is no complt solution for multicast in plac. Typically, all major aspcts for multicast support in a ntwork-basd DMM nvironmnt ar inhritd from that in PMIPv6, whil an additional complxity is addd [16]. Compard to PMIPv6, DMM introducs also two basic scnarios to nabl multicast rgarding th multicast functionality dployd at th MAR i.., multicast routr (MR) and Multicast Listnr Discovry (MLD) Proxy [15]. Howvr, th oprators may not want to support th multicast routing function at th MAR du to its implmntation and oprational costs. Thrfor, this papr assums that th MAR and MLD Proxy ar co-locatd (th scnario in which MAR acts as a multicast routr is brifly discussd in Sction 7). Also, only multicast listnr mobility in th ntwork-basd DMM is furthr studid. In ntwork-basd DMM, whn a multicast flow is initiatd, th traffic is routd dirctly from th multicast infrastructur via th currnt MAR. In cas of handovr, th traffic is routd from th anchor to th currnt MAR via th mobility tunnl btwn thm, just lik unicast traffic. Th oprations in dtails ar illustratd in Fig. 2 and dscribd as follows. Aftr dtcting th prsnc of a nw mobil nod by mans of a Routr Solicitation (RS) mssag, th currnt MAR allocats a prfix for th MN (.g., prf1::/64). According to th normal DMM bhavior, a Proxy Binding Updat (PBU) including th allocatd prfix is snt to th CMD for th prfix 5 rgistration. Upon rciving th PBU, th CMD crats a binding cach ntry (BCE) for this MN and rplis by a Proxy Binding Acknowldgmnt (PBA) mssag. Th MAR thn unicasts a Routr Advrtismnt (RA) including th allocatd prfix to th MN. In paralll, th MLD Proxy instanc at MAR adds th MN to its downstram intrfac, and configurs its upstram intrfac towards its dfault upstram MR. Th MN, aftr configuring its IPv6 addrss (prf1::mn1/64), can join a multicast flow via th currnt MAR by mans of an MLD Rport. As a rsult, th currnt MAR rcivs th multicast packts from th nativ multicast infrastructur and forwards thm to th MN. It is notd that instad of using RS/RA mssag, anothr mchanism can b usd to allow th MN obtain an IPv6 addrss.g, by using Dynamic Host Configuration Protocol (DHCPv6). In this cas, th DHCP Rqust and DHCP Rply mssags will play th rol of RS and RA, rspctivly. In cas of handovr (s Fig. 3), following th standard DMM oprations, th MLD Proxy instanc at th cmar adds th MN to its downstram intrfac, and configurs its upstram intrfac towards th amar. Th cmar, aftr obtaining th MN s subscription information by mans of th normal MLD opration, snds an aggrgatd MLD Rport to th amar to join th ongoing flows. Finally, th multicast traffic is transmittd from amar to cmar via th mobility tunnl btwn thm and rachs th MN. This approach is similar to th bas dploymnt for multicast listnr support in PMIPv6 [22]. In this papr, it is calld th dfault multicast support mod (DF) [15, 23, 24]. Howvr, this mod dos not addrss any multicastrlatd issus causd by th movmnt of listnr such as long srvic disruption (and high numbr of packt losss), non-optimal routing, high nd-tond dlay, and tunnl convrgnc problm. For mor dtails, whn a listnr movs to a nw MAR (cmar), it may caus a noticabl disruption for th ongoing flows du to multicast subscription acquisition tim (basd on th normal MLD Qury/Rport mchanism). It is about 5 sconds in th normal cas, and 1 scond in th bst cas [25]. This dlay is much longr than th maximum tolratd tim for normal srvics, as spcifid in [26] is 500 ms. As a rsult, for a intrruption snsitiv flow, th multicast contxt transfr [27, 28] may

7 MN pmar cmar amar CMD Attachmnt vnt Routr Solicitation MN prforms a handovr from pmar to cmar PBU Multicast Infrastructur Addrss configuration Routr Advrtismnt MLD proxy configuration Rtriving th multicast subscription information Updat BCE PBA Dfault multicast mod (DF) Dirct multicast mod (DR) PBA MLD Rport Updat BCE Figur 3: Multicast mobility support in th dfault and dirct mod (with and without contxt transfr). b rquird to avoid a larg dlay. Howvr, vn with th multicast contxt transfr, it is difficult to mt th rquirmnt in trms of srvic disruption for th intrruption-snsitiv srvic whn th dlay btwn th anchor and th currnt MAR is larg [16, 29]. It is bcaus th multicast traffic has to pass through th amar, which plays th rol of multicast mobility anchor (MMA). Also, th traffic follows a non-optimal path via th amar. In particular, whn considring a larg domain, it can caus a high nd-to-nd dlay. This issu bcoms srious in cas of nd-to-nd dlay snsitiv srvic. Also, sinc th listnr is unawar of mobility, it will not snd an MLD rport for xplicitly laving th group in th prvious MAR. As a rsult, if th last mmbr of a multicast group movs to anothr MAR, th prvious on will continu to dlivr th multicast traffic until it updats its mmbrship information. Thus, it causs wast of ntwork rsourc. Using th xplicit tracking function and th contxt transfr, in this cas, could hlp. 6 On th othr hand, th mobility of th nod may rsult in th tunnl convrgnc problm (or packt duplication). It occurs whn multipl instancs of th sam multicast packts convrg to an MAR (from diffrnt MARs via th mobility tunnl btwn thm), lading to duplicatd multicast packts. Sinc th purpos of DMM is moving th mobility anchors from th cor to th dg of th ntworks, th numbr of mobility anchors (th mobility tunnl as wll) in a DMM domain will b much mor than that in a PMIPv6 domain. As a consqunc, th tunnl convrgnc problm is supposd to b much mor svr than that in PMIPv6. To avoid th tunnl convrgnc problm, th cmar can obtain th multicast traffic of th ongoing flow dirctly from its upstram MR (thus using th nativ multicast infrastructur for dlivring th traffic, as similar as in [30]). This mod is calld dirct routing (DR). It also allows th multicast traffic to b routd in a bttr mannr. Howvr, although it is th simplst way to support multicast in DMM, it may caus a significant srvic disruption du to th tim ndd to join th multicast dlivry tr and dlivr th traffic to th currnt MAR [16]. Our prvious work in [16] argud th nd for a dynamic multicast mobility anchor slction to adapt to th srvic s rquirmnts as wll as oprator s policy. This articl laborats th ida proposd in [16] with a full functionality of th systm. Also, th prformanc comparison btwn our proposal and th DF and DR mods (with and without th multicast contxt transfr) is conductd.

8 3. Dynamic Multicast Mobility Support This sction proposs a solution, namly dynamic multicast mobility anchor support (DMMS), which provids a suitabl multicast support mods in DMM in a flxibl mannr dpnding on diffrnt contxts. Our mthod dcids dynamically from which MAR th multicast traffic should b rtrivd basd on diffrnt mobility scnarios (with or without using mobility tunnl). DMMS aims at addrssing th issus causd by th mobility of th listnr as dscribd in th prvious sction from both th srvic and th ntwork oprator point of viw. In this sction, w first highlight how th solution rflct th considrd contxts and its bnfits. W thn prsnt in mor dtails th architctur as wll as th oprations of th proposd solution Considrd Contxt To provid multicast support mod in a flxibl mannr, diffrnt contxts ar takn into account including th multicast srvic contxt, th nod s mobility contxt, and th ntwork contxt. Thn upon ths contxts, an appropriat bhavior should b followd. Th multicast srvic contxt rfrs to th srvic s rquirmnt in trms of srvic disruption, nd-to-nd dlay, packt loss, and its fatur (.g., long-livd, short-livd). If th multicast srvic dos not rquir any rquirmnts in trm of srvic disruption, and nd-to-nd dlay; th simplst support mod such as DR and DF should b usd. On th othr hand, whn srvics ar snsitiv to intrruption or packt loss, th srvic disruption tim should b minimizd. For instanc, it should b lss than 300ms for a ral-tim srvic, whil 500ms for a normal on [26]. For th nd-to-nd dlay-snsitiv srvic, th long mobility tunnl, which can rsult in a high nd-to-nd dlay, should b avoidd. ITU-T Rcommndation G.114 [31] suggsts that if on-way transmission tim for connction dlays can b kpt blow 150ms, most applications will xprinc a transparnt intractivity. If th on-going flow is long-livd, th MN may prform many handovrs and mov far away from its anchor during th flow s liftim, thus affcting th srvic disruption and nd-to-nd dlay. In trms of mobility contxt, a mobil nod with high mobility prforms frqunt handovrs. In this cas, almost all ongoing multicast flows ar th handovr ons. If th multicast traffic is always routd through th amar utilizing th mobility tunnl (DF mod), th longr flow s liftim is, th mor srious th impact will b. Also, th numbr of anchors and tunnls may b incrasd. On th contrary, for th low mobility nod, th MN is xpctd to stay at on or svral MARs most of th tim. It is notd that th mobility faturs can b dfind basd on th avrag numbr of handovrs pr unit of tim. Bsids, svral ntwork contxts such as currnt load of th MARs, gographical proximity of th MAR to th MN as wll as th multicast channl policy 4 also ar considrd. For xampl, whn th load of MAR is high, it may caus a long dlay and a high numbr of packt losss if it srvs as th MMA. In this cas, th last loadd MAR (for xampl, among th MARs having th multicast forwarding stat for this channl) can b a potntial candidat. Th rason lis in th fact that if th channl is alrady availabl at th slctd MAR, th srvic disruption tim can b minimizd (no nd xtra tim to join th multicast channl). Also, with a ngligibl incras of load, this MAR can forward th traffic to th cmar [8] Bnfits of th Solution Th proposd architctur is dsignd from both usr and ntwork oprator prspctivs, thus it can offr such bnfits as: A complt solution for all th major issus rlatd to multicast listnr mobility including srvic disruption, tunnl convrgnc problm, ntwork rsourc wast (du to lav latncy), sub-optimal routing, and packt loss; A pr-flow multicast support: dpnding on th contxts, ach multicast flow can b tratd diffrntly; Rout optimization: th multicast flows will b routd in a bttr rout sinc thy do not always pass through thir mobility anchor; Tunnl convrgnc problm avoidanc: by using an xtnsion to MLD proxy to support multipl upstram intrfacs [32], th tunnl convrgnc problm can b avoidd. In this cas, only on proxy instanc will b dployd at 7 4 Th ntwork oprator can dfin th channl policy in which som channls should b rcivd dirctly from th nativ multicast infrastructur (to gain bnfit from local contnt) whil th othrs from thir anchor MAR [23]

9 MAR with its upstram intrfacs bing configurd towards diffrnt amars and its upstram MR. Accordingly, th MAR will rciv only on instanc of th multicast packt; Dynamic utilization of mobility tunnl: th utilization of mobility tunnl for th ongoing multicast flows is nabld in appropriat cass.g., for rmot contnt, or for a flow with strict dlay rquirmnts; Effctiv tunnl managmnt: in a DMM nvironmnt, it is infasibl to pr-stablish all th tunnls btwn MARs sinc th numbr of MARs is supposd to b larg. Also, by nabling th multipl upstram intrfacs in DMM, it may caus th complx tunnl managmnt (.g., maintnanc of th tunnl and kp aliv signaling). Thus, th proposd solution, which is basd on a combination btwn th multicast and unicast mobility managmnt modul, can hlp to solv this issu; load distribution: sinc th mod slction taks th currnt load of th MARs into account, it hlps bttr distribut th multicast traffic load among MARs; Cntralizd channl managmnt: th cntral ntity (Multicast Control Entity, or MCE) collcts and manags th considrd contxts (.g., th multicast channls and thir scop (local or rmot), thus nhancing th control of ntwork providrs. In addition, DMMS can also b applid in cas of sourc mobility and is compatibl with th unicast mobility Architctur of DMMS In ordr to collct and manag th considrd contxts, a logical ntity, calld Multicast Control Entity (MCE), is introducd. This ntity can b collocatd with th CMD to bcom Multicast Mobility Controllr (MMC). This ntity, bsid playing th rol of a mobility databas as in a normal DMM, can act as a cntral ntity for managing multicast channl in th domain. It thrfor stors such multicast-rlatd information as srvic contxt (.g., basd on QoS class), nod s mobility contxt, ntwork policy configuration as wll as currnt load of th mobility accss routr. Rsiding in th MAR, th multicast mobility managmnt modul (MUMO) taks rsponsibility for all actions rlatd to th multicast mobility. Th structur of this modul is dpictd in Fig. 4 and brifly dscribd as follows: Th multicast group managmnt modul (MGM) rfrs to th multicast group managmnt oprations and information storag, which is dvlopd basd on th MLD proxy with multipl upstram intrfacs 5. This modul also supports th multicast xplicit tracking function in ordr to kp a pr-host multicast mmbrship stat [33] thanks to its databas. Bsids, it holds a countr structur for th numbr of listnrs pr IP multicast channl, allowing it to idntify whn a nod is th last subscribr of a group. Th multicast contxt managmnt and dcision making modul (CMDM) collcts and manags th considrd contxt including th channl policy, srvic contxt and th mobility contxt. Basd on th collctd contxt, it dcids th suitabl mod among th candidats. Th CMDM thn indicats th MGM to configurs an appropriat upstram intrfacs and join th corrsponding MMA. Th multicast contxt transfr modul (MCT) is in charg of xchanging th MN s multicast subscription information btwn MARs. So that th nw MAR can join th on-going flows in advanc to minimiz th srvic disruption. Th IP mobility managmnt modul (I3M) rsmbls th mobility protocol stack (DMM). It is rsponsibl for dtcting MN s attachmnt, assigning and maintaining th IP connctivity of an MN roaming insid th DMM domain. In othr words, it is rsponsibl for all th mobility managmnt-rlatd actions Oprations of DMMS Fig. 4 and Fig. 5 rprsnt th componnts as wll as oprations of th proposd solution. It is notd that ths figurs mainly focus on th multicastrlatd oprations. Basically, our solution introducs two lvls of intllignc. First, th MMC, for xampl, basd on th ntwork policy, can forc th MAR to follow a spcific multicast support mod. 8 5 It is notd that in cas of MAR acting as a multicast routr, this modul is rlid on th multicast routr function.g., MRDv6.

10 Multicast Control Entity (MCE) 18 PBU/PBA Procss Modul 11 BCE + Mobility Contxt 5 2 MMA 7 MUMO@MAR Routing Filtr 6 Traffic Forwarding 10 D 8 9 Multicast Contxt Managmnt and Dcision Making (CMDM) 3 4 Multicast Group Managmnt Modul (MGM) Databas Mobil Nod Multicast Contxt Transfr Modul (MCT) PBU/PBA Procss Modul MN Dtction Modul 1 13 BCE Modul IP Mobility Managmnt Modul (I3M) MCT 14 MGM Databas Figur 4: Multicast mobility managmnt modul (MUMO) in th MAR and th multicast-rlatd oprations. Bsids, MMC can also provid additional information to th MAR (MUMO) which thn can dcid th most suitabl support mod to follow. Th dtaild oprations ar dscribd as follows. Whn an MN attachs to a nw MAR, at first, th typical DMM oprations ar xcutd to updat th MN s location and configur its addrss (prf1::mn/64) as spcifid in th prvious sction (stp 1, 2 ). In paralll, MGM modul at MAR adds th MN to its downstram intrfac. Th MN thn can join a multicast flow via th currnt MAR by mans of an MLD Rport ( 3 ). If th MGM had th multicast information of th rqustd flow (in othr words, th MGM alrady subscribd to th rqustd flow), it simply forwards this flow to th MN ( 9, 10 ). Othrwis, th MGM triggrs th channl configuration acquisition procdur at th MMC by th CMDM modul ( 4, 5 ). Th CMDM, basd on th acquisition information, dcids and rturns th appropriat multicast support mod to th MGM. Th MGM, acting as an MLD Proxy, snds an MLD Rport to th corrsponding MMA to join th flow on bhalf of th MN ( 6 ). Aftr rciving th multicast packts from th MMA, th MAR forwards thm to th corrsponding intrfac to snd to th MN ( 7, 8 9, 10 ). In cas of handovr to a nw MAR (nmar), similarly, th I3M at th nmar allocats a nw prfix for this MN (.g., prf2::/64). It thn snds a 9 PBU to th MMC for th nw prfix rgistration ( 2 ). By looking up th BCE tabl, th MMC updats th ntry corrsponding to th MN with its nw prfix and location. It is notd that th BCE is xtndd to stor th mobility charactristic of th MN (for xampl, with 3 diffrnt lvls including low, mdium, and high mobility) (11 ). Th mobility fatur, th list of anchor MARs addrss, th corrsponding prfixs, and th addrss of th prvious MAR ar thn convyd in th PBA mssag snt to th I3M at th cmar ( 2 ). Th MMC also notifis th anchor MARs th currnt location of th MN via a PBA mssag. Th mobility tunnl is thn stablishd btwn cmar and ach amar to rdirct th on-going unicast traffic dstind to th MN s activ prfixs (.g., prf1::/64). Th I3M thn unicasts a RA including th nw prfix (prf2::/64) to th MN ( 1 ). Basd on this prfix, th MN can configur a nw IPv6 addrss (prf2::mn/64) whil kping using th old on for th ongoing flows. Th I3M also updats its BCE and triggrs th MCT to prform th contxt transfr (CXT Rqust/Rspons) xchangd with th pmar (12, 13 ) to obtain th MN s subscription information. It is notd that th pmar rtrivs th MN s subscription information from its databas thanks to th xplicit tracking function (14 ). MCT thn updats ths informations in th databas (15 ) and snds thm to th CMDM

11 for th dcision making (16 ). In paralll, I3M snds th mobility faturs and triggrs th CMDM to gt th multicast channl configuration from th MMC (17, 5 ). Again, basd on th channl configuration, th mobility contxt as wll as th multicast srvic contxt, th CMDM dcids to slct th most appropriat support schm. Th CMDM thn snds a join rqust to th MGM including th multicast group and th corrsponding MMA addrss. MGM, aftr joining and gtting th multicast packt for th corrsponding flow, forwards thm to th MN. In addition, if th cmar dos not gt th traffic from th pmar, it will rqust th pmar to stop forwarding th flow (if th MN is th last mmbr of th channl at th pmar) to lowr th lav latncy, thus rducing th wast of rsourc. For a handovr flow, th multicast traffic can b rcivd from th amar, th pmar, th cmar, a common MMA (COMMA) which srvs as only on MMA for th domain (as similar in [30]) or vn an MAR in which th multicast channl is alrady availabl, or a lss loadd MAR so as to mt a st of rquirmnts. At this stag, w considr only 4 candidats including th cmar, pmar, amar, and COMMA corrsponding to diffrnt multicast support mods: MMA(a) - similar to th dfault mod, th multicast traffic is routd from th anchor to th currnt MAR via th mobility tunnl btwn thm; MMA(p) - similar to MMA(a), howvr, th traffic is rcivd from th prvious MAR instad of amar; MMA(c) - using th nativ multicast infrastructur for dlivring multicast traffic (without using mobility tunnling); and MMA(co) - th traffic is rcivd from a common multicast routr in th domain. To rduc th complxity and th signaling cost for th contxt collction procss, th MMC can stor th MN s subscription information, howvr, only for th privilgd usrs and th channls with strict rquirmnt in trms of srvic disruption and nd-to-nd dlay. For thos channls, th mod dcision will b mad by th MMC whil for th normal ons, it is don by th MUMO at th cmar. As a rsult, for th channls with th strict rquirmnt, th corrsponding MMAs will b convyd via th xtndd PBA from MMC to th cmar. Accordingly, th tim for th multicast contxt xchangd as wll as th channl configuration acquisition can b ignord. In addition, DMMS can work in a simpl mod (SIMP) as DF and DR. It is don by adding an option, namly multicast mod (MM) to th PBA snt from MMC to cmar (stp 2 as in Fig. 4) to indicat th multicast mod that cmar should follow. For xampl, th valu 0 indicats that th normal MMA oprations should b xcutd. On th othr hand, th valu 1 shows that th dfault mod without contxt transfr (DF-C) should b applid. That mans th contxt transfr and channl configuration acquisition procsss should not b activatd. Consquntly, th cmar simply joins th ongoing flow from th amar via th mobility tunnl. Similar procdur happns for othr approachs including DF with contxt transfr (DF- C, MM=2), DR (MM=3), and DR-C (MM=4). 4. Prformanc Analysis In wirlss mobil ntworks, th mobility anchor is rsponsibl for tracking th location of th mobil nod to provid th mobility support. Thus, location managmnt is crucial for th ffctiv opration of wirlss ntworks. In this contxt, th signaling cost is dfind as th cost to updat th location of th nod which can b considrd as a function of diffrnt mtrics as th hop distanc btwn th ntitis, th unit transmission cost ovr wird/wirlss link, and th handovr rats. Signaling cost is an important factor sinc it influncs th scalability of th systm as wll as th cost for data dlivry. This mtric bcoms vn mor critical with th prsnc of wirlss links whos hav a limitd capacity. As th data and control plan ar no longr coupld, in cas whr a hug amount of traffic is gnratd in th ntwork, th packt dlivry cost and th tunnling cost could play a vry important rol. On th othr hand, from an application point of viw, srvic disruption, nd-to-nd dlay, and numbr of packt losss ar th most important mtrics. Th srvic disruption tim is dfind as a priod whn a nod cannot rciv/snd th packts whil prforming a handovr. During this priod, th packts will b lost. Thus, it may rsult in noticabl srvic disruption, spcially in cas 10 of intrruption snsitiv applications lik vido and Voic ovr IP (VoIP). Th numbr of lost packts typically is proportional to th srvic disruption, packt arrival rat, ntwork condition, tc. Howvr, sinc this papr focuss on th impact of mobility to th prformanc mtrics, thus, only two main factors ar considrd i.., srvic disruption and packt arrival rat. In IPv6-basd ntworks,

12 MN pmar cmar amar MMC MMA Ongoing multicast flow MN dtachd MN attachd Routr Solicitation PBU Ongoing multicast flow Multicast Infrastructur Updat BCE Routr Advrtismnt CXT Rqust CXT Rspons [srvic contxt] Lav Rqust Support mod dcision MLD proxy configuration PBA [MN s mobility contxt] Updat BCE MLD Rport PBA Channl Conf Rqust Channl Conf Rspons MLD Rport (lav) Join Figur 5: Multicast-rlatd handovr signaling with th multicast contxt transfr. QoS may b dfind by packt loss, handovr latncy and signaling ovrhad. As a rsult, a long srvic disruption tim and a larg numbr of lost packts may dgrad th quality of srvic. Bsids, nd-to-nd dlay is also on important mtric, spcially in cas of dlay-snsitiv srvic. Accordingly, this sction prsnts th prformanc analysis of th proposd solution in comparison with diffrnt approachs (DF, DF-C, DR, and DR-C) rgarding diffrnt mtrics as multicast srvic disruption, nd-to-nd dlay, signaling cost, packt dlivry cost, tunnling cost and packt loss. At this stag, whn a listnr subscribs to a nw multicast flow, this flow will b rcivd dirctly from th nativ multicast infrastructur. This mans th mod slction in th initial phas will b lft for futur works. For a handovr flow, th traffic can b rcivd from th amar, th pmar, th cmar, a common MMA (COMMA), corrsponding to 4 diffrnt mods: MMA(a), MMA(p), MMA(c), and MMA(co). W also do not considr th ntwork oprator s policis. It is notd that COMMA gnrally rflcts th multicast dploymnt in PMIPv Rfrnc Modl Fig. 6 shows a rfrnc topology for th prformanc analysis. Th hop-count distancs btwn th ntitis ar dfind as follows: h ac : th avrag numbr of hops btwn th amar and th cmar. 11 amar h sa S hsp hsm COMMA /MMC hcd h ap pmar h pc cmar MN h ac hsc h mi h ml Figur 6: Rfrnc ntwork topology. IMR h ap : th avrag numbr of hops btwn th amar and th pmar. h pc : th avrag numbr of hops btwn th pmar and th cmar. h cd : th avrag numbr of hops btwn th MAR and th MMC/COMMA. h sa, h sp, h sc, h sm : th avrag numbr of hops btwn th sourc S and th amar, th pmar, th cmar, th COMMA, rspctivly. h mi : th avrag numbr of hops btwn th cmar and th intrsction MR (IMR) which alrady has a multicast forwarding stat for th group. In th contxt of this documnt, h mi rprsnts th popularity of usrs subscribing to th sam flow.

13 It is notd that th avrag numbr of hops btwn th MAR and th listnr (wirlss link) and btwn th MAR and its upstram MR ar assumd to b on Analytical Modling Multicast Srvic Disruption Tim Analysis Th multicast srvic disruption tim (SD (.) ) is dfind as a priod whn a listnr is unabl to rciv th multicast packts. Assuming that th dlay associatd with th procssing of th mssags in th ntwork ntitis (.g., tim for PBU/PBA procssing and updating binding cach in MAR) is includd in th total valu of ach variabl. Thn SD (.) in th proposd solution is xprssd as: SD (.) MMA = TL2 + TRA RS + TMMC + TCXT + T Conf + T (.) M, (1) whr T L2 is th layr 2 (L2) handovr duration, T RA RS is th tim for RS/RA xchangd btwn MAR and MN, T MMC is th tim ndd to gt th addrss of th anchor/prvious MARs from th MMC and updat th currnt location of th MN (at th amar), T CXT is th tim for th contxt transfr mssags xchangd, T Conf is th tim to gt th multicast configuration information from th MMC, T (.) M is th tim ndd for th cmar to join, gt th first multicast packt and dlivr it to th MN aftr handovr. Although diffrnt signaling mssags hav diffrnt sizs, w assum that thy hav th sam siz for simplicity. Also, th dlay for transmitting a signaling mssag is supposd to b proportional to th distanc btwn th sourc and th dstination. Th proportion is τ for wird and κ for wirlss link. As a rsult, T RA RS, T MMC, T CXT, and T Conf ar givn by: T RA RS = 2κ, T MMC = 2τh cd, T CXT = 2τh pc, T Conf = 2τh cd. Rgarding T (.) M, in cas of MMA(c), th cmar has to gt th multicast traffic from th IMR which alrady has a multicast forwarding stat for this group. Thus, whr ω is th dlay tim in which an MR (and an MLD proxy) nds to join a multicast flow at ach routr (proxy) in th intrnt [34]. In cas of MMA(p), th pmar alrady had th multicast stat for this flow. W hav: T p M = 2ω + 2τh pc + κ. In cas of MMA(a), th amar may nd to rjoin th multicast channl, lading to an xtra dlay. It happns, for xampl, in cas th multicast traffic was rcivd from th multicast infrastructur in th pmar and th amar has lft th channl as a rsult of using MLD proxy with multipl upstram intrfacs (calld worst-cas scnario, or wc). Lt p a dnot th probability that this situation happns. As a rsult, T (.) is calculatd as: M TM a = (1 p a )T DF + p a T a wc M M, whr TM DF is th tim th cmar nds to gt th multicast packt from th amar, as similar to in th dfault mod (DF). W hav: T a wc T DF M = 2ω + 2τh ac + κ, M = (2 + h mi)ω + 2τh ac + 2τh mi + κ. In cas of MMA(co), w hav: T co M = 2ω + 2τh cd + κ. Similarly, th srvic disruption tim in th dfault mod (DF - without contxt transfr, DF-C using contxt transfr) is givn by: SD DF = T L2 + T RS RA + T MMC + T Sub + T DF M, (2) SD DF c = T L2+T RS RA+T MMC +T CXT +T DF M, (3) whr T Sub is th tim ndd for th MAR to obtain th MN s subscription information basd on th normal MLD procss. W hav: T Sub = T MSA + T QRD + 2κ, whr T MSA, T QRD rprsnt th multicast srvic activation tim and th qury rspons dlay, rspctivly [25]. W suppos that MLD Quris ar followd immdiatly th link-up vnt or th autoconfiguration of IPv6 link-local addrss of an MN [22]. As a consqunc, th multicast srvic activation tim can b ignord (T MSA = 0). Th srvic disruption tim in th dirct mod (DR) is givn by: SD DR = T L2 + T RS RA + T MMC + T Sub + T c M, (4) T c M = (h mi + 1)ω + 2τh mi + κ, 12 SD DF c = T L2 + T RS RA + T MMC + T CXT + T c M. (5)

14 End-to-End Dlay End-to-nd dlay (E2E (.) ) is th packt transmission dlay from th sourc to th listnr. In th MMA(c), th cmar rcivs th multicast traffic dirctly from th multicast infrastructur similar to th dirct mod. Hnc, w hav: E2E c MMA = E2E DR = τh sc + κ. (6) In cas of MMA(a), th multicast packt is routd from th sourc to th cmar via th amar, rprsnting th dfault mod. W hav: E2E a MMA = E2E DF = τh sa + τh ac + κ. (7) In MMA(p) mod, if th traffic for th multicast flow is alrady availabl at th currnt MAR, this MAR will simply forward it to th MN. Aftr ach handovr, th currnt MAR can obtain th multicast traffic ithr from its upstram intrfac (with probability p p ) or from th prvious on (with probability 1-p p ). Sinc th flow is startd at th anchor MAR, th dlay in cas of MMA(p) is thrfor givn by: E2E p MMA + = κ + (τhsa + τnmarhmm)pn mar 1 N mar 1 i=1 [τh i + τ(i + 1)h mm]p i p(1 p p), (8) whr N mar dnots th avrag numbr of MARs involvd in th data traffic forwarding btwn amar and cmar; and h i is th hop-count distancs from th sourc to th i th MAR in th moving path of th MN (from th amar to th cmar). Considring th MMA(co), E2E is xprssd as: E2EMMA co = τh sm + τh cd + κ. (9) Cost Analysis Signaling Cost. Th signaling cost (SC (.) ) is th signaling ovrhad for supporting th handovr including multicast-rlatd procdurs. It is notd that w considr only th signaling cost pr handovr, thus th cost for rfrshing and drgistration ar not takn into account. It thrfor can b calculatd as: p SC (.) = µ ( LU (.) + MC (.) ), (10) whr µ is th MAR subnt bordr crossing rat, LU (.), MC (.) is th signaling cost for th location updat and th multicast-rlatd procdurs, rspctivly. According to [35], th signaling mssag dlivry cost is calculatd as th product 13 of th mssag siz, th hop distanc and th unit transmission cost in a wird/wirlss link (α for th wird and β for th wirlss link). W obtain: LU MMA = LU DF = LU DR = 2β+2αh cd +2αh ac, (11) MC c MMA = MC CXT + MC conf + α(1 + h mi), (12) whr Similarly, w hav: MC CXT = 2αh pc, MC conf = 2αh cd. MC p MMA = MCCXT + MC conf + αh pc, (13) MC a MMA = (1 p a)mc a df whr MC a df MMA + pamca wc MMA, (14) MMA = MCCXT + MC conf + αh ac, MC a wc MMA = MC CXT + MC conf + α(h ac h mi), MC co MMA = MC CXT + MC conf + αh cd. (15) Rgarding DF and DR mod, MC DF and MC DR ar xprssd as: MC DF = αh ac + 2β, (16) MC DF c = MC CXT + αh ac, (17) MC DR = α + αh mi + 2β, (18) MC DR c = MC CXT + α + αh mi. (19) Packt Dlivry Cost. Th packt dlivry cost (P C (.) ) rprsnts th cost of dlivring multicast packts to th MN pr unit of tim. Lt S c, λ p dnot th avrag sssion lngth at th cmar and th packt arrival rat, rspctivly. Again, th packt dlivry cost in th MMA(a) corrsponds to th dfault multicast mod. Th packt dlivry cost is xprssd as: P C c MMA = P C DR = S cλ p(αh sc + β), (20) P C a MMA = P C DF = S cλ p(αh sa + αh ac + β). (21) Similar to E2E p MMA, P Cp MMA can b calculatd as: P C p MMA = Scλpβ+Scλp(αhsa+αN marhmm)pn mar 1 p N mar 1 + S cλ pα [h i + (i + 1)h mm]p i p(1 p p). (22) i=1 P C co MMA = S cλ p(αh sm + αh cd + β). (23)

15 Tunnling Cost. Rgarding th packt tunnling cost (T C (.) ), it is dfind as th additional cost from th tunnling ovrhad. In MMA(c), th multicast traffic is rcivd dirctly from th multicast infrastructur, thus, thr is no tunnling cost. On th contrary, in MMA(a), MMA(p), and MMA(co) th traffic is routd via th tunnl amar-cmar, pmar-cmar, and cmar-comma, rspctivly. Not that th tunnling cost in th MMA(a), MMA(c) corrsponds to th dfault mod, and th dirct mod, rspctivly. Th tunnling cost is thrfor computd as: T C p MMA T C c MMA = T C DR = 0. (24) T C a MMA = T C DF = αs c λ p h ac. (25) mar 1 = αscλphmmn marpnp N mar 1 + αs cλ ph mm (i + 1)p i p(1 p p), (26) i=1 T CMMA co = αs c λ p h cd. (27) Packt Loss During th handovr, packts may b lost. For sak of simplicity, w assum that th numbr of lost packts is proportional to th srvic disruption tim and th packt arrival rat. As a rsult, th numbr of lost packts is givn by: 5. Numrical Rsults P L (.) = λ p SD (.). (28) This sction prsnts th numrical rsults for th proposd solution in comparison with th DR, DR-C, DF, and DF-C mod. It is worth to not that all th 4 diffrnt schms in our proposd solution (including MMA(a), MMA(c), MMA(p), MMA(co)) ar prsntd to highlight th nd of a dynamic multicast support mchanism. Th dfault paramtr valus for th analysis ar introducd in Tabl 1, in which som paramtrs ar takn from [25, 27, 34]. Also, w considr th cas whr th MN always movs from MAR to MAR as if thy wr linarly dployd (th usr is moving furthr away from th first attachd MAR and nvr attachs back to a prviously visitd MAR). It rprsnts th worstcas scnario. Thus, w hav h ac = N mar h mm, 14 Tabl 1: Paramtrs for th prformanc analysis. Paramtr Valu Paramtr Valu T L2 29.9ms τ 2 λ p 10 packts/s κ 15 α 1 β 5 ω 10 ms h mm 1 hops h cd 8 hops h mi 2 hops h sa 14 hops h sp 14 hops h sc 14 hops h sm 14 hops S c 60 s p p 0.9 p a 0.5 T QRD 1 s r a m 15 _ N Vlocity (m/s) N_mar Figur 7: N mar as a function of vlocity (υ). h ap = (N mar 1)h mm, and h pc = h mm. According to [36], N mar is calculatd as: N mar = 1 + µ δ, (29) whr 1/δ is th man valu of th activ prfix liftim whil th MN is visiting a forign ntwork. To giv th ida of th rlation btwn th numbr of MARs involvd in th data traffic forwarding to/from an MN (N mar ) and th vlocity (υ), w assum that th subnt rsidnc tim (MAR subnt) is a random variabl which follows an xponntial distribution with man valu 1/µ and th MAR covrag ara is circular with radius R. According to [37], th subnt bordr crossing rat µ is calculatd as: µ = 2υ πr, (30) whr υ is th avrag vlocity of th MN. Fig. 7 dpicts th valu of N mar as a function of th vlocity whn th subnt radius R and 1/δ ar fixd to th valu of 400m and 300s, rspctivly. As th vlocity incrass, N mar is incrasd. According to quation (29), w can obtain a similar curv as in Fig. 7 if th valu of υ is fixd whil th man valu of th activ prfix liftim (1/δ) is

16 ) s ( m im T n tio p r u is D ic rv S (a) N_mar MMA(c) MMA(p) MMA(a) MMA(co) varying. Thus, th figur for this cas is not shown hr. As w can obsrv, th low valu of N mar rprsnts a low mobility and/or a low-livd flow scnario. Th highr valu of N mar corrsponds to a high mobility and/or a long-livd flow scnario Multicast Srvic Disruption Fig. 8 shows th multicast srvic disruption tim as a function of N mar and h mi. In Fig.8(a), th valu of N mar is varid ovr a rang from 1 to 15. It appars clarly that without th multicast contxt transfr, th srvic disruption in th DF and DR mod (about 1200ms) is dfinitly highr than that in th othr cass and lading to such an unaccptabl srvic disruption. Whn N mar is small, DF- C givs a bttr prformanc than th othrs. As N mar incrass, whil th disruption tim in DR- C, MMA(p), MMA(c), MMA(co) is kpt constant, that in DF-C, MMA(a) is significantly incrasd. As a rsult, DR-C outprforms th othrs, whil MMA(p) introducs a minor additional disruption compard to that in DR-C. Similarly, as can b sn in Fig.8(b), whn th h mi is incrasd, th srvic disruption tim in MMA(p), MMA(co) and DF-C is fixd whil that in MMA(c), MMA(a) and DR-C is notably incrasd. Altogthr, th srvic disruption tim cannot b guarantd in both cass DR-C and DF-C. Bsids, th srvic disruption in MMA(p) is slightly highr compard to th lowr valu among DF-C and DR-C. It is also stabl in both figurs. In conclusion, th diffrnc btwn th srvic disruption in MMA(p), DF-C, and DR- C can b considrd as a cost of our solution to obtain th rquird contxt to kp th srvic disruption tim stabl and as low as possibl as wll. DF DF_C DR DR_C ) s ( m im T n tio p r u is D ic rv S Figur 8: Srvic disruption as a function of: (a) N mar, (b) h mi h_mi (hops) (b) 5.2. End-to-End Dlay MMA(c) MMA(p) MMA(a) MMA(co) Rgarding th nd-to-nd dlay, two diffrnt scnarios ar considrd. In th first scnario, th sourc is supposd to b outsid of th DMM domain. Thus, th distanc btwn th sourc and th MAR is supposd to b th sam. Th rsults of this scnario ar shown in Fig.9(a). Th scond scnario is usd to illustrat th cas whr th sourc (insid th domain) is xtrmly clos to th amar (on th right sid of Fig. 9(b)) or xtrmly clos to th cmar (on th lft sid of Fig. 9(b)). It is don by varying th valu of h sc whil fixing th valu of h sa + h sc (for xampl, 16 hops). In th first scnario (Fig. 9(a)), as N mar incrass, th nd-to-nd dlay in cas of MMA(a)/DF is dramatically incrasd, whil that in MMA(c)/DR and MMA(co) is kpt constant. On th othr hand, th dlay in MMA(p) is rlativly small incrasd. Not that th dlay in MMA(c)/DR and MMA(p) is kpt blow th valu 50 ms, which mans that ths mods satisfy th strict rquirmnt in trms of nd-to-nd dlay (for ral-tim gaming as spcifid in [31]). In th scond scnario, as can b obsrvd in Fig. 9(b), vn whn th sourc is vry clos to th amar (h sa =1, h sc =15), th dlay in th MMA(c)/DR is lowr than that in th othr cass. Thrfor, th impact of th mobility tunnl (cmar-amar and cmar-pmar) on th nd-to-nd dlay is obvious. In conclusion, th MMA(c)/DR is gnrally wll suitd for th dlaysnsitiv flows, whil MMA(p) introducs a minor additional dlay compard to that in MMA(c)/DR. DF DF_C DR DR_C

17 80 ) s ( m y la 60 D d n - E - to d n E 40 t s o C g lin a n ig S MMA(c)/DR MMA(p) MMA(a)/DF MMA(co) 5.3. Signaling Cost N_mar (a) Figur 9: End-to-End dlay as a function of: (a) N mar, (b) h sc /mu (s) (a) MMA(c) MMA(p) MMA(a) MMA(co) DF DF_C DR DR_C Fig. 10 shows th signaling cost of th proposd solution in comparison with th DF and DR mod. As can b sn in this figur, th DR and DF mods giv a bttr prformanc compard with our solution. It is obvious sinc in our solution, mor signaling mssags ar ndd to collct th contxt. In Fig. 10(a), th signaling cost is dcrasd as th subnt rsidnc tim (1/µ) incrass (µ dcrass). Howvr, th signaling ovrad is ngligibl. In Fig. 10(b), whn th valu of h mi incrass, th signaling cost is fixd in cas of DF, DF- C and MMA(p), whil it is incrasd in th othr cass. Th rason is that in cas of DF, DF-C, and MMA(p) th currnt MAR obtains th multicast traffic from th MAR which had th subscription information of th flow. In gnral, our solution introducs an accptabl signaling ovrhad compard to th DF and DR mods, as a cost of th contxt collction procss. Additionally, this ovrhad can b avoidd if our solution works in th SIMP mod. Figur 10: Signaling cost as a function of: (a) 1/µ, (b) h mi. ) s m ( y la D d n -E ṯ o d n E 16 t s o C g lin a n ig S h_sc (hops) (b) MMA(c)/DR MMA(p) MMA(a)/DF MMA(co) t s o C r y liv D t k c a P MMA(c)/DR MMA(p) MMA(a)/DF MMA(co) h_mi (hops) (b) MMA(c) MMA(p) MMA(a) MMA(co) DF DF_C DR DR_C N_mar Figur 11: Packt dlivry cost vrsus N mar Packt Dlivry Cost Rgarding th packt dlivry cost, MMA(c) and DR mod giv th bst prformanc compard to th othrs. Whn N mar incrass, th packt dlivry cost in MMA(c)/DR and MMA(co) is kpt constant whil that in MMA(a)/DF is notably incrasd. In th middl, MMA(p) introducs a minor incras in compard to MMC(c)/DR.

18 t s o C g lin n n u T MMA(c)/DR MMA(p) MMA(a)/DF MMA(co) MR MR PIM domain MR Sourc MMC N_mar Figur 12: Tunnling cost as a function of N mar Tunnling Cost Fig.12 dpicts th tunnling cost as a function of N mar. As can b sn in this figur, MMA(c) and DR mod do not introduc any tunnling ovrhad sinc th traffic is routd dirctly from th multicast infrastructur without using th mobility tunnl. On th contrary, th tunnling cost in cas of MMA(a) and DF is significantly incrasd as N mar incrass. It is du to th fact that th traffic is routd via th tunnl amar-cmar which is supposd to b long. Th tunnling ovrhad in cas of MMA(p) is incrasd, howvr, still lowr than that of MMA(co) which is kpt constant Packt Loss With a fixd valu of packt arriv rat, th packt loss is dirctly proportional to th srvic disruption tim as givn in q. (28). Accordingly, th figur dpicting th packt loss (as a function of N mar and h mi ) has a similar curv as in Fig.8, thus, is not shown hr. Again, th DF and DR rprsnt a larg numbr of packt losss, whil MMA(p) can b considrd as a good option to guarant th low numbr of packt losss. 6. Implmntation and Prliminary Rsults 6.1. Currnt status of th Implmntation Th proposd solution, DMMS, is undr dvlopmnt [27, 24]. At this stag, MGM, MCT, and I3M moduls ar alrady availabl. In dtails, MGM was dvlopd basd on an opn-sourc for MLD Proxy, namly ECMH 6. It is xtndd to support th xplicit tracking function and th multipl upstram intrfacs. Thr is anothr possibility in which 6 Easy Cast du Multi Hub, 17 MAR1 AP MAR16 AP16 MN MN MN NS-3 Figur 13: Tstbd dploymnt. MGM can work as an MR.g., by using MRD6 7. MCT modul (writtn in C), which was dvlopd as a sparat componnt, can b asily applid to th othr solutions in PMIPv6 as wll as in DMM [27, 24]. On th othr hand, in our laboratory, a Linux-basd DMM was rcntly implmntd on top of th UMIP 8 and OAI PMIP implmntation [38]. Our DMM implmntation, which follows a partially distributd approach, is prfctly fit with I3M modul. Th CMD is xtndd to play th rol of MMC. At this stag, CMDM modul is xcutd in a simpl way: i) with a low mobility nod, MMA(a) is always usd; ii) with a high-mobility nod, for a disruption-snsitiv srvic, MMA(p) is applid whil for a dlay snsitiv srvic, MMA(c) is slctd. In addition, whn th MN plays th rol of a sourc, MMA(a) is applid Tstbd Dploymnt and Scnario Dscription Following th ida of a nar-to-ral tstbd dscribd in [25], th proof-of-concpt architctur, as indicatd in Fig. 13, is dployd. Th tstbd is a combination of virtualizd nvironmnt which consists of multipl virtual machins (.g., using Usr-Mod Linux 9 ) and th Ntwork Simulator NS It is composd of a cntral ntity playing th rol of MMC, 16 MARs with MUMO functionality, 16 accss points (APs), 15 multicast routrs (MRs) supporting Protocol Indpndnt Multicast 7 MRD6, 8 UMIP - Mobil IPv6 and NEMO for Linux, Usr-Mod Linux, 10 Th Ntwork Simulator NS-3,

19 - Spars Mod (PIM-SM) 11, on multicast sourc and on MN acting as a multicast listnr. Th architctur of th PIM-SM domain is hirarchically formd as a tr structur with 4 layrs in which th sourc s MR acts as th root of th tr [39]. Th MARs ar thn connctd to th PIM-SM dommain in a similar mannr, as th lafs of th binary tr. Thus, this structur allows to masur th impact of h mi to th prformanc mtrics. For instanc, th tstbd is dployd on a singl physical machin running Ubuntu LTS. Th MMC, MARs, MRs and th sourc ar th virtual machins, whil th MN and th APs ar NS-3 nods. By using NS-3, th mobil nod can asily mov btwn MARs. To gnrat th multicast traffic, svral tools can b usd.g., Iprf 12 and MINT 13. During th xprimnts, a ntwork analyzr tool (.g., Wirshark 14 ) is usd to captur th packts xchangd btwn th ntitis. At this stp, two prformanc mtrics ar considrd including srvic disruption and ndto-nd dlay. It is notd that for th improvmnt of th crdibility, w prformd th xprimnt in a larg amount of tims. Basd on th collctd rsults, w calculatd th avrag valu and th standard dviation to improv th dgr of confidnc. Thn two diffrnt xprimntal scnarios ar dfind as follows. Scnario 1 (S1): This simpl scnario is to xplain th situation in which th flow will b trminatd aftr on handovr and th valu of h mi is fixd to a valu of on. In this scnario, th MN will first attach to th MAR1. It subscribs to a multicast flow which is bing broadcastd by th sourc. Th MN will thn prform a handovr from MAR1 to MAR2. Scnario 2 (S2): This gnral scnario is usd to illustrat th situation whn both th numbr of activ prfixs and th valu of h mi ar varid. In this cas, th MN will first attach to th MAR1. It subscribs to a multicast flow which is bing broadcastd by th sourc. It thn movs from MAR1 to MAR16 passing th MARi (i=2,..,15). Th flow is kpt aliv during th movmnt. W thn calculat th avrag 11 Th multicast routr functions ar dployd by using MRD6 implmntation. 12 Iprf, 13 MINT, 14 Wirshark, 18 srvic disruption as wll as nd-to-nd dlay for all handovrs Prliminary Rsults Tabl 2: Prliminary Rsults: th avrag and standard dviation valus of srvic disruption and nd-to-nd dlay in millisconds. Mtric/ MMA DF-C DR-C Mthod SD (S1) (203.6, 60.3) (170.4, 45.5) (199.3, 49.4) SD (S2) (213.3, 65.2) (311.3, 160.6) (327.3, 150.2) E2E (S1) (43.2, 11.3) (46.1, 14.5) (42.2, 13.4) E2E (S2) (48.2, 13.2) (67.3, 20.5) (40.3, 12.2) Tabl 2 shows th avrag and standard dviation valus of srvic disruption tim and nd-tond dlay of our solution in comparison with DF-C and DR-C in two diffrnt scnarios (S1 and S2). Rgarding th multicast srvic disruption, in th scnario 1 (S1) th disruption in cas of MMA is slightly longr than that in DF-C and DR-C as a cost of additional signaling mssags xchangd btwn th ntitis for collcting th contxts. Howvr, in th scnario 2, whil th srvic disruption in cas of MMA is slightly incrasd, thos in DF- C and DR-C ar significantly incrasd. Thus, it is clar that by dynamically providing a suitabl multicast support mod, our solution hlps to kp th valu of srvic disruption stabl. Morovr, this valu is much lowr than th on in cas of DR-C and DF-C in th scnario 2. Th rason is that by moving th MN from MAR1 to MAR16, w varid th valu of two paramtrs i.., numbr of activ prfixs and h mi at th sam tim. Th similar thing happns in trms of nd-to-nd dlay. In dtails, in th first scnario, thr mods giv th similar rsults. Howvr, whil th dlay in cas of MMA and DR-C is almost stabl, th on in cas of DF-C is notably incrasd. In th nxt stps, mor xprimnts will b considrd to validat th bhavior of our proposd solution. 7. Discussions 7.1. Multicast Routr Function Dploymnt at th MAR Our analysis can also b applid whn th multicast routr function is dployd at th MAR. As in th Mdival projct, th MGM rprsnts th functionality of a PIM-SM multicast routr (.g., basd on MRD6 implmntation). In this cas, th Multicast Routing Information Bas (MRIB) not

20 only can b basd on th unicast RIB, but also on th information from th CMDM. For xampl, in ordr to apply MMA(p) for a spcific channl (say C1), th cmar uss an xplicit PIM join mssag to join th C1 at pmar. In othr words, pmar bcoms a rvrs path forwarding (RPF) nighbor routr of th cmar rgarding th spcific flow C Multicast Sourc Mobility Support At this stag, our solution can also support sourc mobility in DMM. Howvr, th MMA(a) will always b applid to avoid th potntial impact on th srvic disruption. In cas of ASM, an xtnsion of PIM-SM [40] can b usd to rout th multicast traffic dirctly from th cmar to th rndz-vous point (RP) bypassing th amar. Thus, th multicast traffic is routd in a bttr way. In mor dtails, th xplicit RPF mchanism is usd to build th multicast dlivry tr via an xplicitly configurd path includd in th PIM join mssags. Aftr rciving th unicast-ncapsulation packts from th currnt MAR, th RP will snd a Join mssag including th addrss of th sndr (cmar s addrss) in a nw typ-lngth-vctor (TLV). It allows th RP to stablish th shortst path tr towards th currnt location of th sourc. Th nativ multicast traffic thn will b snt via th nw dlivry tr from th cmar and rachs th listnrs (PIM phas two). 8. Conclusions and Prspctivs As a varity of multicast srvic with diffrnt faturs is xpctd to b widly usd in th futur ntworks, a flxibl architctur to support multicast is rquird. In this papr, w introducd an architctur to support multicast in a flxibl mannr (namly DMMS) from both th srvic and th oprator point of viws. Dpnding on a st of contxts, an appropriat support mod will b nabld, thus, providing a pr-flow multicast support. Th numrical and xprimntal rsults showd that DMMS guarantis th srvic rquirmnts in trm of srvic disruption and nd-to-nd dlay whil kping th low valu of signaling, packt dlivry and tunnling cost compard with othr proposals. Also, DMMS hlps to avoid th traffic rplication issu whil bttr distribut th load among th accss routrs. In th nxt stp, to achiv a mor ralistic rsult, mor xprimnts will b conductd basd on th undr-dploymnt ral tstbd. Acknowldgmnt EURECOM acknowldgs th support of its industrial mmbrs: BMW Group Rsarch & Tchnology, IABG, Monaco Tlcom, Orang, SAP, SFR, ST Microlctronics, Symantc. Rfrncs [1] Ericsson, Ericson Mobility Rport: On th Puls of th Ntworkd Socity, Nov [2] Cisco, Cisco Visual Ntworking Indx: Global Mobil Data Traffic Forcast Updat, , Fb [3] Cisco Whit Papr, Cisco VNI Srvic Adoption Forcast, , [4] Tlfonica Ss ARPU Dclin as Data Grows and Voic Falls, Analysis/tlfonica-ss-arpu-dclin-as-data-growsand-voic-falls. Jun [5] H.A. Chan, D. Liu, P. Sit, H. Yokota, and J. Korhonn, Rquirmnts for Distributd Mobility Managmnt, RFC 7333, Aug [6] H.-A.Chan, H. Yokota, J. Xi, P. Sit, and D. Liu, Distributd and Dynamic Mobility Managmnt in Mobil Intrnt: Currnt Approachs and Issus, Journal of Communications, vol. 6, no. 1, [7] C.B. Sankaran, Data Offloading Tchniqus in 3GPP 19 Rl-10 Ntworks: A Tutorial, IEEE Commun. Mag., vol. 50, no. 6, pp , Jun [8] B. Williamson, Dvloping IP Multicast Ntworks, Cisco Prss, [9] T. Schmidt, M. Wahlisch, and G. Fairhurst, Multicast Mobility in Mobil IP Vrsion 6 (MIPv6): Problm Statmnt and Brif Survy, RFC 5757, Fb [10] Ericsson Whit Papr, LTE Broadcast: A Rvnu Enablr in th Mobil Mdia Era, Fb [11] A. El-Sayd, V. Roca, and L. Mathy, A Survy of Proposals for an Altrnativ Group Communication Srvic, Ntwork, IEEE, vol. 17, no. 1, pp , [12] I. Romdhani, M. Kllil, H.-Y. Lach, A. Bouabdallah, and H. Bttahar, IP Mobil Multicast: Challngs and Solutions, IEEE Communications Survys Tutorials, vol. 6, no. 1, pp , [13] Ericsson, LTE Broadcast: A Rvnu Enablr in th Mobil Mdia Era, Whit Papr, Fb [14] T.-T. Nguyn, Optimization of Mobility Mchanisms for IP-basd Multicast Flows, Ph.D. thsis, Mobil Communications Dpt., EURECOM, Sophia-Antipolis, Franc, May [15] S. Figuirdo, S. Jon, and R.L. Aguiar, IP Multicast Us Cass and Analysis ovr DMM, IETF Draft (xpird), Oct [16] T.-T. Nguyn and C. Bonnt, On th Efficincy of Dynamic Multicast Mobility Anchor Slction in DMM: Us Cass and Analysis, IEEE Intrnational Confrnc on Communications (ICC), Jun [17] H. Ali-Ahmad, D. Moss, H. Moustafa, P. Sit, and T. Condxia, Mobility Anchor Slction in DMM: Us-cas Scnarios, IETF-Draft (work-in-progrss), Jul [18] C. Prkins, D. Johnson, and J. Arkko, Mobility Support in IPv6, RFC 6275, Jul 2011.

21 [19] S. Gundavlli, K. Lung, V. Dvarapalli, K. Chowdhury, and B. Patil, Proxy Mobil IPv6, RFC 5213, Aug [20] C.J. Brnardos, A. d la Oliva, and F. Giust, A PMIPv6-basd Solution for DMM, IETF Draft (workin-progrss), Mar [21] H. Asada, H. Liu, and Q. Wu, Tuning th Bhavior of th Intrnt Group Managmnt Protocol (IGMP) and Multicast Listnr Discovry (MLD) for Routrs in Mobil and Wirlss Ntworks, RFC 6636, May [22] T. Schmidt, M. Wahlisch, and S. Krishnan, Bas Dploymnt for Multicast Listnr Support in Proxy Mobil IPv6 (PMIPv6) Domains, RFC 6224, Apr [23] T.-T. Nguyn and C. Bonnt, Efficint Multicast Contnt Dlivry ovr a Distributd Mobility Managmnt Environmnt, in Proc. VTC Fall, Las Vgas, USA, Spt [24] S. Figuirdo, C. Guimaras, R.L. Aguiar, T.-T. Nguyn, L. Yadin, N. Carapto, and C. Parada, Broadcasting Usr Contnt ovr Novl Mobil Ntworks, ICC 2013, Jun [25] T.-T. Nguyn and C. Bonnt, Prformanc Optimization of Multicast Contnt Dlivry in a Mobil Environmnt basd on PMIPv6, WCNC, Apr [26] 3GPP, TR , Rquirmnts for Evolvd UTRA (E-UTRA) and Evolvd UTRAN (E-UTRAN), Rlas 9, Dc [27] MEDIEVAL projct, Dlivrabl D4.4, Final Oprational Mobility Architctur, Dc [28] LM. Contrras, CJ. Brnardos, I. Soto, Proxy Mobil IPv6 (PMIPv6) Multicast Handovr Optimization by th Subscription Information Acquisition through th LMA (SIAL), RFC 7161, March [29] S. Figuirdo, S. Jon, and R.L. Aguiar, Us-cass Analysis for Multicast Listnr Support in Ntworkbasd DMM, PIMRC 2012, Spt 2012 [30] JC. Zuniga, LM. Contrras, CJ. Brnardos, S. Jon, and Y. Kim, Multicast Mobility Routing Optimizations for Proxy Mobil IPv6, RFC 7028, Sp [31] ITU-T Rcommndation G. 114, Gnral Charactristics of Intrnational Tlphon Connctions and Intrnational Tlphon Circuits: On-Way Transmission Tim, May [32] H-K. Zhang, S. Gao, TC. Schmidt, B-H. Fng, and L-L. Wang, Multi-Upstram Intrfacs IGMP/MLD Proxy, IETF Draft (xpird), Jul [33] H. Asada, IGMP/MLD-Basd Explicit Mmbrship Tracking Function for Multicast Routrs, IETF Draft (work-in-progrss), Mar [34] S.J. Yang, and S.H. Park, A Dynamic Srvic Rangd- Basd Multicast Routing Schm Using RSVP in Mobil Ntworks,GLOBECOM, [35] J.-H. L and T.-M. Chung, How Much do W Gain by Introducing Rout Optimization in Proxy Mobil IPv6 Ntworks?, Annals of Tlcommunications, vol. 65, no. 5-6, pp , Jun [36] F. Giust, C.J. Brnardos, and A. D La Oliva, Analytic Evaluation and Exprimntal Validation of a Ntworkbasd IPv6 Distributd Mobility Managmnt Solution, IEEE Trans. Mobi. Comp., no. 99, Fb [37] C. Makaya and P. Samul, An Analytical Framwork for Prformanc Evaluation of IPv6-basd Mobility Managmnt Protocols, IEEE Trans. Wirlss Communications, vol. 7, no. 3, pp , Mar [38] OpnAir Intrfac Proxy Mobil IPv6, [39] Y Min-hua, Yang Lv-yun, Liu Yu, and Zhang Hui-min, Th implmntation of multicast in Mobil IP, Proc. of WCNC, [40] J. Asghar, IJ. Wijnands, S. Krishnaswamy, A. Karan, and V. Arya, Explicit RPF Vctor, IETF-Draft(workin-progrss), Fb Tin-Thinh Nguyn is a Postdoc rsarchr at EURECOM, Sophia Antipolis, Franc. H rcivd his B.S. dgr in Computr Enginring from Hanoi Univrsity of Scinc and Tchnology, Vitnam in H rcivd th M.S. dgr in Ntworks and Communication Systms from Univrsity of Claud Brnard Lyon 1, Franc in H rcivd his PhD dgr in Computr Scinc and Ntworking from Tlcom Paristch, Franc in His rsarch intrsts ar in th aras of wirlss ntworks and mobil ntworks with mphasis on IP multicast, mobility managmnt, and Softwar-dfind Ntworking. Christian Bonnt rcivd his M.S. dgr in 1978 from Ecol National ds Mins d Nancy, Franc. H is currntly a Profssor in th Dpartmnt of Mobil Communications at EURE- COM, Sophia Antipolis, Franc. His taching activitis ar raltim and distributd systms, mobil communication systms, wirlss LANs and protocols for mobility managmnt. His main aras of rsarch ar wirlss protocols, wirlss accss to IP ntworks and data communications in mobil ntworks including mobil ad hoc ntworks. 20