Contributions to the future media internet using service-oriented architectures
Abstract
Nowadays, video streaming applications are the most bandwidth-hungry applications and this tendency is envisaged to grow exponentially. With the proliferation of multimedia capable devices, multimedia services have to deal with heterogeneous environments where very different types of terminals wish to receive content anywhere and anytime. This situation motivates the appearance of multimedia services that adapt contents to the specific context of users. These services can benefit from the use of different technologies for content delivery (e.g. Peer-to-Peer and Network Coding), media signalling (e.g. SIP and P2P protocols), media representation (e.g. MPEG-7 and MPEG-21) or multimedia scalable and robust codification (e.g. Multiple Description Coding and Scalable Video Coding). However, current Internet architecture is based on a rigid layered model (TCP/IP-based) following the, no longer valid, end-to-end argument, which makes difficult to introduce new functionalities efficiently. To solve this, Service Oriented Architectures (SOA) principles seem to fit in the proposal of new architectures for a more flexible Future Internet based on services that can be invoked when and where necessary. The objectives of this PhD. Thesis are exploring and validating different mechanisms for enabling Future Media Internet communications. To achieve this, we apply the SOA paradigm to provide efficient context-aware multimedia communications in the Future Internet. This work proposes solutions to enable the seamless provisioning of multimedia services in the Future Internet by means of context-aware service discovery and composition processes which are integrated in a novel service-oriented clean-slate architecture. One goal is to provide adapted and personalized services, dealing with high dynamic and heterogeneous environments. For this reason, this thesis includes research on novel media coding techniques (Multiple Description Coding, Scalable Video Coding) and distribution techniques (Peer-to-Peer, Network Coding) that can be applied to achieve seamless media communications. Moreover, context-aware service composition will address the requirements of media services (and any service in general), access methods, devices and interactions. This work presents a radical view of the Future Internet, where the necessary functionalities for accomplishing communications, in user devices, in the network and at all levels are considered as services. Services are not fixed but dynamically composed where and when necessary, with respect to user service requirements, network transfer capabilities and surrounding context in the user and the network environments. Composition of basic network-level services calls for a clean-slate approach to the Internet, while composition of higher level (transport and application) services prompts for an evolutionary approach. Nevertheless, composition of communication services manifests itself as a revolutionary way of looking communications and building communication systems. This PhD. Thesis introduces two main architectural innovations clearly beyond current state of the art. Firstly, a Service- Oriented framework able to deal with (existing) functionality at all levels (connectivity, transport, application) by considering the provided service and not the technology behind the functionality. All these service functionalities can be seen as services thanks to suitable service-oriented abstractions that allow including existing functionality/protocols as well as new functionality in a flexible way. Secondly, we present a novel service-oriented clean-slate architecture generalizing Information- Centric Networking (ICN) approaches. This work would propose the first clean-slate architecture completely aligned with the work done within the ISO Future Networks working group
Full text
! ! ! ! ! ! Universitat!Politècnica!de!Catalunya!(BarcelonaTech)! ! Department!of!Telematics!Engineering! ! ! ! ! ! ! PhD.!Thesis!! ! ! ! ! ! Contributions!to!the!Future!Media!Internet! using!ServiceEOriented!Architectures! ! ! ! Alberto!José!González!Cela! ! ! ! ! ! ! ! ! Advisor:!Jesús!Alcober!Segura! ! ! ! 2012! ! ©!2012!All!rights!reserved! !
! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! “We!can't!solve!problems!by!using!the!same!kind!of!thinking!we!used!when!we! created!them.”!(Albert!Einstein)! ! !
! ! Acknowledgements. ! First!of!all,!the!author!wishes!to!express!his!love!and!gratitude!to!his!beloved! parents,!Juan!Andrés!and!Maite,!for!their!understanding,!patience!and!endless! love!through!the!duration!of!his!studies,!professional!activities!and!life.! ! This!work!was!supported!by!the!TARIFA!project!of!the!i2CAT!Foundation,!the! EuroENF! and! by! the! Spanish! Government! (MICINN)! under! research! grant! TIN2010E20136EC03.! ! This!work!would!not!have!been!possible!without!the!support!of!many!people.! The!author!would!like!to!thank!all!participants!from!the!TARIFA!project!of!the! i2CAT!Foundation! for! their! help! and!support.! Specially! thanks!to! the! Grup! de! Tecnologies!Media! (GTM)!of!La!Salle!–!Universitat! Ramon!Llull!(URL)!and!the! Wireless! Networks!Group! (WNG)! group! from! Universitat! Politècnica! de! Catalunya!(UPCEBarcelonaTech)!with!a!special!mention!to!Mr.!Ramón!Martín!de! Pozuelo,!Prof.!Josep!Paradells!and!Dr.!Xavier!SánchezELoro.! ! The!author!wishes!to!express!his!gratitude!to!his!supervisor,!Dr.!Jesús!Alcober! (UPCEMediaEntel)! and! to! Prof.! Sebastià! Sallent! (UPCEBAMPLA! and! director! of! i2CAT)!for!the!opportunity!of!working!in!this! issue!in!the! context!of!different! research!projects.!! ! Thanks!also!to!Mr.!André!Ríos!(UPC)!and,!again,!to!Mr.!Ramón!Martín!de!Pozuelo! (URL)! who! were! very! helpful! and! offered! constant! support! and! guidance.! Moreover,!I!would!like!to!thank!my!colleagues!Dr.!José!Ramón!Piney!(UPC),!Dr.! Javier!Ozón,!(UPC),!Mr.!Xavier!Miguélez!(Telefónica),!Mr.!Martín!Germán!(UPC)! and!Mr.!Pablo!Fernández!(UPC)!for!their!invaluable!advice!and,!especially,!for! their!friendship.! ! Special! thanks! also! to! Dr.! David! Rincón! (UPC),! Dr.! Francesc! Tarrés! (UPC),! Dr.! Cristina!Cervelló!(UPC),!Dr.!Panos!Georgatsos!(CERTH,!Greece),!Dr.!Yi!Jong!Hwa! (ETRI,!Korea),!Dr.!Kayhan!Zrar!Ghafoor!(UTM,!Malaysia),!Mr.!Antoni!Oller!(UPC),! Mr.!Flaminio!Minerva!(i2CAT),!Dr.!Bernd!Reuther!(University!of!Kaiserslautern,! Germany)!and!Prof.!Dae!Young!Kim!(CNU,!Korea)!for!sharing!literature,!precious! assistance!and!collaboration.!! ! The!author! would! also! like!to! convey! thanks! to! the!Universitat! Politecnica!de! Catalunya! (UPCEBarcelonaTech)! and! the! i2CAT! Foundation! for! providing! financial!means,!laboratory!facilities!and!support.!! ! Finally,!Карина!Корнилова!,!I’ll!never!be!able!to!thank!you!enough!for!all!your! love,!support,!help!and!guidance,!specially!during!all!this!rough!times.! ! Not! forgetting! his! bestfriends! who! always! have! been! there:! Jose!M.! Merayo,! Cristina!Sardanyés,!Cris,!Alex!Cateura,!Toñi,!Maria!Pons,!David!León,!Ana,!Estefi,! Meri!Ruiz,!Marc!Pous,!Xavi!Castells,!Xavi!Barrera,!Montmeló!team,!etc.!
! ! Abstract. ! Nowadays,! video! streaming! applications! are! the! most! bandwidthEhungry! applications! and! this! tendency! is! envisaged! to! grow! exponentially.! With! the! proliferation! of! multimedia! capable! devices,! multimedia! services! have! to! deal! with!heterogeneous!environments!where!very!different!types!of!terminals!wish! to! receive! content! anywhere! and! anytime.! This! situation! motivates! the! appearance!of!multimedia!services!that!adapt!contents!to!the!specific!context!of! users.! These! services! can! benefit!from!the! use! of!different! technologies! for! content!delivery!(e.g.!PeerEtoEPeer!and!Network!Coding),!media!signalling!(e.g.! SIP! and! P2P! protocols),! media! representation! (e.g.! MPEGE7! and! MPEGE21)! or! multimedia! scalable! and! robust! codification! (e.g.! Multiple! Description! Coding! and!Scalable!Video!Coding).!However,!current!Internet!architecture!is!based!on!a! rigid! layered! model! (TCP/IPEbased)! following! the,! no! longer! valid,! endEtoEend! argument,!which!makes!difficult!to!introduce!new!functionalities!efficiently.!To! solve! this,! Service! Oriented! Architectures! (SOA)! principles! seem! to! fit! in! the! proposal! of! new! architectures! for! a! more! flexible! Future! Internet! based! on! services!that!can!be!invoked!when!and!where!necessary.!! ! The! objectives! of! this! PhD.! Thesis! are!exploring!and! validating!different! mechanisms! for! enabling! Future! Media! Internet! communications.! To! achieve! this,!we!apply!the!SOA!paradigm!to!provide!efficient!contextEaware!multimedia! communications!in!the!Future!Internet.!! ! This!work!proposes!solutions!to!enable!the!seamless!provisioning!of!multimedia! services!in!the!Future!Internet!by!means!of!contextEaware!service!discovery!and! composition!processes! which!are!integrated!in!a! novel! serviceEoriented!cleanE slate! architecture.! One! goal! is! to! provide! adapted! and! personalized! services,! dealing! with! high! dynamic! and! heterogeneous! environments.! For! this! reason,! this! thesis! includes! research! on! novel! media! coding! techniques! (Multiple! Description!Coding,!Scalable!Video!Coding),!Forward!Error!Correction!codes,!and! distribution!techniques!(PeerEtoEPeer,!Network!Coding)!that!can! be! applied! to! achieve! seamless! media! communications.! Moreover,! contextEaware! service! composition!will!address!the!requirements!of!media!services!(and!any!service!in! general),!access!methods,!devices!and!interactions.!! ! This!work!presents!a!radical!view!of!the!Future!Internet,!where!the!necessary! functionalities! for! accomplishing! communications,! in! user! devices,! in! the! network!and!at!all!levels!are!considered!as!services.!Services!are!not!fixed!but! dynamically!composed!where!and!when!necessary,!with!respect!to!user!service! requirements,!network!transfer!capabilities!and!surrounding!context!in!the!user! and!the!network!environments.!! ! Composition!of!basic!networkElevel!services!calls!for!a!cleanEslate!approach!to! the! Internet,! while! composition! of! higher! level! (transport! and! application)! services! prompts! for! an! evolutionary! approach.! Nevertheless,! composition! of! communication! services! manifests! itself! as! a! revolutionary! way! of! looking! communications!and!building!communication!systems.!
! ! ! ! This!PhD.!Thesis!introduces!two!main!architectural!innovations!clearly!beyond! current!state!of!the!art.!Firstly,!a!ServiceEOriented!framework!able!to!deal!with! (existing)! functionality! at! all! levels! (connectivity,! transport,! application)! by! considering! the! provided! service! and! not! the! technology! behind! the! functionality.!All!these!service!functionalities!can!be!seen!as!services!thanks!to! suitable! serviceEoriented! abstractions! that! allow! including! existing! functionality/protocols!as!well!as!new!functionality!in!a!flexible!way.!Secondly,! we! present! a! novel! serviceEoriented! cleanEslate! architecture! generalizing! InformationECentric! Networking! (ICN)! approaches.! This! thesis!would! propose! the!first!cleanEslate!architecture!completely!aligned!with!the!work!done!within! the!ISO!Future!Network!working!group.! .
! ! Table.of.Contents. ! Part.I:!Introduction.–.The.Basics..........................................................................1! Chapter.1!Motivation:.Towards.Future.Media.Internet......................................3! Chapter.2!Multimedia.Delivery.Challenges.for.the.Future.Internet....................9! Chapter.3!Future.Media.Internet.Enablers.......................................................11! 3.1!Media!Streaming!Solutions!.............................................................................................................!13! 3.1.1!Media)Distribution)...........................................................................................................................)13! 3.1.2!Media)Coding).....................................................................................................................................)14! 3.1.3!Media)Adaptation)............................................................................................................................)16! 3.1.4!Media)Signalling)...............................................................................................................................)16! 3.2!ServiceEOriented!Future!Internet!Architecture!Solutions!.................................................!17! 3.2.1!Service)Composition)........................................................................................................................)17! 3.2.2!Context@awareness)..........................................................................................................................)18! Chapter.4!Scalable.and.Robust.Streaming.for.the.Future.Internet....................20! 4.1!Types!of!Overlay!..................................................................................................................................!23! 4.1.1!Tree@based)Overlay)..........................................................................................................................)24! 4.1.2!Mesh@based)Overlay)........................................................................................................................)25! 4.2!Content–aware!P2P!networks!.......................................................................................................!25! 4.3!Advanced!Media!Coding!Techniques!for!the!Future!Internet!..........................................!27! 4.3.1!Source)Coding)....................................................................................................................................)27! 4.3.2!Network)Coding)(NC)).....................................................................................................................)29! 4.4!QoS!Provisioning!and!Video!Adaptation!...................................................................................!30! Chapter.5!Future.Internet.from.a.Service.Perspective......................................33! 5.1!Service!Definition!and!Classification!...........................................................................................!35! 5.2!Problem!Statement!and!Requirements!of!a!ServiceEbased!Future!Internet!..............!38! 5.3!Relevant!Examples!of!Service!Composition!in!Future!Internet!Projects! ! !and!Standardization!Activities!.....................................................................................................!41! 5.4!Service!Identification,!Naming!and!Addressing!.....................................................................!48! 5.4.1!Semantic)Service)Identification).................................................................................................)50! 5.5!Service!Discovery!................................................................................................................................!51! Part.II:!Scalable.and.Robust.Media.Streaming....................................................55! Chapter.6!Robust. and. Scalable. Streaming. in. Heterogeneous. and. Dynamic. Scenarios.……………………………………………………………………………………………………..57! 6.1!Evaluating!Multiple!Description!Coding!with!Incentives!in!P2PTV!Systems!............!59! 6.1.1!P2PTV)Challenges)............................................................................................................................)60! 6.1.2!Proposed)Solution)............................................................................................................................)61! 6.1.3!Simulation)Results)...........................................................................................................................)63! 6.1.4!Conclusions).........................................................................................................................................)70! 6.2!Fuzzy!Redundancy!Adaptation!and!Joint!Source!Network!Coding!for!VANET! !Video!Streaming!...................................................................................................................................!70! 6.2.1!Video)Transmission)over)VANET)...............................................................................................)72! 6.2.2!MDC@based)Approach).....................................................................................................................)72! 6.2.3!Random)Linear)Network)Coding)Approach).........................................................................)73! 6.2.4!Proposed)Joint)Source)Coding)and)Network)Coding)Approach)...................................)74! 6.2.5!Proposed)Fuzzy)Logic)Redundancy)Control).........................................................................)75! 6.2.6!Fuzzification)of)Inputs)and)Outputs).........................................................................................)76! 6.2.7!Performance)Evaluation)...............................................................................................................)80!
Part!I:!Introduction!–!The!Basics! ! ! 3! Chapter.1 Motivation:. Towards. Future. Media. Internet. ! There!is!no!doubt!these!days!that!the!Internet!epitomises!a!cornerstone!tool!for! human!communications!but,!at!the!same!time,!it!has!triggered!new!challenging! problems.!Amongst!other!demands,!users!expect!higher!levels!of!performance,! security!and!reliability.!Internet!is!growing!beyond!its!original!expectations!and! its!fundamental!design!goals!based!on!the!endEtoEend!argument.!!As!a!result!of!its! gigantic! growth,! the! Internet! is! reaching! some! technological! and! operational! limits!imposed!by!its!architecture!in!its!attempt!to!give!full!support!to!the!new! requirements!introduced!by!the!increasing!number!of!new!services,!applications! and! contents.! However,! whilst! it! still! seems! unclear! how! the! current! Internet! architecture!will!handle!these!new!requirements,!the!fastEgrowing!need!for!new! strategies!in!the!network!that!can!guarantee!a!certain!level!of!Quality!of!Service! (QoS)!and!Quality!of!Experience!(QoE)!appears!to!be!at!this!stage!paramount.! ! One! of! the! most! significant!reasons! for! the! fast! growth! of! the! Internet! comes! from! multimedia! and,! concretely,! from! video.! Current! Internet! traffic! is! increasing! very! fast! mainly! due! to! the! proliferation! of! media! capable! devices,! media! services! and! their! demand! by! Internet! users.! Digital! production! techniques! are! rapidly! reshaping! the! industries! for! media! production! and! broadcast.!They! have! a! tremendous! impact! also! on! the! networking! industry! because! of! the! huge! number! of! networked! media! deployment! and! end! user! multimedia!capable!devices.!Some!analyses![1][4][20]!confirm!that!video!traffic! will! keep! growing! at! a! tremendous! pace.! Next,! we! give! some! numbers! and! predictions!in!Internet!video!growth.! ! • Internet! video! is! now! 40%! of! consumer! Internet! traffic,! and! will! reach! 62%!by!the!end!of! 2015,!not!including! the!amount!of!video! exchanged! through!P2P!file!sharing.!! ! • The!sum!of!all!forms!of!video!(TV,!video!on!demand,!Internet,!and!P2P)! will! continue! to! be! approximately! 90%! of!global! consumer! traffic! by! 2015.! ! • Internet! video! to! TV! tripled! in! 2010.! Internet! video! to! TV! will! be! over! 16%!of!consumer!Internet!video!traffic!in!2015,!up!from!7%!in!2010.! ! • VideoEonEdemand!(VoD)!traffic!will!triple!by!2015.! The! amount! of!VoD! traffic!in!2015!will!be!equivalent!to!3!billion!DVDs!per!month.! ! • HighEDefinition!(HD)!videoEonEdemand! will! surpass! standard! definition! by!the!end!of!2011.!By!2015,!highEdefinition!Internet!video!will!comprise! 77%!of!VoD.! !
Chapter!1!Motivation:!Towards!Future!Media!Internet! ! ! 4! Thus,! Internet! requires! efficient! methods! for! accelerating! the! sharing!and! reliable! distribution!of! this! big! volume! of! digital! media! according! to! different! users!need!and!context.!Emerging!digital!TV!services!offer!contents!in!multiple! ways! and! different! formats.! Popularity! of! video! services,! such! as! Youtube! or! Zattoo,!have!made!video!traffic!in!the!Internet!the!most!present!one.!Here,!PeerE toEPeer!(P2P)!systems!play!a!crucial!role!as!they!allow!distributing!multimedia! contents!in!a!scalable!and!robust!manner,!overcoming!the!limitations!of!other! technologies!such!as!multicast!by!creating!overlay!networks.!Even,!today,!there! are! appearing! new! revolutionary! transmission! techniques,! such! as! Network! Coding,!which!aim!at! introducing! novel! paradigms! to! increase! the!throughput! and!reduce!the!overall!delay!of!communications!whilst!proposing!an!alternative! to!classic!routing!and!avoiding!only!store!and!forward!functions!of!intermediate! nodes.! However,! these! kinds! of! techniques! are!difficult! to! introduce! in! the! current! Internet! in! an! efficient! manner.! They! can! be! deployed! at! application! level,!but,!in!so!doing,!they!cannot!offer!the!most!of!their!advantages.!! ! Moreover,!the!heterogeneity!of!media!capable!devices!connected!to!the!network! is!also!rising!(e.g.!handheld,!PC,!TV,!tablet!PC,!smartphones,!etc.)!and!it!usually! requires!the!creation!or!the!adaptation!of!services!and!resources!specifically!for! each!target!platform.!This!situation!leads!to!too!generic!and!static!systems!that! do!not!provide!the!content!adapted!to!the!final!device!or!too!complex!systems! that!require!a!big!effort!in!development!and!maintenance!tasks.! ! In!this!scenario,!the!necessity!of!contextEaware!systems!arises.!Their!goal!is!to! offer!services!adapted!to!the!context!of!users!(e.g.!device!capabilities,!network! conditions,!user!preferences).!These!systems!try!to!maximize!the!provisioning!of! QoS!whilst!improving!the!QoE!of!users,!thus,!allowing!a!more!efficient!usage!of! resources.!In!order!to!provide!adapted!media!communications!it!is!necessary!to! introduce! adaptation! and! transcoding! processes!that! are! transparent! for! the! users.!Adaptation!mechanisms!can!be!offered!by!end!services!or,!even,!by!the! network!itself.!Some!advanced!examples!of!these!kind!of!mechanisms!are!source! coding!techniques!such!as!Multiple!Description!Coding!(MDC)!or!Scalable!Video! Coding!(SVC)!that!allow!preparing!contents!to!be!transmitted!over!a!network!in! a!scalable!and!robust!manner,!adapting!communications!to!network!conditions! and! end! device!capabilities.! Furthermore,! there! are! different! quality! metrics! (objective! and! subjective)! that! can! be! introduced! in! streaming! systems! to! measure! the! degree! of! quality! being! obtained! in! an! audiovisual! transmission.! Thanks!to!these!measurements,!systems!can!react!when!quality!diminishes.!! ! Although!this!PhD.!Thesis!contributes!with!specific!media!streaming!solutions,! more!functionalities!to!achieve!real!seamless!media!communications!that!meet! users’! expectations!will! be! required.! Even! more,! there! exist! lots! of! existing! functionalities!that!could!be!combined!as!desired!to!achieve!specific!goals!under! certain!context!conditions.!In!addition,!new!advances!in!all!fields!will!introduce! new!mechanisms!that!will!improve!future!networks.!At!this!point,!the!question! is:!How!can!we!efficiently!introduce!all!these!existing!and!future!functionalities! (media!or!not)?!! !
Part!I:!Introduction!–!The!Basics! ! ! 5! In!recent!years!multiple!initiatives!have!contemplated!restructuring!the!current! Internet! architecture! in! order! to! cope! with! its! limitations.! Basically,! there! are! two! kinds! of! architectural! approaches! aimed! to! amend! current! Internet! deficiencies.! The! first! ones! are! evolutionary! architectures! that! propose! to! incrementally! introduce! improvements! over! the! current! Internet! architecture,! for!instance,!by!means!of!creating!specific!overlays!running!on!top!of!the!current! TCP/IP!architecture!(Figure!1.1).!This!view!fits!the!vision!introduced!by!contentE centric![5]!and!some!informationEcentric![6][7]!architectures.! ! ! ! ! ! Figure!1.1!Future!Internet!architecture!based!on!specific!overlays![5]! ! The! second! ones! are! revolutionary! (also! called! disruptive! or! cleanEslate)! architectures,! which!intend! to! introduce! new! architectures! from! scratch! covering! current! deficiencies! and! preparing! the! Internet! constant! and! fast! evolution,!motivated!by!the!rapid!growth!of!digital!contents,! devices,!network! technologies,!services!and!applications.!An!example!can!be!seen!in!Figure!1.2!a)! where!new!information!objects!can!be!created!and!Figure!1.2!b)!introducing!a! completely!new!architecture!not!based!on!layers.!! ! ! ! Figure!1.2!a)!Mapping!a!layered?based!Content?Centric!Internet!Architecture!into!Objects! [5],!b)!TARIFA!service?oriented!Internet!Architecture![8]!
Chapter!1!Motivation:!Towards!Future!Media!Internet! ! ! 6! Many!of!the!solving!strategies!introduce!novel!cleanEslate!architectures!that!do! not! take! TCP/IP! as! their! groundwork.! Following! this! trend,! ServiceEOriented! Architectures! (SOA)! and! ServiceEOriented! Computing! (SOC)! [58]! aim! at! presenting!paradigm!principles!that!can!pave!the!ground!to!implement!a!new! flexible!and!scalable!architecture!for!the!Future!Internet!(FI).!SOA!promotes!the! usage!of!services!to!support!the!development!of!rapid,!interoperable,!evolvable,! and!massively!distributed!applications.!! ! Furthermore,! in! [114]!authors! presented! a! very! disruptive! idea! on! how! to! establish!network!communications,!called!RoleEBased!Architecture!(RBA).!Their! proposal!was!to!avoid!existing!layered!structure!of!the!TCP/IP!stack!and,!in!so! doing,! extract! the! roles! or! network! functionalities! which! as! a! result! could! be! interconnected!without!current!layer!restrictions!(Figure!1.3).!Decomposition!of! current!protocols’!stack!allows!a!certain!granularity!of!network!functionalities! that!enables!their!selection!as!required.!This!is!the!first!step!to!provide!inherent! crossElayering!functions!to!a!Future!Internet!architecture.!! ! ! ! ! ! ! Figure!1.3!Protocol!stack!vs.!protocol!heap! ! Thanks!to!this!approach,!numerous!specific!and!complex!crossElayer!solutions,! such! as! the! improvement! of! switching! and! routing! especially! in! wireless! networks![133],!can!be!avoided.!An!architecture!that!does!not!have!layers!and! does!not! provide! interconnection!and! hierarchical!restrictions! could! solve!the! main! drawback! of! these! solutions,! as! is! the! impossibility! to! be! reused! for! different!purposes!in!varied!situations.!!! ! InterElayer! communication! in! current! TCP/IP! stack! is! completely! rigid.! This! rigidity,! and! its! collateral! effects,! has! not! only! led! to! different! crossElayer! approaches,! but! it! has! also! been! a! factor! in! the! appearance! of! subElayers! not! considered! in! the! original! design,! violating! the! layered! structure! of! the! stack! [115].! These! practices! pose! serious! interoperability! issues! and! provide! particular!solutions!to!every!problem!preventing!their!reuse.!Thus,!cleanEslate! [3]!Internet!architectures!appear!in!order!to!propose!novel!architectures!for!the! Future!Internet!taking!into!consideration!the!limitations!of!current!TCP/IP!and! the! lessons! learned! from! the! past.! Furthermore,! network! applications! and! services!continuously!evolve,!increasing!its!complexity!and!requirements,!while! diverging!from!the!endEtoEend!principle.!New!services!and!computing!paradigms! require! new! modes! of! interaction,! new! features! (identification,! contextE awareness,!seamless!service!discovery!and!composition,!etc.)!and!clean!solutions! to!known!open!issues!(mobility,!security,!flexibility,!etc.).!For!this!reason,!SOA! principles! introduce! promising! guidelines! to! develop! a! flexible! and! scalable! architecture! from! scratch! for! the! Future! Internet! that! will! cover! current! and! future!requirements,!including!multimedia!communications!for!a!Future!Media! Internet.!
Part!I:!Introduction!–!The!Basics! ! ! 7! Furthermore,! thanks! to! a! contextEaware! protocol! devised! to! establish! communications!as!well! as! service! negotiation! based! on! specific!conditions! of! the! network! and! the! user's! requirements,! providing! services! with! endEtoEend! QoS/QoE! can! likewise! be! guaranteed.! Due! to! its! malleable! nature,! this! will! certainly! propitiate! easy! adaptation! of! Future! Internet! communications! with! respect!to!already!wellEestablished!requirements!and!those!yet!to!come.! ! Instantiating!network!functionalities! only! when! and! where! necessary!helps!to! avoid!redundancy,!which!translates!into!more!efficient!communications!in!terms! of!data!throughput!and!resource!usage.!Improvements!on!QoS/QoE!provisioning! are!an!immediate!consequence!as!these!functionalities!can!be!tracked!down!and! selected!as! services!around!the!network! according!to!the!requirements!of!the! participants!involved!in!the!communication!and!particular!context!conditions.!As! an!example,!energyEaware!communications!can!be!provided.!Making!an!efficient! use!of!energy!or!resources!(computational,!storage,!etc.)!is!possible.!Saving!and! optimizing! resources! by! providing! only! minimum! (mandatory)! network! functionalities!and!resources!at!each!segment!of!the!network!would!be!a!feasible! fact.!! ! As! said,! several! initiatives! have! contemplated! restructuring! the! Internet! architecture!in!order!to!overcome!its!limitations.!However,!they!all,!no!matter!if! disruptive! or! not,! address! the! issue! from! network! protocol! perspectives.! The! view! in! this! PhD.! Thesis!is! that! the! Internet! has! suffered! because! its! original! design!principles!and!its!requirements!cast!into!common!protocols!like!TCP!and,! yet!today,!we!see!that!the!emerging!networking!approaches!try!to!define!their! own!protocol.!A!fresh!new!look!is!required.!! ! This!work!presents!such!a!fresh!new!look,!away!from!network!protocol!and!layer! rigidities.!It!adopts!a!radical!view!of!the!Future!Internet,!where!the!necessary! functionality! for! accomplishing! communications,! in! user! devices! and! in! the! network,!is!not!fixed!but!dynamically!composed!where!and!when!necessary,!as! appropriate! to! user! service! requirements,! network! transfer! capabilities! and! surrounding! context! in! the! user! and! the! network! environments.! This! work! provides!a!new!serviceEoriented!communications!framework,!enabling!adapted! communications! to! actual! user! needs,! in! highly! heterogeneous! environments,! seamlessly!across!different!underlying!network!technologies,!IP!or!nonEIP.!We! are!proposing!a!disruptive!network!architecture,!without!being!yet!another!clean! slate!approach.!! ! Composition!of!basic!networkElevel!services!supposes!a!cleanEslate!approach!to! the! Internet,! while! composition! of! higher! level! (transport! and! application)! services! prompts! for! an! evolutionary! approach.! Nevertheless,! composition! of! communication! services! manifests! itself! as! a! revolutionary! way! of! looking! communications! and! building! communication! systems.! The! main! innovations,! advancing!current!stateEofEtheEart:!! ! • First,! a! ServiceEOriented! communications! framework,! for! making! up! communication! functionality! as! needed,! at! network,! transport! and! application! levels,! out! of! existing! functionality.! Communication!
Chapter!1!Motivation:!Towards!Future!Media!Internet! ! ! 8! functionality!is!suitably!abstracted!to!decouple!its!capabilities!from!their! technologyEspecific!realisation,!thus,!it!is!viewed!as!a!service.!This!allows! to! incorporate! existing! functionalities! and! protocols! as! well! as! new! functionality!in!a!flexible!way!and!to!create!“intelligent”!networks!that!can! adapt! communications! to! context! conditions! and! users! requirements.! This! is! key! for! providing! adapted! transparent! media! services! transparently.! ! • Second,!by! extending! the! approach! at! the! connectivity! level,! a! novel! serviceEoriented! network! architecture! for! providing! endEtoEend! QoSE aware! data! transfer! services.! The! paradigm! of! InformationECentric! Networking! (ICN)![6]!is! thus!extended! to! apply! for! services.!Moreover,! this!architecture!is!completely!aligned!with!the!onEgoing!work!within!the! ISO!Future!Network!working!group.! ! • Third,!we! introduce!specific!media!services! that! will! allow!high! quality! and!seamless!content!delivery!in!a!transparent!manner.! ! This!PhD.!Thesis!introduces!the!main!concepts!in!the!field!of!media!streaming! and! Future! Internet! serviceEoriented! architectures! that! will! guide! the! readers! through!the!rest!of!the!work!in!this!first!part.!The!highlighted!concepts!guide!the! basic!research!topics!and!techniques!that!have!been!explored!to!make!different! contributions! in! order! to! advance! towards!the! realization! of! a! more! flexible! Future! Media! Internet.!The! second! part! of! this! work! describes! different! streaming!scenarios!where!we!have!provided!specific!solutions.!Although!they! are!very!distinct!scenarios,!all!of!them!present!heterogeneity,!network!dynamics! and!high!packet!loss.!!These!are!conditions!that!this!work!specifically!covers!and! makes!different!proposals!to!mitigate!their!effects.!Then,!the!third!part!of!this! PhD.!Thesis!introduces!the!envisaged!solutions!that!will!enable!a!flexible!serviceE oriented! Future! Internet! where! functionalities! are! abstracted! as! discoverable,! composable!and!adaptive!services.!Finally,!conclusions!are!inferred!in!part!four! and!future!work!is!highlighted.! !
Part!I:!Introduction!–!The!Basics! ! ! 9! Chapter.2 Multimedia. Delivery. Challenges. for. the. Future.Internet. ! This!section! describes! the!main! research! challenges!to! be! faced!in! the! Future! Internet!to!obtain!seamless!multimedia!communications![10]:! ! • Increasing!Bandwidth.!The!Internet!is!growing!and!advancing!in!several! dimensions:!the!number!of!users,!the!amount!and!size!of!the!content,!the! new! media! and! new! traffic! requirements! introduced! by! new! services.! Thus,! more! bandwidth! is! needed! in! the! endEtoEend!path! and! new! (e.g.! P2P)!delivery!methods!are!required.!! ! • Content! adaptation! and! personalization.! The! highly! heterogeneous! environment!in!terms!of!diversity!of!end!user!devices,!networks!and!user! preferences!will!remain.!To!ensure!a!real!seamless!access!to!new!media! applications,!it!is!desirable!that!the!network!itself!and!the!services!could! automatically! realize! content! adaptation! and! enrichment! inside! the! network.!! ! • Content?Centric! networks.! ContentEaware! realEtime! transmission! of! future!media!means!that!the!relative!importance!of!each!packet!towards! increasing!the!endEtoEend!utility!function!is!established.!That!is,!the!more! important!packets!should!be!better!protected!(by!allocating!appropriately! network! resources)! or! should! be! transmitted! first! in! a! scheduling! scenario.!! ! • Content/Information! driven! routing.! Internet!routing!system!shall!be! capable!to!consider!associated!routing!information!and!metrics!for!path! calculation!such! as! the! link! quality,!security!level,! energy! consumption,! priorities!or!location.!! ! • New! architectures! and! overlay! networks! for! content! distribution.! The!main!research!challenge!related!to!new!architecture!is!the!(dynamic,! autonomicity! and! selfEorganising)! creation! of! overlay! network! infrastructures!to!support!the!provisioning!of!media!services!to!endEuser! communities.!Some!of!the!issues!related!to!overlay!networks!have!a!wider! impact!and!span,!in!fact,!multiple!areas.!For!instance!the!specification!and! measurement!of!QoS!parameters!and!other!metrics!that!can!be!used!to! assess! the! underlying! communication! technologies!achieve! network! friendliness!(via!local!caches),!suggest!most!suitable!service!instances!for! the!endEuser.!A!possible!approach!to!deal!with!these!crossElayer!issues!is! to!gather!information!from!the!underlying!networks!and!combine!it!with! the!higher!level!quality!assessment!and!requirements!of!applications!to! adjust!the!overlay!networks.!! !
Chapter!2!Multimedia!Delivery!Challenges!for!the! Future!Internet! ! ! 10! • Quality! of! Experience.! Quantification! of! QoE! using! objective! and! subjective! measurements! remains! a! challenging! research! problem.! Furthermore,!the!relationship!between!network!level!QoS!measures!and! overall!QoE!must!be!studied.!! ! • Identity,! Trust,! Privacy! and! Security.! The! content! that! is! being! produced!and!distributed!is!increasing!rapidly.!Users!expect!to!be!able!to! take! advantage! of! the! future! widespread! availability! of! multimedia! content!and!access!to!virtual!worlds.!At!the!same!time,!they!need!to!feel! confident! that! their! security! and! privacy! is! being! protected.! The! increasing! complexity! and! scale! of! future! media! systems! will! make! the! problems!of!Identity,!Trust,!Privacy!and!Security!harder!to!solve.!! ! • Content! Encoding.! MultiElayered! Scalable! Video! Coding! (SVC)! offers! scalability;! MultiEview! point! Video! Coding! (MVC)! allows! for! different! views! of! video! streaming! without! drastically! increasing! the! data! rate;! Multiple! Description! Coding! (MDC)! offers! an! inherited! resiliency! mechanism!with!improved!PQoS!when!different!subEstreams!are!received! from!independent!physical!or!logical!paths.!However,!new!media!formats! and! encoding! methods! (also! network! coding! methods)! to! offer! High! Definition! (HD)! selectable! freeEviewpoint! content! coding! and! delivery,! considering! the! evolution! from! H.264! 2D! SVC/MVC! to! scalable! HD! 3D,! Multiview!Video!plus!Depth!(MVD)!and!selectable!free!Eviewpoint!video! with!interactive!virtual!panning/zooming.!Moreover,!new!media!formats! that! go! beyond! video! and! sound! to! even! other! senses! e.g.! feeling,! touching,!sensing.!! ! • In?network!content!enrichment.!Novel!methods!for!inEnetwork!content! enrichment! and! crossEnetwork! adaptation! will! be! needed! to! allow! for! optimal! use! of! available! resources! and! enriched! QoE.! By! dynamically! combining!the!inherited!content!scalability!(SVC!different!content!layers,! MVC!different!content!views!and!MDC!different!content!descriptions)!of! the! same! resource! (video! stream),! transmitted! from! multiple! sources! (different!servers!or!peers!in!case!of!P2P!streaming)!and/or!received!over! multiple! diverse! paths! or! networks! (use!the! MDC! features),! onEthe! fly! content! adaptation,! inherited! resiliency! and! enriched! QoE! may! be! achieved.!Reconstruction!of!the!content!segments!may!take!place!either! within!the!network!or!at!the!edge!of!the!network!(at!content!aware!edge! routers)! offering! transparent! streaming! to! lowEend! terminals! or! at! the! terminal! side! in! case! multiEnetwork! connectivity! is! available.! CrossE network!adaptation!and!inEnetwork!content!enrichment!especially!in!P2P! overlay!topologies,! will!offer!traffic!adaptation! (load!balancing!to!avoid! network!flooding),!optimal!use!of!available! resources! (bandwidth),! and! enriched!QoE.! !
Part!I:!Introduction!–!The!Basics! ! ! 11! Chapter.3 Future.Media.Internet.Enablers. ! Today,!Internet!represents!a!cornerstone!information!exchange!mean!and!is!the! main!communication!tool!not!only!in!the!business!world.!Internet!also!fosters! social!interactions.!With!the!proliferation!of!media!capable!devices!is!evolving! towards! the! provisioning! of! richer! and! more! immersive! media! experiences.! Different! stakeholders! such! as! users! consuming! media! services,! providers! offering! advanced! media! services! and! operators! dealing! with! an! enormous! volume! of! media! traffic! that! needs! to! be! delivered! in! an! efficient! manner! are! constantly! introducing! new! requirements.! Moreover,! recent! improvements! in! video! acquisition!and! content! creation! will! lead! to! massive! creation! of! new! multimedia!contents!and!Internet!media!applications,!including:!live!streaming,! 3D!contents,!immersive!environments,!online!gaming,!virtual!worlds,!etc.!Thus,! the!Future!Internet!will!have!to!deal!with!a!huge!amount!of!media!contents!and! will!need!to!be!able!to!give!solutions!to!its!seamless!delivery.!! ! The!Future!Media!Internet!will!not!only!enable!faster!ways!to!go!online.!It!needs! to!be!designed!to!overcome!current!Internet!deficiencies!and!to!flexibly!address! emerging!requirements!and!future!trends!in!the!area!of!seamless!media!delivery! such!as!these!ones:!! ! • MediaEagnostic!network!architectures.! ! • ContentEcentric! networking,! including! methods! for!content! finding! and! streaming.! ! • Support!of!heterogeneous!nodes!and!devices.! ! • UserEcentric/userEgenerated!content!provisioning.! ! In! this! scenario,! research! on! content! enrichment! and! distributed/community! overlay! networks! (peerEtoEpeer! and! cloud)! are! promising! fields! expected!to! bring!innovative!schemes!of!cooperation!and!interaction.!In!addition,!they!will! open! the! door! to! support! novel!applications,! like! virtual! collaboration,! immersive!environments,!personalised!media!services!(and,!in!general,!any!kind! of! service),! virtual! groups,! network! gaming,! edutainment,! etc.!Thus,! the! interaction! with! content! combined! with! interactive! and! multimedia! lookup! capabilities!across!distributed!repositories,!P2P!and!overlay!networks!and!the! dynamic! adaptation! to! the! characteristics! of! diverse! devices!are! expected! to! contribute!with!outstanding!improvements!for!the!Future!Media!Internet.! ! Furthermore,! advances! in! network! coding,! 3D! processing,! and! dynamic! adaptation!to!the!network!conditions!will!foster!the!appearance!of!applications! such!as!massive!multiplayer!mobile!games!and!virtual!worlds,!whilst!introducing! new!traffic!demands!and!constraints!on!network!architectures.! !
Chapter!3!Future!Media!Internet!Enablers! ! ! 18! services.!Service!composition!is!a!main!part!of!ServiceEOriented!Computing![57],! and! is! a! process! that! plays! a! key! role! in! ServiceEOriented! Architectures! (SOA! [58]).! ! The!Future!Internet!architecture!will!have!to!provide!high!levels!of!flexibility!and! scalability! in! order! to! face! current! Internet! limitations.! Thus,! an! architecture! where!services!represent!the!basic!components!will!be!considered,!as!they!can! be!combined!taking!into!account!the!specific!requirements!of!a!communication.! Obviously,! this! architecture! must! consider! context! parameters! from! different! entities:! users,! nodes,! services! and! networks.! In! addition,! there! can! be! considered! other! high! level! requirements! such! as! business! goals! or! socioeconomic!aspects!when!providing!a!service.! ! Service! composition! mechanisms! will! be! key! for! combining! those! required! services!and!create!the!composed!services!needed!at!each!node!along!the!endEtoE end!path.!Considering!the!ServiceEOriented!Architecture!proposed!in!the!TARIFA! project,! a! suitable! composition! mechanism! was! proposed,! selected,! validated! through! simulation! and! implemented! as! an! architectural! component! (Service! Composer).! However! it! remains! as! future! work! the! applicability! of! other! selection!and!composition!algorithms!(e.g.!based!on!fuzzy!logic!–!section!6.2.5!E! for! selecting! among! different! compositions,! services! and! mechanisms! [GP9][GP5])!in!order!to!compare!them!and!see!which!one!fits!better!for!specific! scenarios.! Considerations! such! as! response! time! and! performance! need! to! be! carefully!identified!in!order!to!apply!the!most!appropriate!one!in!each!situation! and!depending!on!the!kind!of!services!to!be!composed!(application,!transport!or! network!levels).!See!section!7.4!for!further!details.!! ! Although!this!thesis!is!focused!on!multimedia!services5,!any!other!service!can!be! composed!(e.g.!network!services!such!as!ACK!or!FEC!functionalities).!The!service! composition!process!must!be!generic!enough!to!compose!any!kind!of!service.! 3.2.2 ContextRawareness. ! ContextEawareness! is! also! a! key! feature! for! enabling! seamless! provisioning! of! multimedia!services!in!the!Future!Internet.!Multimedia!services!must!be!able!to! gather!context!information!from!different!entities:!users,!networks,!devices,!etc.! With!this!information,!services!can!adapt!communications!(server!side!or!inside! the!network)!in!order!to!maximize!the!experience!of!users!and,!in!addition,!to! improve! the! utilization! of! available! resources.! In! contextEaware! systems,! it! is! especially! important! to! provide! mechanisms! for! gathering! and! exchanging! context!data,!storage!and!management!context!data,!processing!of!context!data.! Concretely,!the!management!of!context!information!is!a!very!challenging!task!as! this!data!must!be!consistent!and!maintained!always!up!to!date!if!one!desires!to! get!the!best!possible!adaptation!of!a!service.! ! Although! this! thesis6!is! focused! on! multimedia! services,! other! services! can! be! represented!by!means!of!wellEdefined!interfaces!using!semantics!and!ontologies.! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 5"Generated"Publications:"[GP5]"[GP6]"[GP7]"[GP8]"[GP13]"[GP20]"[GP22]"[GP23]"
Part!I:!Introduction!–!The!Basics! ! ! 19! In! this! PhD.! Thesis! we! proposed! mechanisms! for! enabling! contextEaware! communications! in! IP! Multimedia! Subsystem! (IMS)Ebased! Next! Generation! Networks! (NGN)! [121][122][123][124]! to! improve! the! enrichment! of! the! services! provided! by! operators.! In! addition! we! suggested! mechanisms! for! sharing! context! parameters! during! the! process! of! discovering! neighbors! in! a! network! as! explained! in! [GP5].! In! this! specific! case! we! propose! to! use!the! beacons! exchanged! in! a! VANET! network! to! share! information! about! the! capabilities!of!nodes.!However,!these!functionalities!can!be!decoupled!from!the! proposed! scenarios! and! be! abstracted! as! independent! services! in! the! Future! Internet!to!be!used!on!demand.! ! ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 6"Generated"Publications:"[GP1]"[GP2]"[GP5]"[GP7]"[GP8]"[GP13]"[GP14]""[GP20]"[GP21]"
Chapter!4!Scalable!and!Robust!Streaming!for!the! Future!Internet! ! ! 20! Chapter.4 Scalable. and. Robust. Streaming. for. the. Future.Internet. ! In! the! current! Internet! the! major! part! of! the! traffic! is! video! and! the! most! bandwidthEhungry!applications!are!video!streaming!applications.!Specifically,!in! the! audiovisual! streaming! area,! the! popularity! of! P2P! realEtime! and! Video! on! Demand! (VoD)! streaming! applications! such! as! PPLive! [11],! PPStream![12],! UUSee![13],! Pando![14],! Zattoo![15]!has! been! demonstrated.! As! an! example,! PPLive! has! registered! over! 110! million! users,! 2! million! users! concurrently! connected,! offers! more! than! 600! channels! and! has! users! in! more! than! 200! countries.!In!addition,!Youtube![16],!a!worldwide!wellEknown!web!2.0!streaming! applications,! is! preparing! to! use! P2P! computing! in! order! to! improve! its! download! rate! while! reducing! transmission! costs! (especially! interesting! in! current!financial!crisis!time).!Thus,!PeerEtoEpeer/overlay!streaming!prototypes! and!their!implementation!are!especially!interesting!for!the!evolution!of!current! Internet!to!the!Future!Media!Internet.!! ! Nowadays,! P2P! supposes! a! major! part! of! current! Internet! traffic! (50%! of! Internet!traffic!in!2008!was!consumed!by!P2P!fileEsharing!applications![17][1])! and! keeps! growing!fast.! In! addition,! regarding! to! highEconsuming! P2P! video! applications,!statistics!in!one!of!the!biggest!Chinese!Internet!Service!Providers! (ISP)!show!that!PPLive!accounts!10%!of!the!total!Internet!backbone!traffic,!even! more!than!fileEsharing!(Bittorrent![18]!represents!the!8%!of!the!traffic).!Some! studies![19]!manifest!that!streaming!is!taking!over!P2P!users!for!video!content.! Thus,! video! and! peerEtoEpeer! contents! are! both! rapidly! increasing! Internet! bandwidth!demands.!Recent!reports!predict!an!“exaflood”![20]!from!advances!in! video!over!the!Internet,!rich!media!content,!and!User!Generated!Content!(UGC).! Moreover,!it!is!expected!that!by!2013,!the!sum!of!all!forms!of!video!(TV,!VoD,! Internet!video,!and!P2P)!will!exceed!90%!of!global!consumer!IP!traffic.!In!that! sense,! new! systems! and! studies! to! optimize! future! P2P! and! video! traffic! may! have!a!very!high!impact!on!the!future!of!the!Internet.!However,!for!the!Future! Internet! we! can! propose! different! types! of! mechanisms! for! facilitating! the! distribution!of!media.!One!approach!is!to!create!specific!overlays,!for!instance!for! sending!media!contents,!similar!to!the!overEtheEtop!!(OTT)!current!solutions.!In! this! PhD.! Thesis!we! also! propose! other! more! disruptive! solutions! based! on! services!to!provide!more!clean!solutions!to,!not!only!video!streaming,!but!also! known!limitations!of!the!current!Internet.!As!we!will!see,!previous!knowledge! and!existing!functions!will!be!reused!and!reorganized!to!give!solution!to!them.!In! section!7.5!and,!specially,!in!Chapter!8!more!details!are!given.! ! In! the! field! of! video! transmission,! live! streaming! introduces! new! challenging! problems!different!to!ordinary!file!sharing.!In!general,!media!streaming!solutions! have! different! features! that! determine! the! operation! of! the! applications.! For! example,!the!large!volume!of!media!data!along!with!stringent!timing!constraints,! the!dynamic!and!heterogeneous!nature!of!P2P!networks!and!the!unpredictable!
Part!I:!Introduction!–!The!Basics! ! ! 21! behaviour!of!peers.!These!effects!can!degrade!the!Quality!of!Experience!of!a!user! and,!sometimes,!makes!the!user!to!leave!the!platform.!! ! There!are!several!issues!in!multimedia!P2P!streaming!that!must!be!taken!into! consideration! when! facing! these! kinds! of! applications.! Some! of! them! are! the! following!ones:!managing!peer!dynamicity!(churn),!peer!heterogeneity,!efficient! overlay!network!construction,!selection!of!the!best!peers,!monitoring!of!network! conditions,! incentives! for! participating! peers!and! appropriate! video! coding! schemes.! ! The!nature!of!multimedia!content!makes!it!highly!sensible!to!the!transmission! over! networks! offering! nonguaranteed! transmission.! Therefore,! a! reliable! multimedia!transmission!system!must!involve!a!reliable!video!coding!scheme.!Its! use!is!more!than!essential.!Such!a!scheme!must!be!flexible!enough!to!meet!the! P2P!network!dynamics!and!its!heterogeneity.!! ! According!to!this,!P2P!streaming!applications!should!be!able!to!deal!well!with! heterogeneity!in!order!to!properly!work!in!different!types!of!networks,!support! different!devices!and! adapt! well! to!high!dynamic! environments.! In! addition! it! must!be!able!to!selfEadapt!in!presence!of!losses!or!when!context!changes!(for! instance!when!a!user!who!is!watching!a!TV!film!in!its!desktop!computer!wants!to! continue!watching!it!in!its!mobile,!this!is!known!as!session!mobility).!To!solve! that,!this!thesis!considers!coding!schemes.!Concretely,!it!describes!the!two!major! techniques! for! video! coding! in! this! type! of! P2P! environments! for! distributing! media!contents:!Multiple!Description!Coding!(MDC)!and!Scalable!Video!Coding! (SVC),!also!known!as!Layered!Coding!(LC).!! ! MDC!and!SVC!are!useful!in!the!case!of!varying!bandwidth!and!losses!or!erasures! due! to! congestion! (e.g.! Internet)! and! unrecoverable! errors! (such! as! wireless! channels).!SVC!provides!a!scalable!representation!that!enhances!rate!control!but! it!is!sensitive!to!transmission!losses.!On!the!other!hand,!MDC!provides!increased! resilience! to! packet! losses! by! creating! multiple! streams! that! can! be! decoded! independently.!! ! Their!features!are!of!special!interest,!specially!focusing!on!the!provisioning!of! media!resources!with!different!requirements! among! heterogeneous! peers! and! networks,!including!future!next!HD!content!or!3DTV.! ! P2P! media! streaming! architectures! are! presented! as! solutions! deployed! as! overlays!over!the!current!IP!network!in!order!to!enable!ALM.!P2P!technology! proposes! very! interesting! solutions! in! order! to! obtain! scalable,! robust! and! distributed!systems.! ! However,!nowadays,!video!contents!are!being!demanded!anywhere!and!anytime.! This!PhD!also!considers!emerging!and!challenging!communication!environments! like!VANETs.!The!challenge!of!video!streaming!over!VANET!can!be!interpreted! by!the!high!channel!errors!of!the!vehicles!in!urban!traffic!conditions.!The!high! packet!loss!and!limited!communication!range!of!the!vehicles!incur!frequent!link! disconnection! and! uneven! network! partition.! Many! of! these! effects! has! been!
Chapter!4!Scalable!and!Robust!Streaming!for!the! Future!Internet! ! ! 22! studied! also! in! P2P! networks,! thus,! both! environments! are! suitable! for! the! exploration!and!proposal!of!robust!and!scalable!streaming!mechanisms.! ! Media!streaming!applications!can!be!classified!according!to!the!delay!tolerance! just!as!shown!in![21].!RealEtime!applications!need!to!have!low!delay!tolerance! because! of! the! interaction! between! the! endEtoEend! users! (no! longer! than! a! 150ms! is! accepted! [22])! in! order!to! achieve! fluid! interactivity.! However,! live! broadcast! applications! typically! have! no! interactivity! requirements! and,! consequently,! longer! delays! are! tolerated,! commonly! up! to! 30! seconds.! This! delay!cannot!be!detected!without!interactivity!or!without!a!reference!point.!In! the!end,!onEdemand!media!applications!present!greater!delay!tolerance!because! the! existent! interactivity! is! limited! to! change! the! channel! or! due! to! VCRElike! control.!! ! Video! streaming! has! the! following! main! constraints:! scalability,! bandwidth! constraint,!realEtime!constraint!and!QoS.!These!characteristics!combined!yield!a! unique! application! scenario! that! differs! from! other! typical! peerEtoEpeer! applications,!including!onEdemand!streaming,!audio/video!conferencing,!and!file! download!(see!Table!4E1).! ! Table!4?1!A!Taxonomy!of!Peer?to?Peer!Applications!! Category! Bandwidth? sensitive! Delay?sensitive! Scale! File)download) No! No! Large! On@demand)streaming) Yes! Yes! Large! Audio/video)conferencing) Yes!/!No! Yes! Small! Live)broadcast) Yes! Yes! Large! ! The! key! problem! in! a! peerEtoEpeer! video! broadcast! system! consists! on! organizing!the!peers!into!an!overlay!for!disseminating!a!video!stream.!The!main! criteria! to! be! considered! regarding! to! overlay! construction! and! maintenance! operations!can!be!found!in!the!following!list:! ! • Overlay! efficiency:! The! construction! of! the! overlay! network! must! be! efficient,!because!the!streaming!video!requires!high!bandwidth!and!low! latencies.!However,!if!these!applications!are!not!interactive!then,!a!startE up!delay!can!be!tolerated.! ! • Scalability!and!Load!Balancing:!The!overlay!must!be!scalable!in!order!to! support!a!large!amount!of!receptors,!and!the!associated!overhead!must!be! reasonable!at!theses!large!scales.! ! • Self?organization:!The!overlay!must!be!built!in!a!distributed!manner!and! it!also!must!be!robust!enough!to!support!dynamic!changes!of!the!peers! which!take!part!in!the!overlay.!Moreover,!the!overlay!should!continuously! adapt! to! changes! in! the! network,! such! as! bandwidth! and! latency! variances.! The! system! should! be! selfEimproving,! that! is,! the! overlay!
Part!I:!Introduction!–!The!Basics! ! ! 23! should!evolve!towards!a!better!structure!as!more!information!becomes! available.! ! • Bandwidth! constraints:! ! The! system! depends! on! the! bandwidth! contribution! of! the! present! peers! so,! it! is! important! to! assure! that! the! total!contribution!of!the!bandwidth!of!a!user!must!not!exceed!its!access! bandwidth!capacity.! ! • Other!system!considerations:!Selection!of!a!suitable!transport!protocol! that!allows! overcoming! connectivity! restrictions,! such! as! NAT! and! firewalling!traversal.! ! Other! issues! to! consider! implementing! a! real! P2P! live! streaming! are! the! connectivity!between!peers!and!the!transport!protocols.!Further!information!can! be!found!in![23].!! ! 4.1 Types.of.Overlay. ! This!section! describes! the! most! common!types!of!overlays!introduced!by!P2P! streaming!systems:!treeEbased!and!meshEbased.!These!overlays!allow!to!provide! Application! Layer! Multicast! (ALM),! as! native! multicast! technology! can! not! be! deployed!in!all!the!Internet.!These!techniques!can!be!applied!OverETheETop!of! current!Internet!architecture!(OTT).!! ! Figure!4.1!shows!a!taxonomy!of!different!types!of!ALM!and!gives!some!examples! of!wellEknown!applications!using!them.!! ! ! ! Figure!4.1!Taxonomy!of!ALM!
Chapter!4!Scalable!and!Robust!Streaming!for!the! Future!Internet! ! ! 24! ! ! Figure!4.2!Multicast!taxonomy! In!literature,!P2P!systems!can!also!be!classified!into!structured!and!unstructured! [24].! This! classification! is! more! general! and! it! has! relation! to! the! way! they! organize! query! handling.! Unstructured! P2P! systems! allow! nodes! to! join! and! leave! freely! and! connect! and! participating! nodes! ad! hoc! into! random! graph.!! NARADA! [25]!and! NICE! [26]! are! two! examples.! Structured! P2P! systems! are! designed!with!the!aim!of!improving!the!efficiency!of!data!discovery,!maintain!a! logical!node!structure!and!impose!constraints!on!the!node!structure! and! data! placement!to!ensure!effective!data!discovery.!CAN![27],!Chord![28],!Pastry![29]! and!Tapestry![30]!are!some!examples.!Figure!4.2!depicts!a!multicast!taxonomy! where!it!is!possible!to!see!ALM!classified!in!structured!and!unstructured.! 4.1.1 TreeRbased.Overlay. ! In!treeEbased!systems![31]!the!overlay!is!hierarchically!organized.!Data!is!sent! from!the!source!node!to!the!rest!of!nodes!of!the!tree.!This!approach!is!known!as! sourceEdriven.!The!technique!used!to!send!data!all!along!the!tree!is!pushEbased,! that!is,!when!a!node!receives!a!data!packet,!it!forwards!the!packet!to!each!of!its! children.! ! There!are!several!requirements!for!treeEbased!systems.!It!is!desirable!the!system! to!build!an!efficient!tree!that!matches!the!underlying!network,!and!also!it!should! provide!a!swallowed!and!optimal!tree.!That!tree!must!be!maintainable,!that!is,!if! a!node!leaves!or!crashes,!all!the!branches!of!this!node!will!stop!receiving!packets,! in!order!to!repair!the!tree.!Thus,!a!shallow!tree!is!beneficial.!! ! Finally,!cycles!are!not!allowed!in!a!treeEbased!overlay!structure.!Moreover,!this! approach!has!an!important!weak!point:!the!failure!of!nodes,!especially!when!the! node!is!on!the!top!of!the!tree.!The!reason!is!that!this!“upperElevel”!node!failure! may! interrupt! data! delivery! to! an! important! part! of! the! tree,! momentarily! dropping!the!overall!performance.!A!shallow!tree!minimizes!this!problem,!but!
Part!I:!Introduction!–!The!Basics! ! ! 25! also! decreases! the! upload! rate,! since! most! of! nodes! are! leafs! and! the! upload! bandwidth!of!leafs!is!not!used.! 4.1.2 MeshRbased.Overlay. ! The!construction!of!meshEbased!overlays!is!an!unstructured!approach!where!any! explicit! data! delivery!structure! is! constructed! or! maintained.! Normally,! this! meshEbased!overlay!uses!a!dataEdriven!approach!for!exchanging!data.! ! DataEdriven!approach!is!guided!by!data!availability,!which!is!used!to!route!the! data! in! the! overlay.! With! pullEbased! techniques! (such! as! CoolStreaming! [32]),! each!node!keeps!a!set!of!neighbour!peers!(partners)!and!periodically!exchanges! its!data!availability.!Later,!one!node!may!retrieve!unavailable!data!from!one!or! more!partners!and,!at!the!same!time,!will!supply!its!available!data!to!its!partners.! Another! technique! that! can! be! used! is! the! pushEpull! based! approach,! such! as! GridMedia![33],!where!each!node!is!autonomous!and!pushes!data!to!its!partners! without!the!pull!request.!The!push!is!performed!on!timeEbased!prediction,!but!a! wrong!prediction!leads!under!flow!or!duplication!issues.! ! This!approach!is!robust!to!failures,!because!available!data!is!redundant!(kept!in! several!partners),!and!the!departure!of!a!node!simply!implies!that!its!partners! will! use! other! nodes! to! receive! segments! of! data! (local! impact! only).! The! potential!bandwidth!of!partners!can!be!totally!used!for!exchanging!data!between! partners.! In! meshEbased! applications,! the! scheduling! algorithm! is! a! key! component,!which!must!schedule!the!segments!that!are!going!to!be!downloaded! from! various! partners! to! meet! playback! deadlines.! It! is! the! brain! or! core! component!of!the!system.! ! Then,! an! interesting! question! is:! “Is! there! a! future! for! meshEbased! live! video! streaming?”! The! positive! answer! to! this! question! is! found! in! [34]!where! the! authors! conclude! that! meshEbased! systems! can! achieve! nearEoptimal! rates! in! practice!with!negligible!chunk!misses!(1%)!at!90%!maximum!stream!rate,!and! comparable! or! better! rate! than! other! treeEbased! systems! (AQCS! [35],! GridMedia).! ! Also,!meshEbased!overlay!is!still!an!attractive!choice!thanks!to!the!high!rates!it! offers.!It! follows! a! simple! unstructured! overlay! compared! with!difficult! to! maintain!treeElike!structures.!It!is!scalable!as!delays!grow!slowly!with!overlay! size!and! has! chunkEtolerance.! But! the! main! disadvantage! in! comparison! with! treeEbased!is!that!the!delay!remains!higher!than!some!treeEbased!systems.!! ! During!the!execution!of!this!thesis!several!contributions!have!been!made!to!a! P2P!delivery! system! named! CoolRuc! [36][23],!which! constructs! a!meshEbased! overlay!inspired!by!CoolStreaming.! 4.2 Content–aware.P2P.networks. ! Among!the!recent!works!appeared!in!the!contentEaware!P2P!networks,!we!could! remark!the!following!outstanding!approaches.!
Chapter!4!Scalable!and!Robust!Streaming!for!the! Future!Internet! ! ! 26! ! Active! Networks! [2]!can! be! viewed! as! a! proposal! where!data! packets! contain! code! fragments! with!specific!processing! logic! for! handling! the! packet! itself.! Although!Active!Networks!paradigm!introduces!a!powerful!proposal,!there!are! several! drawbacks! that! have! hindered! their! acceptance! and! deployment.! The! main!concern!is!security,!as!there!can!be!active!routers!running!malicious!code! hidden!in!active!packets.!The!other!primary!concern!the!control!of!the!network.! Network!operators!want!to!have!full!control!over!their!network!and!resources.! Next,!we!make!an!overview!of!other!contentEaware!networks.!! ! In!DONA!(DataEOriented!Network!Architecture![37])! users!can!request!named! data!from!the!network!by!using!the!FIND!primitive,!while!content!providers!can! publish!a!data!object,!which!will!be!served!to!the!users!by!using!the!REGISTER! primitive.!To!support!these!two!primitives,!DONA!introduces!specific!elements! called! Resolution! Handlers!(RH),! which! forward! content! to! the! users! as! an! overlay.!! ! Siena! (Scalable! Internet! Event! Notification! Architectures! [38])! proposes!a! generic! scalable! publish/subscribe! eventEnotification! service! similar! to! DONA.! Siena! specifies! a! general! model! of! contentEbased! addressing! and! routing! to! maximize!both!expressiveness!and!scalability.!! ! PARC! [39]!started!a! research! program! named! Assurable! Global! Networks! (AGNs),!where!they!focus!on!the!pointEtoEmultiparty!or!multipartyEtoEmultiparty! information!delivery!instead!of!traditional!pointEtoEpoint!communications.!The! main!feature!of!AGNs!is!that!the!security!will!reside!in!the!data!itself,!not!in!the! network!as!in!today!pattched!Internet.!Thus,!the!network!only!concerns!how!to! distribute! the! data! and! the! publishers! control! the! security! of! the! data.! Consequently,! the! network! will! be! a! huge! storage!facility!of! authenticated! content.!! ! OpenCDN! [40]!constructs! an! application! layer!tree! using!relay! nodes! that! distribute! multimedia! contents.! To! coordinate! relay! nodes,! OpenCDN! collects! clientErelated!information!from!relay!nodes!and!decides!the!best!relay!node!for!a! newly!joining!client!applying!specific!algorithms.!! ! Slightly!different!to!OpenCDN,!Oscar![41]!collects!sampling!information!of!key! distribution!during!the! P2P! overlay! construction! and! uses! that! information! to! choose!routes!based!on!smallEworld!graphs.!! ! COCONET! [42]! aims! to! utilize! semantic! data! tagging! to! provide! content! level! information!that!will!be!used!by!the!network!for!data!stream!forwarding.!! ! Lastly,! Akamai's! EdgePlatform! [43]! is! a! network! of! more! than! 40,000! secure! servers!with!proprietary!software,!aiming!to!optimize!routes!and!replicate!data! dynamically! to! deliver! content! and! applications! more! quickly,! reliably,! and! securely.! Akamai‘s! approach! is! to! eliminate! long! routes,! by! replicating! and! delivering!content!and!applications!from!servers!close!to!end!users.!
Part!I:!Introduction!–!The!Basics! ! ! 27! 4.3 Advanced. Media. Coding. Techniques. for. the. Future. Internet. ! During!this!PhD.!Thesis!we!studied!different!video!coding!techniques!to!prepare! the!data!to!be!transmitted!over!the!network!in!order!to!face!the!effect!of!losses,! dynamicity! of! the! nodes,! dynamic! context! conditions! and! network/device! heterogeneity.! We! mainly! considered!coding! techniques! for! distributing! HQ! contents!over!the!Future!Internet.!These!coding!techniques!could!be!represented! as!specific!functional!components!(called!services)!that!could!be!implemented!by! specific!nodes!in!a!network!using!the!ServiceEOriented!Architecture!introduced! in!(Chapter!7).!Then,!thanks!to!the!mechanisms!described!in!section!7.3!and!7.4! they!will!be!used!to!provide!adapted!communications!in!a!transparent!manner! for!the!end!users,!as!they!could!be!discovered!and!invoked!as!required!although! the! requester! node! or! provider! node! does! not! implement! them! but! a! node! between!them!or!“inEside”!the!network.! ! There!are!basically!two!techniques!that!currently!are!being!studied!to!be!applied! to!a!P2P!system!able!to!achieve!our!goals!in!terms!of!scalability!and!robustness:! Source!Coding!(SC)!and!Network!Coding!(NC).!Well!known!examples!of!source! coding!techniques!are!Multiple!Description!Coding!(MDC),!Scalable!Video!Coding! (SVC)! and! Multiview! Video! Coding! (MVC).! In! general,! P2P! systems! have! well! known! advantages! in! terms! of! scalability,! robustness! and! faultEtolerance.! However,! if! all! users! receive! and! serve! data,! the! probability! that! one! stream! breaks! is! higher! because! of! the! replication! rate! of! the! video! streams.! Furthermore,! the! connectivity! to! the! network! and! the! different! paths! used! is! strongly!variable.!MDC,!SVC!and!NC!are!coding!techniques!that!can!be!applied!in! media!streaming!for!situations!where!the!quality!and!availability!of!connections! vary!over!time.!! 4.3.1 Source.Coding. ! This!section!introduces!the!following!main!source!coding!techniques:!MDC,!SVC! and!MVC.! 4.3.1.1 Multiple,Description,Coding,(MDC),and,Scalable,Video,Coding,(SVC), ! MDC! [44]!is! a! source! coding! technique,! which! encodes! a! signal! (audio/video)! into! a! number! of! N! different! subEbitstreams! (where! N! ≥2).! Each! bitstream! is! called! descriptor! (or! description),! as! shown! in! Figure! 4.3! a.! The! descriptors,! which!are!all!independently!decodable,!are!meant!to!be!sent!through!different! network!paths!in!order!to!reach!a!destination.!The!receiver!can!play!the!media! when!any!of!the!descriptors!is!received.!!
Chapter!5!Future!Internet!from!a!Service!Perspective! ! ! 34! therefore! decide! which! turns! out! to! be! more! appropriate! according! to! its! requirements.! ! We! believe! that! a! new! architecture! model! should! be! network! and! technology! agnostic.! This! is! a! key! feature! for! a! better! interconnection! of! heterogeneous! networks! and! devices! and! should! consequently! be! understood! as! a! crucial! consideration!for!the!development!of!the!FI.!Such!a!shift!is!required!in!order!to! deal! with! the! increasing! network! heterogeneity,! including! a! wide! range! of! services,!devices,!users!and!physical!technologies.!We!need!to!be!able!to!cope! with!different!conditions!throughout!the!complete!delivery!chain,!and!thus!the! intermediate!nodes!must!be!aware!of!the!environment!and!be!able!to!adapt!to! any! sudden! change! in! the! network.! SOA! presents! a! paradigm! suitable! for! deploying! these! concepts.! Relying! on! a! set! of! principles! for! services! (loose! coupling,! abstraction,! reusability,! autonomy,! statelessness,! discoverability! and! composability),! architectures! based! on! services! are! more! flexible! and! able! to! react! more! efficiently! to! changes! (context,! business,! etc.)! as! compared! to! the! classic!monolithic!TCP/IP!stack.!Such!flexibility!and!adaptive!capability!will!be! achieved!by!means!of!contextEaware!service!composition!mechanisms.!! ! Next,!Figure!5.1!shows!a!conceptual!serviceEoriented!architecture,!highlighting! the! service! composition! components! that! enable! creating! adapted! communications.! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Figure!5.1!Conceptual!architecture!of!a!SOA?based!architecture! ! Herein,!we!think!that!RBA!and!SOA!offer!complementary!guidelines!for!defining! a!flexible!new!architecture!based!on!the!decomposition!of!protocols!into!roles!or! services!and!their!recomposition!according!to!specific!communication!goals!and! conditions.! However,! the! verification! of! the! feasibility! of! RBA! is! still! an! open! issue.! Whilst! it! promises! higher! levels! of! flexibility,! it! also! introduces! new! processing! requirements! and! structural! changes! in! comparison! to! layered! approaches.!RBA!exposes!how!a!packet!will!be!conformed!using!this!strategy!and! how! some! roles! could! be! interconnected! within! a! node,! but! in! a! real! communication! it! entails! other! issues! that! remain! unsolved.! One! of! the! most!
Part!I:!Introduction!–!The!Basics! ! ! 35! important!being!how!different!nodes!will!understand!the!proposed!heaps!if!they! do!not!follow!a!hierarchical!encapsulation!as!TCP/IP!does.!! ! In!order!to!configure!who!should!execute!a!role,!implementing!mechanisms!to! discover! nodes! and! their! functionalities! is! outstanding! especially! when! considering! heterogeneity! of! interconnected! devices.! Consequently,! a! service! identification!scheme!integrated!with!naming!and!addressing!techniques!should! be! defined! to! seamlessly! provide! services.! This! scheme! must! be! flexible,! lightweight!and!scalable!because,!unless!these!properties!are!met,!there!is!a!fair! chance! to! incur! in! the! same! problems! we! encounter! these! days.! Enabling! semantic! service! search! will! improve! the! discovery! of! services,! therefore! allowing! users! to! seek! a! service! or! content! based! on! specific! and! expressive! attributes.!For!example,!using!human!readable!attributes,!a!user!would!be!able!to! look! for! the! closest! colour! printer! that! has! a! minimum! number! of! sheets! available.! ! Last!but!not!least,!regarding!the!format!of!identifiers,!we!must!bear!in!mind!that! each!router!in!the!core!of!a!network!handles!hundreds!of!gigabits!of!information! per!second.! The!built!in!hardware!for! routing!each!packet!is!dedicated! and!is! responsible!for!analyzing!the!packet!ID!and!determining!where!each!packet!must! be!routed.!Hardware!is!restricted!by!an!important!limitation.!It!can!efficiently! handle! sizeEfixed! addresses,! while! the! new! addressing! scheme! must! be! as! flexible!as!possible.!FI!routing!must!take!into!account!these!constraints.! ! Summarizing,! an! Internet! based! on! services! and! the! proposed! premises! has! some! relevant! technical! challenges![131]![134]! that! must! be! tackled! such! as! dynamical! service! composition! of! functionalities,! contextEawareness! and! automaticity,! requester! empowerment! during! service! selection! and! routing,! semantic! search! and! service! identification.! Some! of! them! are! faced! by! the! proposed! solution,! specifically! for! covering! challenging! multimedia! delivery! scenarios.! ! 5.1 Service.Definition.and.Classification. ! In! literature,! it! is! possible!to!find! different! definitions! for! the! term! “service”! (RFC2165EService!Location!Protocol,!ATIS!SON,!W3C,!OASIS,!etc.).!In!this!PhD.! Thesis!we!adopt!the!following!definition:! ! “A)service)is)any)process,)function)or)task)that)provides)networking,)computational) or) informational) resources) on) request) which) is) represented) by) means) of) well@ defined)interfaces”) ! With!this!definition!we!can!abstract!that!a!service!can!be!provided!by!any!type!of! entity/node!regardless!their!characteristics!such!as!hardware,!software,!virtual,! physical,!etc.!Moreover,!a!service!itself!can!be!of!very!different!natures,!ranging! from! a! specific! computing! function! (e.g.! audio/video! coding! or! delivery)! or! storing!data!to!providing!resources!and!tasks!to!interconnect!different!entities.! Thus,!covering!from!lowElevel!network!services!like!MAC,!ACKs!and!sequencing!
Chapter!5!Future!Internet!from!a!Service!Perspective! ! ! 36! to!endEservices!or!applications!like!data!files!(e.g.!text,!music,!video)!transfers!or! web!services![129].!! ! Figure! 5.2! shows! a! taxonomy! with! a! possible!services! classification.!This! taxonomy!is!based!on![129].!! ! ! Figure!5.2!Service!Taxonomy! ! Regarding!service!granularity!they!can!be!classified!as!atomic!or!composed.! ! • Atomic! Services!are!the!core!of!this!architecture.!They!are!the!building! blocks!(roles)!used!to!establish!communications!and!to!deliver!data!in!a! selfEadaptable,! selfEconfigurable! and! contextEaware! way.! Each! atomic! service!provides! one! concrete! and! wellEdefined! networking! function! (along! with! the! reverse! function,! if! any).! Different! algorithms! and! implementations!of!an!atomic!service!may!exist!(e.g.!different!congestion! control! algorithms),! and! coEexist! in! the! same! node,! using! attributes! to! both!describe!the!different!possibilities!and!to!tune/configure!the!atomic! service!in!order!to!use!it!to!fulfill!specific!workflows!needs.!As!explained! in!section!7.2,!Atomic!Services!will!abstract!specific!implementations!of! different! functionalities.! The! specific! implementation! will! be! called! Atomic!Mechanism.! ! • Composed! Services!are!network!applications! with!a!wider!scope!than! just!establishing!communications!(e.g.!sensing!service,!directory!service,! file!transfer,!instant!messaging,!presence,!etc.).!Each!composed!service!or! application! implies! consuming! different! atomic! and! sometimes! other! composed!services,!with!possible!dependences!appearing!between!them.! In! addition,! they! can! involve! one! or! more! nodes,! depending! on! the! complexity!of!the!service.! !
Part!I:!Introduction!–!The!Basics! ! ! 37! – Execution/Distribution:! ! •!!Isolated:!local!execution!of!the!service.! ! •! Distributed:! execution! distributed! between! two! nodes,! regardless! their!location.!It!includes!support!for!endEtoEend,!section!and!hopEbyEhop! distribution/allocation!of!services.! ! – Scope:! services! can! be! applied! with! different! scopes! or! considerations! depending!on!the!desired!result.! ! •!Network:!services!are!executed!to!optimize!communication!according! network!context.! ! •!Application:!services!are!executed!to!optimize!application!behaviour! and! interconnection! to! meet! application! requirements! according! to! context!characteristics.! ! – Usage:!rules!governing!the!service!usage.! ! •! Mandatory:! usage! of! this! service! is! mandatory! as! it! is! basic! for! establishing!a!communication!(e.g.!forwarding).! ! •! Optional:! usage! of! this! service! is! optional,! its! usage! will! depend! on! application!requirements!and!context!characteristics.! ! – Purpose:!which!is!the!purpose!of!the!service.! ! •!Delivery:!to!deliver!data!between!two!different!entities!involved!in!the! delivery!chain!(they!can!be!adjacent!or!nonEadjacent!nodes!or!they!can! be!two!end!applications,!depending!on!the!scope!of!the!service).! ! •!Mobility:!services!related!to!application,!user!and!node!mobility.! ! •!Storage:!services!dealing!with!the!storage!of!data.! ! •!Security:!services!dealing!with!security!issues.! ! •! Data! Adaptation:! services! dealing! with! adapting! and! transforming! data! for! different! objectives,! interoperability,! customization! and! optimization!of!data.! ! •! Addressing:! services! dealing! with! the! identification! and! labeling! of! resources.! ! •!Management:!services!dealing!with!the!management!of!the!different! entities!in!the!network!(nodes,!applications,!services,!etc.).! !
Chapter!5!Future!Internet!from!a!Service!Perspective! ! ! 38! •!Signaling:!services!dealing!with!interchange!of!signaling!and!control! data.! ! •Presentation:! services! dealing! with! the! presentation! of! contents! and! user/application!interfaces.! ! – Order:! order/existence! of! the! AS! in! workflow! composition! may! be! dependent!of!another!service.! ! •!Dependent:!needs!the!use!of!another!AS.! ! •!Independent:!no!need!of!other!AS!execution.! ! In! this! PhD.! Thesis! we! proposed! some! solutions! for! enabling! adapted! media! streaming!communications!in!the!current!Internet.!All!these!contributions!can!be! seen!as!new!functional!components!abstracted!as!services.!Some!examples!are:! ! • Signalling! services:! functional! components! for! establishing! communications!such!as!SIPEbased!functionalities!(Invite,!Register,!Info,! etc.).! ! • Adaptations! services:!functional!components!for!adapting!video/audio! data! according! to! user! needs! such! as! coding,! decoding,! transcoding,! quality!assessment,!etc.! ! • Delivery!services:!functional!components!for!optimizing!the!delivery!of! data! in! a! network! such! as! enabling! intermediate! nodes! to! combine! incoming!data!packets!(Network!coding).! ! Generalizing!this!concept,!all!the!existing!knowledge!(functionalities)!could!be! then!abstracted!as!services!and,!if!present!in!the!network,!be!used!(by!means!of! specific!composition!mechanisms)!to!meet!user!requirements!and!provide!truly! QoE!to!the!end!users.! ! 5.2 Problem.Statement.and.Requirements.of.a.ServiceRbased. Future.Internet. ! A!new!concept!and!definition!of!services!for!the!Future!Internet!will!be!closely! connected! to! the! innovation! of! network! environments! and! users.! Futuristic! capabilities! that! will! be! provided! by! Future! Internet! and! complex! and! personalized!requirements!of!users!can!drive!that!services!can!be!selfEevolved! continuously.! Considering! this,! the! service! composition! technology! should! be! also!extended!to!cover!possible!changes!derived!from!the!service!and!network! evolution.! ! New! distributed! software! systems! have! become! more! dynamic,! allowing! transparent!distribution,!selfEreconfiguration,!portability,!etc.!Based!on!that,!new!
Part!I:!Introduction!–!The!Basics! ! ! 39! paradigms! deviated! from! the! endEtoEend! principle! have! emerged,! such! as! Pervasive! and! Ubiquitous! Computing,! the! Internet! of! the! Things!(IoT)!or! the! Internet!of!Services!(IoS).! ! The! continuous! evolution! of! network! application! and! services! increased! its! complexity,! adding! more! and! more! requirements! during! the! process.! New! features! (identification,! contextEawareness,! seamless! service! discovery! and! composition,! etc.)! are! required! in! order! to! match! with! new! services! and! new! modes! of! interaction.! Additionally,! these! features! should! help! to! offer! clean! solutions!to!known!open!issues!(e.g.!mobility,!flexibility,!security,!etc.)![236].! ! Nowadays,! network! services! are! executed! without! taking! into! account! the! characteristics!of!the!surrounding!context.!Consequently,!current!architecture!is! unable! to! provide! information! of! the! underlying! network! technologies,! the! capabilities!of!the!devices!involved!in!a!communication!or!the!characteristics!of! the!users!interacting.! ! In! this! scenario,! similar! or! redundant! network! services! (e.g.! error! correction,! retransmission,!encryption)!are!executed!at!different!levels!making!a!bad!usage! of! computing! and! network! resources! and! sometimes! reducing! communication! performance.! Even! more,! in! specific! environments,! the! execution! of! certain! functions!can!be!inefficient!for!the!correct!operation!of!an!application!or!network! service.!A!clear!example!would!be!TCP’s!congestion!control!in!wireless!networks! specially!in!media!communications.!This!provokes!to!modify!existing!protocols! in! order! to! adapt! them! to! environments! with! certain! restrictions.!However,! a! general!trend!nowadays!is!to!use!TCPEbased!protocols!such!as!HTTP!to!deliver! all!kind!of!data!in!any!environment!due!to!the!presence!of!NAT!and!Firewalls! elements! that! limit! the! access! of! certain! protocols! to! networks.! This! occurs! because! of!the! strongly! restricted! design!of! current! protocol! stack! interElayer! communication.!! Furthermore,! the! introduction! of! strategies! in! the! network! that! guarantee! a! certain!level!of!Quality!of!Service!(QoS)!and!Quality!of!Experience!(QoE)!should! be!as!well!a!critical!need!in!the!Future!Network!(FN).! ! Taking!these!problems!into!account,!there!are!some!features!that!Future!Internet! should!inherently!integrate!in!its!architecture.!Several!challenges!must!be!faced! for!designing!an!integral!solution!for!the!service!composition!in!FN!that!allows! overcoming!the!current!technologies!and!deficiencies:! ! • Dynamic! network! composition.! Establishing! network! functions! as! services!that!can!provide!and!access!easily!to!all!this!information!should! be!an!essential!feature!in!FN,!in!order!to!have!a!network!that!can!adapt!to! current! requirements! and! new! ones! that! eventually! rise! up.! A! greater! modularity! of! the! network! means! a! better! adaptation! to! new! communication! paradigms,! while! decreasing! the! complexity! of! the! architecture.!Unlike!static!service!composition,!services!can!be!specified! at!run!time.!It!means!that!the!capabilities!of!the!service!can!be!extended! dynamically,!allowing!runtime!reEcomposition,!decomposition!of!services,!
Chapter!5!Future!Internet!from!a!Service!Perspective! ! ! 40! and! dynamic! adaptation! in! case! of! changes! in! context! (services! and! resources)!involved!in!composite!services.! • Network!flexibility.!Network!service!composition!should!facilitate!in!FN! the!integration!of!new!functionalities!into!the!network.!Instead!of!tight! coupling!of!functionalities!within!endEtoEend!protocols,!network!services! are!deployed!on!arbitrary!nodes,!are!loosely!coupled!and!provide!their! service!to!arbitrary!other!functional!blocks.!This!design!originates!in!the! service! oriented! architecture! approach! and! requires! means! of! service! description,! discovery! and! composition.! This! design! approach! reduces! management!efforts!and!provides!a!flexible!framework!to!integrate!new! network!services.!!! • Inherent! cross?layer! information! exchange.!CrossElayer! means! that! functionalities!can!be!adjusted!based!on!the!interaction!between!different! layers.!FN!should!allow!arbitrary!composition!and!information!exchange! between!network!services,!thus!incorporating!the!benefits!of!crossElayer! design!architectures.! • Context?awareness! in! service! composition.!FN! should! support! the! context!management!to!provide!customized!and!context!based!services.! Thus,!different! kind! of!context!including!user,! device,!service,!resource,! and! network! can! be! used! for! discovering,! selecting,! allocating! and! composing!services!to!participate!in!the!composition!process.!! • Requester! empowerment! in! service! choice! and! routing.!Service! requester!should!have!more!control!over!the!contents/service!that!wants! to!consume.!This!control!must!be!reflected!in!flexible!routing!and!service! selection! according! to! requester's! service! definition.! Consequently,! FN! must!build!a!network!architecture!that!provides!more!intelligence!to!the! networkEside! whilst! still! leaving! decisionEmaking! processes! at! the! endE points.!! • Semantic!Searches!oriented!to!service/resource.!FN!must!be!focused! on! a! service/dataEcentric! approach! that! allows! executing! the! search! of! services!and!resources!based!on!the!requester!requirements.!This!implies! that! future! network! must! be! able! to! create,! discover,! negotiate! and! consume!composite!services!in!a!flexible!and!contextEaware!way.! • Resources! and! services! identification.!Every! flow! over! FN! must! be! routed!based!on!its!requirements.!Therefore,!each!flow!must!be!identified! in! order! for! nodes! along! the! route! to! cooperate! and! negotiate! autonomously,!for!guaranteeing!the!minimum!QoS!parameters!of!it.! • Environmental! heterogeneity.! Heterogeneity! of! nodes,! networks! and! services!add!another!level!of!complexity!to!service!composition!process! for! FN.! If! instances! of! a! service! are! executed! in! nodes! with! different! capabilities! and! network! access! links,! every! service! instance! should! be! evaluated! individually,! and! attributes! of! a! specific! one! could! not! be! applied!to!one!of!another!node.!!!
Part!I:!Introduction!–!The!Basics! ! ! 41! • Attribute! acquisition.! Composition! process! should! be! based! on! the! attributes!of!the!services!(and!their!concrete!implementation),!but!extract! the!complete!and!updated!information!of!a!service!is!extremely!difficult.!It! should!require!a!previous!empiric!process!extracting!information!about! how!the!inclusion!of!a!service!or!another!affects!in!terms!of!delay,!error! rate,!and!each!QoS!parameter!that!are!relevant!for!a!complete!solution! (the!whole!chain!of!services!from!requester!to!end!service!provider).! • Service! Validation.! Service! composition! should! be! validated! to! guarantee!consistency!and!reliability!of!services!in!FN!in!such!a!way!that! it! does! not! hamper! the! entire! process! of! service! composition! and! heterogeneity! of! FN.! Each! service! needs! to! be! validated! its! correctness! and! consistency! before! registering! itself! with! FN! and! composition.! Services! and! composition! process! must! be! defined! and! described! with! languages!based!on!formal!semantics.!! • New! Business! Models.!Internet! brings! opportunities! to! create! new! business!models!according!to!novel!services,!applications!and!capabilities! demanded!by!users.!Hence,!it!is!necessary!to!introduce!innovative!models! for!costing!and!pricing.!FI!architecture!should!also!provide!a!transparent! framework! that! permits! service! consumers! and! providers! to! interact,! establish! agreements! and! satisfy! their! goals! [134].! The! new! network! services! can! also! provide! a! new! business! model! for! network! service! providers.! Nowadays! network! providers! are! in! strong! competition! because! they! all! offer! the! same! commodity! service! E! packet! transport.! Through!new!network!services! the! network! providers! can! differentiate! from!competitors!and!it!guarantees!higher!margins.!The!network!services! can! be! offered! as! premium! services! for! customers! and! overEtheEtop! service! providers.! In! this! way! network! providers! can! also! benefit! from! applications!that!run!over!their!infrastructure.!Because!service!providers! and!customers!can!choose!between!the!services! this!will!also! lead!to!a! thriving! evolution! of! network! services! where! the! best! performing! and! efficient!services!will!survive![130].!! 5.3 Relevant. Examples. of. Service. Composition. in. Future. Internet.Projects.and.Standardization.Activities. ! Internet!faces!an!architectural!crisis.!Load!on!the!network!is!rapidly!increasing! with!the!appearance!of!new!users!and!applications.!!Since!Internet’s!inception,! 40!years!ago,!lots!of!patches!have!appeared!aimed!to!amend!the!deficiencies!of! the!current!Internet.!Thus,!its!architecture!is!becoming!more!and!more!ossified! and! complex.! Some! researchers! are! questioning! the! principles! behind! the! original! design! of! the! Internet! that! motivates! its! patchEbased! evolution.! However,!nowadays,!it! remains! unclear! how! the! current! Internet! architecture! will!be!able!to!cope!with!all!these!new!requirements.! ! There!are!two!big!approaches!in!current!research!trying!to!solve!this!doubt.!On! one! hand,! evolutionary!approaches!and,! on! the! other! hand,! disruptive! approaches.!From! our! point! of! view,! it! is!difficult!to! believe! that!evolutionary!
Chapter!5!Future!Internet!from!a!Service!Perspective! ! ! 42! approaches!will! allow! solving!all! the! issues! and! challenges!that! the! current! Internet! introduces!(e.g.! multihoming,! crossElayer! interactions,! routing! table! scalability,!middleEboxes,!QoS,!subElayer!proliferation,!mobility,!security,!etc.)!in! an!efficient!manner!whilst!providing!enough!flexibility!to!adopt!future!services! and! requirements! which! are! yet! unknown! [115][135][136].! Most! of! the! deficiencies!of!current!Internet!derive!from!the!original!design!principles!behind! the!TCP/IP!layered!architecture!(monolithic,!layered!and!hierarchical!stack).!The! Internet!was!not!designed!for!its!current!uses.!Consequently,!we!strongly!think!it! is!better!to!redesign!the!network!architecture!from!scratch!considering!current! requirements,! reusing! and! adapting! all!the! previous! knowledge! and! advances! made! during! the! life! of! Internet!and! providing! clean! solutions! to! known! problems.! Therefore! we! advocate! for! a! cleanEslate! redesign! of! the! Internet! architecture!based!on!service!composition!approaches.!This!is!part!of!the!work! we!have!been!doing!in![8][209][GP13].!!! Recently,! there! is! a! big!discussion! on! network! architecture! design,! protocol! modularization!and!redesign!of!the!Internet.!The!MIT’s!New!Arch!project![137]! introduced!some!interesting!and!relevant!work!on!new!network!architectures! and!protocols.!The!most!groundEbreaking!output!of!this!project!was!the!proposal! of! the! RoleEBased! Architecture! (RBA)! [114].! This!nonElayered! and! modular! architecture!build!around!the!concept!of!roles!is!one!of!the!bases!of!this!research.! RBA!establishes!that!a!role!can!be!seen!as!a!communication!building!block!that! performs!some!specific!function!relevant!to!forwarding!or!processing!packets.!!It! is!remarkable!that!in!this!work!roles!receive!can!be!mapped!to!the!term!services.! This! concept! allows! establishing! relations! amongst! network! components! in! order! to! achieve! a! specific! communication! goal.! Even,! we! can! establish! new! relationships!on!demand!according!to!specific!needs.!In!so!doing,!nodes!are!able! to! implement! the! different! roles! required! for! a! certain! communication.! Some! examples!are!packet!forwarding,!fragmentation,!flow!rate!control,!segmentation,! request!web!page,!coding/decoding!of!data!or!enable/disable!caching,!etc.!RBA! proposes!the!replacement!of!current!protocol!stack!by!a!protocol!heap,!where! each!node’s!realm!of!execution!in!the!protocol!heap!is!limited!to!its!supported! roles.!Hence,!this!absence!of!layered!design!implies!that!we!need!new!rules!for! role!combination,!modularity,!header!structure!and!ordering!for!the!processing! of!metadata,!and!encapsulation.!! ! In! this! work,! we! adopt!an! approach! based! on! the! microEmodularization! of! protocol,! network! and! processing!functionalities.! This! is! a! quite! common! approach!that!can!be!found!in!other!cleanEslate!proposals![138][139][140][110].! The! main! idea! behind! this! process! is! to! break! existing! protocols! into! small! components!with!a!particular!functionality.!They!main!difference!between!them! lies!in!how!this!modularization!is!done.!For!instance,!it!can!be!done!according!a! specific!goal,!scope,!focus,!purpose!and!level!of!granularity.!In!addition,!they!also! defer!in!how!network!architecture!and!protocols!are!abstracted,!represented!and! built.!Then,!communications!are!composed!with!these!independent!components.!! ! Some!projects!in!the!USA!(NSF!GENI/FIND[141][142]),!EU!(4WARD![139])!and! Japan!(AKARI!Project![143])!have!been!issued!to!develop!new!network!solutions! from! scratch.! These! cleanEslate! proposals! share! some! common! concepts,! like!
Part!I:!Introduction!–!The!Basics! ! ! 43! microEmodularization! and! virtualization! as! a! means! to! support! multiple! architectures! simultaneously,! in! their! design! and! objective.!Nevertheless,! they! differ!in!scope!and!development.!For!example,!from!the!GENI/FIND!program,!the! SILOS!proposal![138][144]!uses!microEmodularization!similarly!to!RBA,!but!does! not!to!avoid!creating!layers.!Actually,!they!generalize!the!layering!approach!to! ease! crossElayer! interactions! and! avoid! subElayer! proliferation.! Thus,! they! advocate! building! a! customEmade! protocol! stack! (known! as! silo)! for! each! connection!made!of!fineEgrain!building!blocks.!This!custom!stack!is!the!same!all! across! the! delivery! context,! so! it! is! not! adapted/tuned! to! the! different! requirements! of! each! network! section! found! in! heterogeneous! environments.! Furthermore,!it!is!not!clear!how!silos!are!negotiated!between!the!edges.! ! Next,!this!section!makes!an!overview!of!some!remarkable!projects!and!initiatives! that! present! cleanEslate! architectures! related! to! SOA,! and! then! an! analysis! is! presented!based!on!the!fundamental!stages!of!a!serviceEoriented!approach.!! ! The!4WARD!project!emphasizes!the!shift!from!networking!nodes!to!networking! information! or! network! of! information.! This! informationEcentric! approach! is! applied! to! routing! and! data! transport! (as! objects).! In! this! approach,! protocol! design!is!focused!on!analyzing!protocol!invariants!in!order!to!build!them!from! their! most! basic! functional! blocks! (e.g.!error! control,! encryption,! etc.).! Thus,! 4WARD! advocates! virtualizing! the! different! architectures! and! protocols! using! constructions!called!Netlets!made!of!several!functional!blocks,!in!order!to!meet! specific!requirements.!!In!this!way,!nodes!instantiate!and!execute!Netlets!on!top! of!a!kind!of!protocol!virtual!machine.! ! SONATE! (ServiceEOriented! Network! Architecture)! [110]!presents! an! approach! completely! based! on! ServiceEOriented! Architectures! (SOA),! considering! the! Internet! as! a! large,! distributed! (software)! system.! Its! goal! is! to! encapsulate! microEprotocols! as!services.! Thus,! their! definition! of! a! service! relies! on! open,! standardized!and!generic!service!interfaces,!permitting!the!decoupling!of!logic! from!implementation,!and!offering!an!abstract!view!on!the!functionality!of!these! protocols,! in! contrast! to! hiding! mechanisms! by! layers.! However,! this! specification!does!not!rely!on!a!fixed!semantic,!to!allow!later!extension!to!yet! unknown!practical!needs.!In!addition,!context!data!is!not!yet!considered.! ! The!RINA![145]!project!proposes!a!clean!slate!approach.!It!proposes!a!general! theory!of! Inter! Process! Communication! (IPC)!where!the!number!of!IPC!layers! (homologous!to!OSI!model)!may!vary!depending!on!the!range!of!the!resource! allocation.! This! network! architecture! is! based! on! the! following! principles:! (1)! Mechanism! and! policy! are! separated! in! the! protocols;! (2)! Connectionless! and! connection!communication!modes!are!unified;!and!(3)!Topological!addresses!are! embedded!in!a!Distributed!Inter!Process!Communication!Model.! ! The! Recursive! Network! Architecture! (RNA)! [140]!explores! the! relationship! between!layering,!protocols! and! network! architecture.! Its! primary! goal! is! to! encourage! cleaner! crossElayer! interaction,! to! support! dynamic! service! composition! and! to! gain! knowledge! on! how! layering! affects! architecture.! In! order!to!fix!the!current!Internet!architecture!problems,!RNA!proposes!the!use!of!
Chapter!5!Future!Internet!from!a!Service!Perspective! ! ! 50! 5.4.1 Semantic.Service.Identification. ! In! the! Future! Internet! users! should! be! able! to! consume! network! services! anytime,!anywhere!and!anyhow.!These!are!specially!needed!features!to!allow!a! real!ubiquitous!Future!Media!Internet.!This!requirement!implies!mechanisms!to! create,! discover,! negotiate! and! consume! composed! services! in! a! flexible! and! contextEaware!way.!! ! Service! consumers! may! not! know! which! device! provides! a! desired! composed! service.!Even!more,!they!may!not!know!the!name!or!the!identifier!of!the!service! they!are!looking!for.!However,!they!know!the!characteristics!of!the!service!they! want! to! consume.! Thus,! consumers! must! be! able! to! describe! the! desired! requested!service!and!the!network!must!be!able!to!resolve!and!reply!if!there!is! any!service!matching!this!description.!In!addition,!a!reachable!locator!must!be! provided! to! access! the! service.!It! would! be! desirable! that! service! consumers! could!describe!a!desired!service!using!semantic!constructions!like!“I!want!a!color! printer!close!to!building!X!with!toner!and!paper”!and!probe!the!network!with! this!semantic! query.! As!the!probe!travel!the!network,! traversing! nodes!match! against!their!profiles!if!any!of!their!services!comply!with!the!semantic!service! description!of!the!probe.!Since!each!node!knows!its!own!capabilities!and!which! composed!services!it!provides!and!their!characteristics,!which!are!described!in! node!and!service!profile!instances,!they!can!match!against!the!attributes!of!their! service! profiles! if! any! of! their! composed! services! complies! with! the! desired! functionality.! This! process! is! called! semantic! service! identification.! It! must! be! noted!that!attribute!resolution!in!the!semantic!identification!process!is!done!inE route!(see! section! 7.3! for! further! details! on! the! proposed! semantic! requests! fields),!during!packet!travelling!and!not!as!a!previous!phase!before!actually!start! sending!packets.! ! In! order! to! be! feasibly! implemented,! network! nodes! must! share! a! common! knowledge!base!or!ontology;!that!is!a!common!attribute!semantics!and!syntax.! Although! different! ontologies! may! be! supported,! all! nodes! must! support! the! minimum! identification! ontology.! This! basic! ontology! is! designed! to! be! minimalistic,!in!order!to!be!supported!by!all!kind!of!devices!and!platforms!with! enough! ease! (in! terms! of! memory,! computing! power! and! energy),! but! still! providing! enough! level! of! expressiveness! and! completeness! when! building! semantic!constructions.! Attributes!are!defined! for!describing!node!capabilities! (CPU,! memory,! network! interfaces,! battery,! etc.),! temporal! context! characteristics! (location,! domain),! atomic! services! characteristics! (type,! supported! granularity,! dependences,! configuration! parameters,! etc.)! and! composed! services! characteristics! (I/O! behavior,! negotiation! scheme,! description,! provider,! etc.).! As! described!in! [GP13]! and! [210],! in! order! to! minimize! the! amount! of! information! transferred,! attribute! syntax! could! be! dictionaryEbased.!Some!possible!operators!that!can!be!applied!to!attributes!when! constructing!semantic!descriptions!are!logical!operators!(e.g.!AND,!OR,!NOT,!etc.)! comparison!operators!(e.g.!<,>,!=,!etc.)!or,!even,!regular!expressions!and!rules.! !
Part!I:!Introduction!–!The!Basics! ! ! 51! 5.5 Service.Discovery. ! Distributed! computing! and! resource! sharing! pose! a! strong! requirement! for! heterogeneous! networks! of! all! types! such! as! largeEscale! networks,! involving! different! domains! (multiEdomain)! and! providers! (multiEprovider),! using! different!network!technologies,!while!also!considering!small!networks!with!tiny! devices!with!computation!limitations!and!challenging!network!conditions.!The! most!obvious!repercussion!is!the!difficulty!in!finding!the!best!services!in!such!a! heterogeneous! environment! according! to! consumers! and! the! providers’! goals,! whilst!determining!the!different!parties!that!can!participate!in!a!communication.!! ! For! instance,! imagine! a! node! that! wants! to! establish! a! communication! that! involves!very!different!networks,!that!is,!a!heterogeneous!scenario!like!the!one! depicted!in!Figure!5.3,!which!involves!a!segment!using!mobile!networks,!optical! networks,! copper! networks,! etc.! In! this! environment! there! may! be! network! segments!with!reliable!communication!characteristics.!This!could!be!the!case!for! nodes!connected!with!wired!links!(e.g.!segment!E!in!Figure!5.3).!Moreover,!other! network!segments!could!require!some!mechanisms!such!as!error!detection!and! recovery!mechanisms!in!order!to!achieve!reliability!under!the!effect!of!high!error! rates!or!packet!loss!in!unreliable!links!(e.g.!segment!A,!B,!F).!Services!should!be! allocated!depending!on!all!the!context!parameters!like!links!conditions,!devices! capabilities,!users!preferences,!etc.!! ! Figure!5.3!Example!of!a!communication!involving!heterogeneous!networks![131]! Hence,!in!order!to!provide!and!consume!(composed)!networked!services!in!an! adapted! and! contextEaware! manner! (e.g.! according! to! desired! functionality!or! service!goal,!behavior!and!QoS!constraints),!the!available!atomic!services!must! be!suitably!combined!and!allocated!along!the!communication!path!where!they! are! actually! needed! and! configured! accordingly! to! accomplish! the! application! requirements.!!Thus,!atomic!services!can!be!executed!in!a!perEhop!or!perEsection! basis.! ! In!the!light!of!this!situation,!a!suitable!and!intelligent!service!discovery!protocol! is! the! key! to! find! and! compose! different! services! in! the! network.!There! are! diverse!Service! Discovery! Protocols! (SDP)! proposed! in! literature.! Service! discovery!enables!services!and!devices!to!discover,!configure!and!communicate! with! each! other.! However,! a! major! problem! of! current! SDPs! is! that! networks!
Chapter!5!Future!Internet!from!a!Service!Perspective! ! ! 52! with!different!properties!require!different!discovery!protocols!and!mechanisms.! This!yields!to!important!interoperability!problems.!In![159],!authors!state!that! existing!protocols!have!various!design!goals!and!solutions.!Each!of!them!has!its! own!benefits!and!drawbacks!in!different!scenarios.!Therefore,!it!seems!difficult! to! have! a! single! protocol! to! discover! services! in! pervasive! computing.! With! current!protocols!clients!and!services!cannot!discover!each!other!if!a!common! protocol!is!not!used.! ! SDPs!have!been!widely!investigated!in!the!field!of!Web!Services!and!Pervasive! Computing.!Web!Services!(WS)!are!used!at!the!top!of!the!application!level!and! aim! towards! service! globalization! in! enterprise! environments.! Enterprise! services! are! customarily! consumed! within! a! specific! network! scope! with! the! presence! of! firewalls! and! managed! by! network! administrators.! In! addition! to! this,! WS! scope! focuses! on! application! interaction.! For! instance,! WWW! Consortium! specifies! different! standards! to! enable! platform! interoperability,! such!as!WSDL![160]!for!XMLEbased!web!service!descriptions.!Regarding!service! discovery! and! configuration,! we! can! find! three! main! discovery! protocols! standardised!by!OASIS:!Universal!Description!Discovery!and!Integration!(UDDI)! protocol,! electronic! business! using! XML! (ebXML)! and! WSEDynamic! Discovery! (WSEDiscovery).!!UDDI!is!the!oldest,!most!extended!and!mature!one.!The!main! drawback!of!WS!approaches!is!that!they!focus!on!electronic!commerce.! ! SDPs!used!in!pervasive!computing!environments![159][161][162][163]!are!more! dynamic! and! heterogeneous.! In! [159]!an! inEdepth! analysis! and! comparison! of! several!SDPs!commonly!used!in!pervasive!computing!appear.!Some!of!them!are! INS,! Ninja! SDS,! DEAP! Space,! Jini,! UPnP,! Rendezvous,! Salutation,! SLP! and! Bluetooth! SDP.! This! work! also! offers! a! useful! taxonomy! to! classify! SDPs! according! to! their! design! principles.! In![164],! authors! offer! an! accurate! comparison!of!different!SDPs!(Salutation,!SDS,!SLP,!Jini,!INS,!UPnP,!INS/Twine,! JXTA! and! Splendor)! in! order! to! establish! grounding! guidelines! to! build! a! distributed!largeEscale!and!multiEdomain!discovery!system!capable!of!facilitating! open!service!discovery!across!heterogeneous!networks!and!scaling!to!hundreds! of! users.! They! compare! them! in! terms! of! architecture,! effectiveness,! faultE tolerance,! performance,! security,! platform! and! network! independence,! scalability,! interoperability! and! standardization.! Authors! focus! on! three! particular!approaches:!WS,!INS/twine!and!structured!P2P!systems!as!potential! components!of!a!new!SDP!considering!no!one!in!literature!could!cover!all!the! objectives!defined!by!them!(largeEscale!multiEdomain).! ! Other!works!like![40]!and![166]!contemplate!contextEaware!service!discovery.! On! the! other! hand,! other! service! discovery! systems! focus! on! single! hop! (Bluetooth![167]!and!DeepESpace![168])!and!multiEhop![169].! ! Service!discovery!protocols!can!be!classified!in!different!ways.!One!classification! can! be! undertaken! attending! to! its! centralised! or! decentralised! operation.! Another! way! of! classifying! SDP! is! by! means! of! their! suitability! to! be! used! in! different!networks!(e.g.!large!vs.!small!and!static!vs.!mobile),!which!is!actually! the! approach! considered! in![170].! Specifically,! in! the! field! of! pervasive! computing,!discovery!protocols!are!very!diverse!in!that!different!networks!need!
Part!I:!Introduction!–!The!Basics! ! ! 53! different!protocols.!Pervasive!SDPs!can!be!adaptive,!meaning!that!they!can!be! used! in! different! domains! [171][172][173].! Another! approach! is! to! create! a! layered! structure! that! allows! the! coexistence! of! different! legacy! SDPs! by! adopting!a!service!discovery!abstraction!layer!above!the!others![174].!Finally,!it! is! also! possible! to! implement! service! discovery! gateways! to! support! interoperability! between! different! protocols! such!as!those! presented! in![175],! where! Jini! clients! can! interact! with! UPnP! clients! and! viceversa.! In![176],! a! dynamic!service!proxy!that!enables!the!interoperability!of!different!protocols!is! introduced.! !Gateways! are! considered! more! efficient! than! a! layered! structure.! They!also!make!it!possible!to!use!legacy!protocols.! ! Regarding!Standardization!activities,!we!can!point!out!works!done!by!the!IETF! for!SLP,!Globus!Alliance!for!OGSA!Grid!Services,!the!W3C!and!UDDI!Consortium! (OASIS)!for!Web!Services,!Salutation!Consortium!for!Salutation,!and!UPnP!Forum! for!UPnP.!Moreover,!SDS,!INS!and!INS/Twine!also!remain!in!the!stage!of!research! works.! A! considerable! number! of! existing! implementations! and! development! platforms! for! Salutation,! SLP,! Jini,! INS! and! INS/Twine,! UPnP! and! JXTA! can! likewise! be! found.! !All! these! proposed! protocols! can! inspire! future! service! discovery!protocol!design,!like!the!one!offered!in!this!work.! !
!! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Part.II: Scalable.and.Robust.Media.Streaming.. !
Part!II:!Scalable!and!Robust!Media!Streaming!! ! ! 57! Chapter.6 Robust. and. Scalable. Streaming. in. Heterogeneous.and.Dynamic.Scenarios. ! Recently,! the! proliferation! of! multimedia! contents! and! multimedia! capable! devices! has! significantly! grown! and! will! keep! growing! very! fast! in! the! future! according! to! different! studies!that! have! analysed! the! Internet! traffic![1]![4].! Video! will! be! the! most! present! content! in! the! network.! This! situation! has! provoked!that!multimedia!should!be!everywhere!and,!consequently,!depending! on!the!context!it!is!consumed,!multimedia!streaming!systems!have!to!deal!with! very!different! requirements! and! conditions.! This! section! introduces! three! contributions!made!in!two!different!scenarios!(Vehicular!Ad!Hoc!Network!and! Internet! media! streaming! using! P2P! mechanisms),! however,! all! of! them! introduce! advances! to! allow! multimedia! delivery! in! a! robust! and/or! scalable! manner!in!such!a!heterogeneous!and!dynamic!environments.! ! The!first!contribution!covers!a!P2P!video!streaming!scenario.!This!scenario!has! attracted! the! interest! of! broadcasters,! operators! and! service! providers!as! it! presents! a! reliable! solution! to! stream! contents! massively! in! the! Internet.! Concretely,!meshEpull!based!P2P!systems!are!the!most!extended!ones.!Despite! these!systems!address!scalability!efficiently,!they!still!present!several!limitations! that! difficult! them! to! offer! the! same! user! experience! in! comparison! with! traditional!TV.!These!ones!are!mainly!the!freeEriding!effect,!long!startEup!delays! and!the!impact!of!churn!and!bandwidth!heterogeneity.!In!this!PhD.!Thesis!we! studied!the!performance!of!Multiple!Description!Coding!(MDC)!combined!with! the!use!of!incentives!for!P2PEbased!streaming!systems!in!order!to!mitigate!some! of! them.! The! simulation! results! we! gathered!show! that! the! use! of! MDC! and! incentiveEbased! scheduling! strategies! improve! the! overall! performance! of! the! system.! Moreover,! an! extended! version! of! the! simulator! P2PTVSim! has! been! developed!to!quantify!the!gain!in!performance!when!using!MDC!and!incentives!in! P2PTV!applications.!See![GP2],![GP12],!![GP14]!and![GP15]!for!more!details!on! these!systems!and!contributions.! ! A!second!contribution!is!made!focusing!on!improving!video!communication!over! a!Vehicular!Ad!Hoc!Networks!(VANETs)!scenario.!Video!communication!VANETs! has!many!applications,! such! as! emergency!video!transmission!or! interEvehicle! entertainment.! However,! delivering! video! to! high! mobile! vehicles! faces! challenges! such! as! packet! loss! due! to! intermittent! connectivity! and! channel! variations.!Thus,! designing! a! reliable! approach! for! video! streaming! over! such! harsh! scenarios!is! needed.! Hence,! we! propose! a!reliable! approach! based! on! random!practical!network!coding!and!source!coding.!This!approach!integrates! the!benefits! of! network! coding! with! Multiple! Description! Coding! to! achieve! robust! streaming! over! VANET.! Furthermore,! we! propose! a! redundancy! controller! based! on! fuzzy! inference! (implemented! using!jFuzzyLogic! [259])! system! to! adjust! the! amount! of! redundant! packets! based! on! vehicular! traffic! density! and! SNR! of! the! channel.! Simulation! shows! the! proposed! approach! achieves!better!protection!against!packet!loss,!application!layer!throughput!and!
Chapter!6!Robust!and!Scalable!Streaming!in! Heterogeneous!and!Dynamic!Scenarios! ! ! 58! video! quality.! Note! that! the! fuzzy! algorithm! implemented! in! this! contribution! could! be! used! as! selection! algorithm! during! the! service! selection! and! composition! process! (see! 7.4).! However,! determining! the! specific! situations! where! an! algorithm! behaves! better! than! others! remains! as! future! work.! This! algorithm! was! implemented! and! validated! in! [GP9]! and! [GP5]! in! different! constrained!VANET!scenarios.!The!foundations!of!them!are!the!same!although! the! final! application! is! different!and! has! been! adapted! (fuzzy! membership! functions!and!rules)!according!to!the!final!goal.! ! Finally,!a!third!contribution!is!made!in!the!field!of!robust!media!transmission!in!a! challenging! VANET! scenario! using! specific! FEC! mechanisms.! Specifically,! in! [GP4]!we!propose!an!error!resilient!scheme!based!on!packet!level!Forward!Error! Correction!(FEC)!and!interleaving!technique!for!reliable!video!geocasting!over! VANET.!The!proposed!scheme!is!able!to!adapt!channel!variations!by!using!Real! Time!Control!Protocol!(RTCP)!reports!of!vehicles!in!the!communication!range!of! video!source.!To!achieve!a!fair!comparison!with!other!error!protection!schemes,! we!have!implemented!a!proposed!error!resilient!scheme!in!Network!Simulator!2! (NS! 2).! The! results! of! this! simulationEbased! study! show! that! the! proposed! scheme!is!able!to!improve!the!perceived!video!quality!and!protection!efficiency! while!minimizing!bandwidth!overhead!(introduced!by!proactive!error!recovery)! in! urban! vehicular! scenarios.! Note! that! this! FEC! mechanism! can! be! used! to! protect! data! transmissions! at! the! packet! level.! Thus,! can! be! seen! as! another! mechanism! complementary! to! others! (e.g.! MDC,! SVC,! etc.)! to! provide! more! robust!and!reliable!communications.! ! Related!results!and!contributions!of!these!works!were!published!in![GP4],![GP5],! [GP9],![GP11]!and![GP17].! ! It! is! important! to! remark! that! these! contributions! propose!robust! techniques! that! can! be! applied! to! the! media! delivery! (streaming)! working! at! application! level,! being! offered! by! two! completely! different! applications!although! using! similar! techniques! to! achieve! scalability! and! robustness!in! different! environments.!Mainly,!these!techniques!are!coding!techniques!(FEC,!MDC,!NC).! MDC! applied! in! combination! with! distributed! delivery! mechanisms! (NC! and! P2P).!Moreover,!in! one!hand,!the!implemented!methods! could!be!optimized!if! they!were!allowed!to!get!information!(e.g.!error!rate,!delay,!etc.)!directly!from! the!network!(lower)!layers!or!specific!layers,!following!a!crossElayer!approach,! for!instance,!instead!of!implementing!all!required!mechanisms!at!the!application! (highest)!layer.!On!the!other!hand,!applications!could!share!the!functionalities! they!implement!among!them!if!they!were!implemented!as!services!allowing!their! reuse.! To! achieve! this,! this! PhD.! Thesis!proposes! to! abstract! all! these! basic! functionalities!as!Atomic!Services!to!allow!their!composition!(into!more!complex! Composed!Services)!according!to!user!and!application!goals!in!order!to!establish! and! provide! adapted! services! in! the! Future! Internet,! specially! focusing! in! multimedia! communications.! In! this! case,! possible! services! could! be! MDC/SVC/MVC!functions!or!operations!like!NC!or!FEC!calculations!like!the!ones! proposed!in!this!thesis.!These!functions!could!be!natively!introduced!as!services! into! the! network! and,! in! so! doing,! allow! their! reuse! at! any! part! of! the! communication! just! when! and! where! needed.! Thus,! creating! smart! networks!
Part!II:!Scalable!and!Robust!Media!Streaming!! ! ! 59! able!to!intelligently!adapt!media!according!to!the!specific!requirements!of!users! and! the! different! participating! stakeholders![237].! This! is! explained! in! more! detail!in!section!Chapter!7.! ! 6.1 Evaluating.Multiple.Description.Coding.with.Incentives.in. P2PTV.Systems. ! P2PTV!streaming!systems!have!become!a!popular!service!on!the!Internet!(both! at!commercial!and!research!level),!with! several!successful!deployments![177],! and! the! most! spread! form! of! what! is! known! as! Internet! TV.! P2PTV! allows! distributing!media!contents!thanks!to!multicasting!at!application!level!(ALM).!! ! The!use!of!these!systems!is!promising!as!they!offer!the!possibility!to!introduce! added!value!to!traditional!TV!broadcasting!by!providing!flexibility,!in!terms!of! content! delivery! (videoEonEdemand! as! well! as! realEtime! contents),! and! interactive!services.!But!in!order!to!become!a!truly!successful!application!they! need! to! be! able! to! provide! the! same! or! even! better! user! experience! as! TV! broadcasting!offers.!! ! These!systems!are!expected!to!provide!a!high!degree!of!scalability!with!different! streaming!rates!and!number!of!peers.!They!must!also!provide!continuity!under! adverse! churn! conditions! (especially! in! presence! of! flashEcrowds)! as! well! as! ensuring! delivery! of! data! within! a! given! deadline! in! order! to! provide! smooth! playback.!The!main!aspects!affecting!the!performance!of!these!requirements!can! be!seen!in![183].!Among!them,!we!will!focus!on!freeEriding!(nonEcooperation)! effect,!long!startEup!delay!and!the!impact!of!churn!and!bandwidth!heterogeneity! in!the!stability!of!the!system.! ! In!this!PhD.!Thesis!we!propose!an!MDCEbased!system,!which!uses!incentives!for! redistribution,!in!order!to!address!the!impact!of!losses!in!the!Continuity!Index! (CI)!and!the!delay!and!the!performance!problems!due!to!the!effect!of!freeEriding.! Multiple!Description!Coding!(MDC)![44]!is!a!technique!designed!to!enhance!error! resilience!and!increase!transmission!robustness!and!scalability.!Results!obtained! in![178]!and![179]!show!that!using!MDC!the!delivered!quality!is!acceptable!even! under!the!presence!of!high!loss!rates.!In!order!to!validate!the!proposed!solution! we!have!deployed!it!in!a!simulation!environment.!! ! For! this! purpose! we! are! using! P2PTVSim! (see! [180]! for! more! details! on! this! simulator)!but!with!some!key!modifications.!More!specifically,!we!have!extended! the!software!in!order!to!be!able!to!simulate!the!flow!of!MDC!subEstreams!in!a! P2PTV!overlay!and!gather!the!corresponding!statistics!as!well! as! the! use! of! a! specific! incentive! strategy.! The! obtained! results! show! how! the! use! of! MDC! provides! a! more! robust! behaviour! against! loses! (generated! by! effect! of! churn! and!bandwidth!heterogeneity).!Consequently,!the!Continuity!Index!of!the!system! is!improved.!In!addition,!thanks!to!the!use!of!incentives,!the!effect!of!freeEriding! is!alleviated.! !
Chapter!6!Robust!and!Scalable!Streaming!in! Heterogeneous!and!Dynamic!Scenarios! ! ! 66! Figure!6.4!Reference!System!?!!Delay!for!0%,!5%!and!10%!losses! 6.1.3.2 Reference,system,with,incentives, ! When!the!use!of!incentives!is!introduced!as!explained!in!previous!sections!the! overall!performance!of!the!system!is!expected!to!improve.!In!Figure!6.5!we!can! see! how! the! CI! of! the! cooperating! peers! has! increased! significantly! while! the! freeEriders!are!aggressively!punished!having!their!CI!importantly!reduced.! ! Even!at!high!loss!rates!like!20%,!the!CI!keeps!above!0,9!for!the!cooperating!peers! and!at!the!40%!loss!rate!class!A!peers!still!maintain!the!CI!over!0,9!while!class!B! and! C! peers! drop! to! 0,8! and! 0,65! approximately.! Then! evaluating! the! delay! results! when! using! incentives! (Figure! 6.6)! we! found! that! there! is! also! a! significant! improvement! for! the! cooperating! peers,! that! have! a! lower! delay! (being!reduced!by!1!second!approximately).!The!freeEriders!delay!behaviour!as! depicted!in!Figure!6.6,!does!not!effectively!drop!from!the!10%!loss!rate,!but!it! does! drop! in! the! picture! because! the! delay! is! measured! only! for! the! useful! received!chunks!and!as!it!can!be!seen!in!Figure!6.5!freeEriders!do!not!have!that! many!chunks!from!that!point.!Thus,!the!average!decreases!as!the!late!received! chunks!are!not!included.! ! ! ! ! ! ! ! ! ! Figure!6.5!Incentive?based!system!?!CI!vs.!Losses!
Part!II:!Scalable!and!Robust!Media!Streaming!! ! ! 67! ! ! ! ! ! ! ! ! ! Figure!6.6!Incentive?based!system!?!Delay!vs.!Losses! The! results! show! that! cooperating! peers! benefit! from! the! incentiveEbased! mechanism.! That! is! because! the! bandwidth! that! these! peers! were! wasting! serving! freeEriders! is! now! available! and! used! for! these! cooperating! peers,! increasing!their!overall!performance.!! 6.1.3.3 MDC,System, ! In! order! to! create! a! more! robust! streaming! system! against! losses,! the! MDC! scheme!is!introduced.!The!proposed!system!has!the!same!characteristics!as!the! reference! one! but! using! multiple! layers! and! the! chunk! request! scheduling! strategy! (no! incentives! for! redistribution! are! used).! Here! the! results! for! the! simulations!performed!with!the!MDC!system!are!presented.!First,!in!Figure!6.7,! we! can! see! the! CI! achieved! using! the! MDC! system.! As! it! can! be! seen! the! continuity!increases!significantly!and!it!only!drops!to!0,9!approximately!when! the!loss!rate!is!40%.! ! This!result!shows!how!the!use!of!MDC!can!improve!one!of!the!main!metrics!that! we!want!to!optimize!in!a!P2P!streaming!system:!the!continuity!playback!or!CI.! But! it! is! important! to! point! out! that! this! measure! only! indicates! the! level! of! continuity!(being!almost!the!same!for!the!different!peer!classes)!but!does!not! indicate!the!received!quality.!This!quality!depends!on!the!number!of!descriptions! as!well!as!on!the!characteristics!of!the!MDC!techniques!used!(such!as!the!ones! described!in![187]),!and!to!show!the!difference!between!the!four!peer!classes!the! average!number!of!received!descriptions!is!depicted!in!Figure!6.8.!Here!we!can! see!that!class!A!peers!receive!in!average!a!higher!number!of!descriptions!than! the!rest!of!the!classes.! ! Also,!as!it!can!be!seen!in!Figure!6.9,!the!delay!decreases!drastically.!This!is!due!to! the!fact!that!the!delay!is!measured!for!individual!chunks!that!are!smaller!in!the! MDC!system!(their!size!in!relation!to!the!size!of!the!single!layered!system!chunks! can! be! considered! proportional! to! the! number! of! descriptions! used).! For! that! reason!the!delay!here!has!to!be!understood!in!a!different!context!than!the!delay! for!the!single!layered!system.!Here!it!is!interesting!to!take!into!account!these!low! delay!values!for!MDC!endEtoEend!chunk!delivery!because!in!systems!where!there! are!lowEdelay!requirements!MDC!could!be!used.!!
Chapter!6!Robust!and!Scalable!Streaming!in! Heterogeneous!and!Dynamic!Scenarios! ! ! 68! ! ! ! ! ! ! ! ! ! ! ! Figure!6.7!MDC!system!?!CI!vs.!Losses! ! ! Figure!6.8!MDC!system!?!Average!number!of!descriptors!vs.!Losses! ! ! ! ! ! ! Figure!6.9!MDC!system!?!Delay!vs.!Losses! 6.1.3.4 MDC,System,with,Incentives, ! Next,!we!combine!the!use!of!MDC!with!incentives!for!redistribution.!Here,!to!the! improvements!introduced!by!MDC!in!terms!of!CI!increase!and!low!endEtoEend! delay,! we! can! add! the! overall! performance! boost! introduced! by! the! use! of! incentives.!As!it!is!shown!in!Figure!6.10,!the!CI!can!be!maintained!at!almost!the! maximum!level!even!at!high!loss!rates!like!40%.!This!combination!allows!a!high!
Part!II:!Scalable!and!Robust!Media!Streaming!! ! ! 69! level! of! continuity! playback.! The! quality,! in! terms! of! average! number! of! descriptions! is! also! increased! for! the! cooperating! peers! as! it! can! be! seen!in! Figure!6.11.!The!only!metric!that!is!not!significantly!enhanced!in!this!system!is! the! delay! (Figure! 6.12)! as! it! is! approximately! the! same! delay! that! the! MDC! system!showed.! ! ! ! ! ! ! ! ! ! ! ! ! Figure!6.10!MDC!+!!Incentives!?!CI!vs.!Losses! ! ! ! ! ! ! ! ! Figure!6.11!MDC!+!Incentives!?!Average!number!of!descriptors!vs.!Losses! ! ! ! ! ! ! ! ! Figure!6.12!MDC!+!Incentives!?!Delay!vs.!Losses! !
Chapter!6!Robust!and!Scalable!Streaming!in! Heterogeneous!and!Dynamic!Scenarios! ! ! 70! 6.1.4 Conclusions. ! The! gathered! results! show! that! the! proposed! solution! clearly! improves! the! considered! metrics! and! the! overall! behaviour! of! the! system! compared! to! the! performance!of!the!reference!system.!These!results!can!be!used!as!reference!or! guideline!for!further!developments.!As!an!additional!outcome!of!this!work!we! have!developed!a!simulation!software!which!is!a!valid!testEbed!that!can!be!used! for! future! studies! (based! on! P2PTVSim).! In! order! to! provide! a! more! comprehensive!validation!of!this! system! other! measurements! and! simulations! should!be!performed!to!complement!the!results!of!this!work.!More!specifically,! the!measure!of!the!overhead!introduced!by!the!use!of!MDC!should!be!considered! in! order! to! see! if! it! is! worth! deploying! this! kind! of! techniques,! and! trying! to! define! the! optimal! overhead! to! be! introduced! (tradeEoff! between! number! of! descriptors!and!overhead).!Also!PSNR!quality!measurements!could!be!performed! by! selecting! a! specific! MDC! technique! and! running! the! corresponding! simulations.!To!complete!these!results,!the!effect!of!churn![190],!concretely!the! impact!of!flashEcrowds,!is!desired!to!be!added!to!the!simulation!environment!and! evaluated!in!order!to!see!if!the!proposed!solution!performs!satisfactorily!under! these!conditions.! ! Taking!into!account!the!obtained!results,!another!line!of!work!that!we!started! was! the! use! of! MDC! for! systems! or! applications! with! low! starEup! delay! requirements!and!the!corresponding!approaches!to!it.! 6.2 Fuzzy.Redundancy.Adaptation.and.Joint.Source.Network. Coding.for.VANET.Video.Streaming. ! Vehicular!adEhoc!networks!(VANET)!are!an!emerging! field! of! communications! technology,!which! integrates! ad! hoc! network! and! wireless! LAN! (WLAN)! networks!to!achieve! intelligent! vehicleEtoEvehicle!communication.! This!kind!of! inter! vehicle! communication! fosters! the! deployment! of! innovative! wireless! applications! based! on! real! time! streaming! of! video! flows.! Real! time! video! communications! between! vehicles! has! several! applications! ranging! from! road! safety,!commercial!advertisement!and!on!road!entertainment.!Furthermore,!it!is! remarkable! that! the! IEEE! 802.11! standard!specifies! the! support! of!video! communication!over!vehicular!networks![191].! ! These!networks!deal!with!different!traffic!scenarios!in!different!situations,!such! as!during!late!nighttime,!rush!hour,!dense!and!sparse!traffic!(e.g.!in!highways),! which! can! cause! unstable! vehicular! network! topologies.! Thus,! the! communication!link!will!last!for!a!short!time!due!to!high!mobility!of!vehicles!and! dynamic!topology.!Mobility!of!vehicles!leads!to!high!variability!of!interEvehicle! communication! channels! according! to! IEEE! 802.11! standard.! This! makes! real! time! video! communications! a! very! challenging! task.! In! addition,! the! communication! channel! between! vehicles! is! prone! to! radio! frequency! interference! together! with! different! forms! of! fading! including! multiEpath! and! slow!fading.!As!a!consequence,!the!channel!suffers!both!from!high!bit!error!rate!
Part!II:!Scalable!and!Robust!Media!Streaming!! ! ! 71! and!high!packet!error!rate,!which!leads!to!high!packet!loss.!There!are!several! reasons!for!packet!loss!such!as!channel!error,!congestion!and!packet!delay.!This! work!concentrates!on!packet!loss!produced!by!channel!error.! ! In! vehicular! networks,! random! and! burst! errors! frequently! occur.! When!bit! errors!occur!during!a!transmission,!the!error!may!repeat!over!several!packets! due! to!the! intrinsic! dependence! among! the! frames! of! the! compressed! video! stream.! Bursts! of! errors! are! considered! [192][193][194]! to! affect! more! negatively! to! video! quality!perception!than!the! effect! produced! by! randomly! distributed!errors.! Thus,! to! overcome!bit!error!rate,!loss! recovery! methods!of! video!streams!are!specially!needed.! ! One!way!to!achieve!reliable!and!robust!video!communications!between!vehicles! is! by! applying!error! resilient! approaches!like! Network! Coding! (NC).! In! [193]! authors!showed!that!NC!could!provide!robustness!and!high!throughput!in!wired! or!wireless!networks.!The!main!idea!behind!NC!is!that!intermediate!nodes!can! encode! incoming! packets! instead! of! having! passive! nodes! just! forwarding! packets!according!to!routing!algorithms!as!in!the!current!Internet.!With!NC!no! routing! algorithm! is! required.! The! receiver! starts! decoding! data! once! it! has! a! certain!minimum!number!of!coded!packets.!However,!a!single!packet!loss!can! cause!a!generation!of!coded!packets!to!be!lost.!Therefore,!NC!should!be!used!with! a!proper!error!resilient!approach!for!video!streaming!in!VANETElike!scenarios.!In! addition,!NC!has!the!ability!to!increase!robustness!against!packet!loss!in!wireless! ad! hoc! networks! [194].! The! error! resilient! capability! of! NC! depends!on! the! number! of! encoded! packets,! which! are! produced! by! intermediate! nodes.! Redundancy!may!vary!according!to!vehicular!network!traffic!conditions!such!as! sparse! and! dense! scenarios.! In! sparse! scenarios,! the! number! of! redundant! packets!should!be!increased!appropriately!to!compensate!packet!loss!while!in! dense!scenarios!it!should!be!decreased!to!mitigate!bandwidth!overload.!Thus,!we! can!optimize!the!redundancy!of!NC!according!to!the!vehicular!traffic!density!in! each!situation.!Also,!redundancy!can!be!tuned!according!to!the!error!rate!of!the! communication! channel.! In! this! section,! we! propose! a! redundancy! controller! based!on!a!fuzzy!inference!system![195],!which!can!effectively!adjust!the!amount! of!redundant!packets!to!the!desired!target!value.!! ! Furthermore,! as! seen! in! section! 4.3.1.1,! Multiple! Description! Coding! (MDC)! encodes!a!video!file!into!a!number!of!different!independent!subEstreams.!Thus,! MDC!can!be!used!to!reduce!the!effects!of!packet!loss![44].!Unlike!previous!works,! which!do!not!consider!the!problems!of!losing!coded!packets!when!using!NC,!this! work!proposes!to!use!MDC!to!mitigate!these!problems!in!combination!with!the! adjustment!of!the!NC!redundancy!according!to!vehicular!traffic!conditions!and! channel! error! rate! variation.! Thus,!we! propose! a! fuzzyEbased! NC! redundancy! control!mechanism!combined!with!MDC!to!achieve!reliable!video!streaming!over! VANET.! This! fuzzyEbased! controller! was! implemented! using! the! jFuzzyLogic! software![259]!and!has!been!validated!in![GP5]!and![GP9]!adapting!them!to!the! specific!goals!of!each!communication.!The!former!for!adapting!the!frequency!of! the!beconing!rate!in!a!VANET!scenario!and!the!later!for!deciding!the!quantity!of! redundancy!data!to!introduce!in!a!video!transmission!in!a!VANET!secenario.! !
Chapter!6!Robust!and!Scalable!Streaming!in! Heterogeneous!and!Dynamic!Scenarios! ! ! 72! 6.2.1 Video.Transmission.over.VANET. ! There! has! been! a! few! prior! works!in! the! field! of! interEvehicle! video! communications.! However,! almost! all! of! them! deal! with! short! message! communications!between!vehicles.!Authors!in![198]!propose!an!architecture!for! video!streaming!over!VANET,!but!no!real!video!data!was!used!in!their!simulation! and!only!the!delay!is!reported!in!their!experimental!studies.!! ! In! [199],! authors!discussed! two! routing! protocols:! Source! Based! Forwarding! (SBF)! and! Receiver! Based! Forwarding! (RBF)! applied! to! VANET! networks.! Authors!considered!different!traffic!conditions!for!data!forwarding!to!evaluate! video!streaming!between!platoons!of!vehicles.! !! In!addition,!video!streaming!communications!over!VANET!are!influenced!by!the! high! channel! errors! of! the! vehicles! in! urban! traffic! environments.! The! high! packet!loss!and!limited!communication!range!of!the!vehicles!incur!frequent!link! disconnection!and!even!network!partition.!Authors!in![201]!have!combined!data! mulling!techniques!with!three!strategies:!network!coding![200],!erasure!coding,! and!repetition!coding.!Specially,!vehicles!in!the!opposite!direction!are!exploited! as! data! mules! to! relay! multimedia! data! to! other! vehicles! to! overcome! intermittent! connectivity! in! sparse! vehicular! ad! hoc! networks.! However,! the! analysis! of! the! delay! for! relaying! multimedia! data! is! based! on! a! theoretical! mathematical!model.!Authors!in![202]!investigated!the!emergency!warning!video! dissemination!to!a!platoon!of!vehicles!in!an!accident!environment.!A!network! coding! algorithm! was! applied! for! emergency! video! dissemination.! The! performance! evaluation! reveals! that! network! coding! is! reliable! for! video! dissemination!over!VANET!especially!in!high!channel!loss!conditions.!Moreover,! the! authors! analytically! showed!that! network! coding! reduces! delivery! delay! across!platoons!via!data!mulling.!However,!all!these!approaches!did!not!consider! an!error!resilient!scheme!to!improve!the!perceived!video!quality!in!high!channel! loss!conditions!in!a!vehicular!network!scenario.! ! Moreover,! in! current! literature! there! can! be! found! methods! based! on! fuzzy! inference! systems.! Some! authors! [199]!have! used! entropyEbased! fuzzy! logic! techniques!to!implement!fuzzy!controllers!with!the!help!of!entropy!metricEbased! metrics! to! reduce! the! number! of! route! reconstructions! whilst! being! able! to! provide!QoS!in!ad!hoc!networks.!In![200]!authors!introduced!a!fuzzy!Petri!net! agent!that!is!implemented!in!each!node!to!learn!and!adjust!itself!to!according! dynamic!conditions!in!multicast!ad!hoc!networks.!In!this!section!we!introduce! our!fuzzy! based! redundancy! controller,! which! uses! two! metrics! to! adjust! the! value!of!redundant!packets.! 6.2.2 MDCRbased.Approach. ! As!seen!in!4.3.1.1,!video!coding!schemes!such!as!MDC!or!SVC!are!used!to!enhance! error! resiliency.! SVC! divides! the! video! file! into!different!layers! referred! to!as! base! layer! and! subsequent! depending! enhancement! layers! in! a! hierarchical! manner.! The! base! layer! is! the! most! important! layer! while! the! enhancement! layers! are! referenced! to! the! base! layer.! The! enhancement! layers! cannot!be!
Part!II:!Scalable!and!Robust!Media!Streaming!! ! ! 73! reproduced! independently! to! the! base! layer.! In! contrast! to! SVC,!MDC! splits! (Figure!6.3)!the!video!signal!into!multiple!subEstreams!where!each!of!the!subE streams!(descriptors)!can!be!reproduced!independently.!! ! Then,!thanks!to!source!coding!techniques,!receivers!can!make!a!reconstruction!of! the! video! file! when! any! of! the! subEstreams! is! received.! The! quality! of! the! reconstructed! video! file! is! proportional! to! the! number! of! descriptors! being! received.!Thus,!the!more!descriptors!are!received,!the!better!the!perceived!video! quality.! Therefore,! MDC! is! preferable! in! extreme! environments! like! VANET! because!it!provides!increased!resilience!to!packet!losses!by!multiple!streams!that! can!be!decoded!independently.!The!main!parts!of!MDC!system!are!the!splitter! and!the!merger.!The!splitter!is!implemented!in!the!source!vehicle.!The!first!step! of!MDC!encoder!is!the!preEprocessing!of!the!video!stream!in!order!to!obtain!the! different!N!descriptions!at!the!video!source,!which!can!be!coded!and!displayed! independently.!Next,!each!encoded!descriptor!is!ready!to!be!transmitted.! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Figure!6.13!System!architecture! 6.2.3 Random.Linear.Network.Coding.Approach. ! This!work!proposes!to!use!Random!Linear!Network!Coding!(RLNC).!When!NC!is! applied!in!!the!source!node,!the!video!packets!are!divided!into!generations!with! the! same! decoding! deadline! [202].! This! approach! treats!each! generation! as! a! vector!and!applies!linear!combinations!before!transmitting!the!data!packets.!In! more!detail,!let!N1,!N2,!N3,…,!NK!be!K!native!packets!in!a!generation.!The!video! source!applies!linear!combinations!on!these!K!native!packets,!and!the!output!is!j! coded!packets!which!are!referred!as!Y1,!Y2,!Y3,!…,!Yj!,!where!!𝑌 !=𝑒!,! ! !!!𝑁!,!and!j! =!1,!2,!3,…,h.!The!set!of!coefficients!𝑒 !,!=𝑒 !,!,𝑒 !,!,𝑒 !,!,…,𝑒 !,!!∈!𝐺𝐹(2!)!denotes!
Chapter!6!Robust!and!Scalable!Streaming!in! Heterogeneous!and!Dynamic!Scenarios! ! ! 74! the!encoding!vector!which!is!randomly!selected!at!the!source!node!to!encode!the! native!packets.! ! Intermediate! nodes! collect! the! encoded! packets! of! a! specific! generation! and,! then,!reEencode!the!buffered!packets.!When!an!intermediate!node!has!received!u! encoded!packets!of!a!given!generation,!then!it!will!select!a!new!set!of!coefficients! 𝜍!,!=𝜍!,!,𝜍!,!,𝜍!,!,…,𝜍!,!!∈!𝐺𝐹(2!).! Thus,! the! outgoing! packets! of!the! intermediate!nodes!are!X1,!X2,!X3,!…,!Xk!where!𝑋!!=𝜍!,! ! !!!𝑌 !.!Note!that!the!new! set! of! coefficients! with! respect! to! the! native! packets! is! 𝛾!,!=𝛾!,!,𝛾!,!,𝛾!,!,…,𝛾!,!,! where!𝛾!,!!=𝑒 !,! ! !!!𝛾!,!.! Then! the! intermediate! nodes!embed!the!coefficients!in!the!header!of!the!outgoing!reEencoded!packets!to! allow! their! practical! decoding.! When! the! destination! has! received! K! coded! packets,!it!first!checks!the!linear!independence!of!the!coefficients!in!the!header! of! the! received! coded! packets.! Next,!it! builds! K! x! K! matrix! using! the! coded! packets.!The! rows! of! the! resulting! matrix! represent! the! coefficients! of! coded! packets.!Afterwards,!it!calculates!the!inverse!of!the!coefficients!matrix!and!then! multiplies!it!with!the!received!coded!packets.!!A!more!detailed!explanation!on! how!to!perform!a!practical!coding!and!decoding!process!can!be!seen!in![132].!! 6.2.4 Proposed.Joint.Source.Coding.and.Network.Coding.Approach. ! Wireless!nodes!will!use!802.11!MAC!layer!to!communicate.!In!the!protocol!stack! each!protocol!layer!adds!all!necessary!information!to!the!incoming!data.!In!the! application! layer,! specific! headers! are!added! whenever!needed.! Source! and! destination!IP!addresses!and!port!numbers!are!added!by!network!and!transport! layers!respectively.!These!addresses!ensure! endEtoEend! delivery!of!packets.!In! case!of!link!disconnection!the!network!layer!drops!missing!packet.!In!addition,! fast!channel!variations!at!the!physical!layer!will!produce!packet!loss!at!the!above! layers.!Thus,!in!order!to!increase!the!robustness!of!the!video!streaming!system!in! this!VANET!scenario,!the!protocol!stack!should!be!modified!by!embedding!data! coding! approaches! to! combat! packet! losses! (adopting! then! a! cross! layer! solution).! In! this! section! we! propose! to! achieve! this! thanks! to! a!joint! source! coding!and!NC!for!improving!video!streaming!in!vehicular!scenarios.!! ! The! overall! block! diagram! of! the! proposed! joint! sourceEnetwork! coding! is! depicted! in!Figure! 6.14.! In! our! video! streaming! system,! a! single! video! source! transmits!video!descriptors!to!a!group!of!receivers!in!the!VANET!network.!MDC! is!applied!for!robust!transmission!in!this!scenario.!The!MDC!generates!several! descriptors! that!are! independently! decodable.! These! descriptions! are! passed! down!to!the!next!protocol!layers!for!performing!the!endEtoEend!delivery.!! ! Furthermore,! we! implemented! RLNC! mechanisms! between! network! and! MAC! layers!running!over!an!IEEE!802.11!MAC!protocol.!The!reasons!for!this!were:!! ! • First,!processing!at!lower!layers!(physical!and!MAC!layers)!are!faster!than! upper!ones.! ! • Second,!to!provide!transparent!NC!operations!to!upper!protocol!layers.!!
Part!II:!Scalable!and!Robust!Media!Streaming!! ! ! 75! At!the!NC!shim!layer,!each!description!is!divided!into!numbers!of!generations.! This!division!depends!on!the!size!of!the!generations!and!MDC!descriptions!video! streams.!! ! The! outgoing! coded! packets!are! identified!by! adding!a!generationEID! and! descriptionEID! into! its! specific! headers.! This! information! is! useful! for! the! receiver!to!merge!generations!and!descriptions!at!the!NC!and!application!layers! respectively.! If! a!receiver!collects!enough! linearly!independent! coded!packets,! the! decoder! NC! component! will! be! able! to!obtain!(recover)!the! original! data! belonging!to!that!generation.!! ! Regarding!the!encoded!video,!frames!depend!among!them!(B!and!P!frames).!The! loss!of!one!frame!may!cause!other!frames!to!be!useless!or!not!decodable.!In!other! words,!in!certain!network!conditions!a!receiver!may!not!be!able!to!decode!the! original!packets!that!belong!to!the!same!generation,!because!it!does!not!receive! enough! innovative! packets! based! on! its! maximum! low! capacity!and,! consequently,! some! frames! of! a! Group! of! Pictures! (GOP)! may! be! lost.! If! this! happens,!MDC!can!compensate!the!effect!of!coded!packet!loss.!This!is!because! one!description!is!divided!into!multiple!generations!while!in!NC!the!effect!of!one! missing!generation!severely!affects!the!whole!video!file!due!to!tight!correlation! between!generations!to!reproduce!original!video.!Therefore,!a!reliable!approach! based!on!MDC!and!NC!is!proposed!to!improve!the!video!streaming!service!by! reducing!the!multiple!packet!losses!in!VANET!scenarios.!The!main!drawback!is! that!this!method!intrinsically!adds!some!redundancy.!! ! ! Figure!6.14!Proposed!joint!source?network!coding!(dark!blocks)! 6.2.5 Proposed.Fuzzy.Logic.Redundancy.Control. ! Fuzzy! logic! simulates! the! interpretation! of! uncertain! sensed! information,! as! a! human! brain! would! do.! The! appropriate! decision! making! process!of! fuzzy! inference!systems!depends!on!the!precise!design!of!membership!functions!and! fuzzy!inference!rules.!However,!in!VANET!the!right!decisionEmaking!process!is! difficult!to! obtain!due!to! uncertain/random! movement! of! vehicles! and! the!
Chapter!6!Robust!and!Scalable!Streaming!in! Heterogeneous!and!Dynamic!Scenarios! ! ! 82! applying!the!proposed!approach.!After!that,!during!offline!analysis,!we!calculated! the!average!packet!loss!rate!through! a!comparison!of!the!receiver!and!source! trace!files.!We!observed!that!the!instantaneous!packet!loss!rate!is!increasing!in! both! approaches!and! the! overall! packet! loss! rate! is! lower! for! the! proposed! approach!than!that!for!the!NC!approach!as!depicted!in!Figure!6.18!b).!! ! Initially,! there! is! small! difference! of!instantaneous! packet! loss! values! for! the! proposed!approach!and!the!NC!approach!due!to!limited!channel!variations!(less! bit!error!rate!and!fading!of!the!channel)!as!well!as!less!frequent!link!disruption.! Consequently,! the! number! of! lost! packets! decrease.! As! mobility! increases,! the! channel! instability! (high! bit! error)! and!intermittent! connectivity! increase.! As! result,! packet! loss! increases! in! both! approaches.! However,! the! NC! has! more! coded!packet!loss!than!the!proposed!approach!at!high!speed.!This!is!because!one! lost! packet! will! probably! generate! multiple! losses! in! subsequent! packets.! However,! MDC! increases! error! resiliency! of! NC! by! generating! multiple! descriptions.! We! observed! a! similar! trend! when! measuring! application! layer! throughput! as! we! vary! the! speed! from! low! to! high! in! Figure! 6.18! c).! The! NC! approach! shows! a! decrease! in! throughput! due! to! high! speed! of! vehicles.! This! leads! to! high! coded! packet! loss.! Regarding!application! layer! throughput,! it! almost!does!not!change!at!high!speeds.!This!is!because!high!coded!packet!loss! (due! to! high! speed)! at! the! lower! layers! reduces! effective! application! layer! throughput!as!well!as!increases!bandwidth!variations.! ! As!seen!in!this!section,!the!NC!operations!are!implemented!above!the!MAC!layer! while! MDC! operations! are! embedded! at! the! application! layer.! The! MDC! descriptions!are!adapted!with!NC!generations.!This!two!stage!coding!mechanism! increases! the! robustness! of! video! streaming! in! vehicular! networks.! Moreover,! the!NC!redundancy!is!adjusted!using!a!fuzzy!inference!system!controller.!Then,! the!tuning!of!the!amount!of!redundancy!was!based!on!vehicular!traffic!density! and! SNR! of! the! communication! channel.! NSE2! extensive! simulations! were! successfully! carried! and! showed!significant! gains! in! terms! of! average! video! quality,! application! layer! throughput! and! average! packet! loss! rate.! The! video! streaming!with!NC!has!been!compared!to!the!proposed!joint!coding!approach! and!the!proposed!scheme!gives!better!performance.! ! 6.3 Reliable. Video. Streaming.over. VANET. using. FEC. mechanisms. ! FEC!mechanisms!can!be!applied!to!different!symbols!with!in!a!packet!(bit,!byte,!a! block!of!bytes).!In!addition!to!that,!FEC!can!be!used!in!different!Open!System! InterEconnected! (OSI)! layers! such! as! application,! network,! Physical! and! MAC! layer.! In! this! thesis,! FEC! is! applied! to! complete! packets! in! application! layer,! which! is! known! as! packet! level! FEC! [242].! This! technique! is! able! to! recover! packet!losses!without!retransmission!request!(retransmission!of!lost!packets!in! large!scale!video!transmission!is!often!not!practical)![241].! !
Part!II:!Scalable!and!Robust!Media!Streaming!! ! ! 83! Packet! level! FEC! is! a! mechanism! for! protecting! RTP! payloads! against! packet! errors! by! adding! specific! FEC! redundant! data! to! the! transport! stream.! Furthermore,!the!packet!level!FEC!is!combined!with!the!interleaving!technique! to!increase!the!error!protection!efficiency.!This!is!because!the!combined!schemes! can! scramble! correlated! burst! packet! losses! and! recover! them.! However,! interleaving! requires! additional! delay! when! interleaving! depth! (m)! and! block! size!(n)!is!too!large.!Thus,!it!is!necessary!to!adaptively!monitoring!the!packet!loss! pattern! of! wireless! channel,! in! order! to! apply! an! effective! interleaved! FEC! protection.!! ! In!VANET,!the!position!and!distance!between!vehicles!are!variable.!In!this!case,! the! packet! error! rate! and! loss! pattern! also! are! variable! between! source! and! destinations.!Actually,!approaches!like![243][244]!use!interleaved!FEC!to!protect! wireless!channel!against!burst!packet!loss.!However,!these!approaches!are!error! resilient!to!static!wireless!networks,!position!variation!of!wireless!nodes!were! not!taken!into!consideration.!Still,!most!of!the!works!focusing!on!static!wireless! or! low! mobility! wireless! networks.! Therefore,! an! error! resilient! scheme! is! needed!to!be!addressed!for!reliable!video!geocasting!in!urban!vehicular!traffic! condition.! ! Next,!we!propose!a!scheme!based!on!packet!level!interleaving!FEC!for!reliable! video!geocasting!over!VANET![GP4].!The!proposed!error!resilient!scheme!is!able! to!tackle!the!above!mentioned!issues.!The!first!phase!of!this!process!generally! consists!of!the!system!architecture!of!proposed!error!resilient!scheme.!The!aim! of!this!architecture!is!to!demonstrate!the!functions!of!the!proposed!scheme.!The! second! phase! consists! of! demonstrating! real! time! video! streaming! and! RTP/RTCP!protocols.!This!RTCP!report!provide!accurate!feedback!that!indicates! for!each!transmitted!packet!per!frame,!whether!it!was!loss!or!received.!In!the! third! phase,! we! adaptively! vary! the! amount! of! redundancy! according! to! the! wireless!channel!condition.!This!adaptive!variation!is!based!on!RTCP!report!of! farthest!vehicle.!The!fourth!phase!is!based!on!the!validating!of!proposed!scheme! based! on! simulations! (NS! 2),! showing! consistent! gain! in! PSNR! as! well! as! maximizing!the!protection!efficiency!in!urban!vehicular!scenario.! 6.3.1 Video.Transmission.over.Wireless.Networks. ! Recent! years,! error! resilient! mechanisms! based! on! Automatic! Retransmission! Request! (ARQ)! and! FEC! are! widely! used! to! correct! video! stream! errors! [242][245].!The!extensive!studies!in!wireless!multimedia!communications!have! shown!that!the!effect!of!FEC!scheme!on!packet!errors!yields!better!bandwidth! utilization!and!lower!delay!than!ARQ.!Thus,!FEC!schemes!are!increasing!error! resilient!in!wireless!multimedia!communications![243].!The!most!popular!FEC! scheme!is!ReedESolomon!(RS)!codes!to!generate!packet!level!FEC!blocks.!A!FEC! coder!is! a! block! coder! that! takes! a!block! of! k!source! packets! as! input! and! produces!n!FEC!packets!as!output ()nk> .!In!the!receiver,!the!original!video!data! can! be! regenerated,! if! the! number! of! packet! errors! is! less! than! decoding! threshold!for!the!FEC!code.!On!the!other!hand,!interleaving!techniques!are!used! to!convert!burst!losses!to!equivalent!numbers!of!isolated!packet!losses.!In!this! way,!it!can!be!used!to!increase!FEC!efficient!recovery.!
Chapter!6!Robust!and!Scalable!Streaming!in! Heterogeneous!and!Dynamic!Scenarios! ! ! 84! ! However,! the! efficiency! of! FEC! recovery! depends! upon! both! the! size! of! FEC! blocks! and! number! of! source! packets! that! are! interleaved! and! scrambled.! Admittedly,! it! is! necessary! to! estimate! the! channel! dynamicity! through! the! network! level! metrics! (packet! loss! rate)! to! change! the! amount! of! FEC! redundancy!and!interleaving!depth.!In![246],!authors!proposed!an!adaptive!FEC! mechanism!for!minimizing!end!to!end!video!distortion.!In!this!mechanism,!the! decision!of!packet!transmission!is!based!on!bandwidth!rate!constraint.!In![247],! authors!studied!an!error!control!adaptive!mechanism!based!on!the!packet!traces! of!Wireless!LAN.!In![248],!authors!proposed!efficient!packetElevel!interleaving! with! RS! coding.! Furthermore,! literatures! also! suggest! an! algorithm! based! on! delayEaware!for!minimizing!delay!generated!due!to!interleaving.!They!have!also! shown!that!packetElevel!interleaving!with!FEC!results!in!better!video!quality.!! ! Some! literatures! also! introduce! the! RTCP! adaptive! feedback! which! is! used! to! optimize!the!amount!of!FEC!redundancy.!However,!none!of!them!look!into!the! amount!of!packet!loss!variation!which!is!carried!by!RTCP!feedback!with!different! position!of!wireless!nodes.! In!vehicular!networks,! the!mobile!nodes! represent! vehicles! that! are! travelling! in! a! higher! range! of! speed.! Hence,! the! network! topology!changes!very!fast.!This!mobility!causes!on!one!hand,!different!distances! between! source! and! destinations! (in! the! geocast! region),! on! the! other! hand! different! speed! of! destinations.! In! both! cases! the! packet! loss! pattern! among! different! receivers! are! different! with! respect! to! the! source,! thus! the! feedback! RTCP! from! different! receivers! have! different! packet! loss.! Thus,! this! distance! variation!leads!to!different!packet!loss!pattern,!hence!different!perceived!video! quality!of!receivers.! 6.3.2 Geocasting.over.VANET. ! InterEvehicle!position!based!communication!has!been!found!to!be!more!suitable! for! VANET! environment.! In! this! case,! the! physical! positions! of! vehicles! are! required,!in!order!to!facilitate!communication!in!high!speed!vehicular!scenarios! [251].!Thus,!cars!are!assumed!to!be!provided!by!Global!Positioning!System!(GPS)! E! enabled! to! know! their! geographic! position.! In! addition! to! that,! each! vehicle! periodically!broadcasts!a!beacon!to!obtain!the!information!of!neighbour!nodes! (see! our! contribution! [GP5]!and! APPENDIX! V! ).! This! information! enables! the! geocast! services! over! VANET.! Geocasting! is! basically! a! location! based! multicasting! [249].! The! objective! of! geocasting! is! to! deliver! information! to! a! group!in!a!specified!geographic!area.!! ! The! basic! access! method! IEEE! 802.11! is! based! on! Distributed! Coordination! Function!(DCF).!A!node!is!initiating!the!transmission!after!the!sensed!channel!is! idle.! This! mechanism! is! based! on! CSMA/CA! protocol! to! schedule! the! medium! accessing.! Although! DCF! is! simple! and! efficient,! it! cannot! support! Quality! of! Service!(QoS)!for!multimedia!applications.!It!is!for!this!reason,!802.11e![250]!is! developed!for!better! access! mechanisms! and!supports!QoS.! The! IEEE! 802.11e! Enhanced!Distributed!Channel!Access!(EDCA)!is!designed!to!enhance!the!802.11! DCF!by!providing!the!required!QoS!mechanisms![252].!In!EDCA!(as!in!DCF)!the!
Part!II:!Scalable!and!Robust!Media!Streaming!! ! ! 85! multicast!traffic!is!defined!as!an!unreliable!service,!i.e.,!it!does!not!include!the!use! of!Acknowledgement!(ACK)!frames.! 6.3.3 Proposed.architecture. ! The! architecture! of! the! proposed! scheme! for! video! geocasting! over! VANET! is! shown!in!Figure!6.19.!The!basic!idea!of!the!proposed!scheme!architecture!lies!on! implementing! streaming! of! video! from! single! vehicle! (Source)! to! a! group! of! vehicles!(Receiver!1!and!2)!in!the!urban!area!scenarios!!(see!Figure!6.19).!The! source! generates! a! video! file! that!is! stored! in! raw! video! format.! The! encoder! receives! the! raw! video! file,! and! then! it! encodes! to! bit! streams.! The! frames! of! coded!bit!streams!become!input!to!FEC!coder,!which!applies!coding!redundancy! at!a!specified!rate.!This!amount!of!redundancy (,)nk !depends!on!RTCP!feedback.! Next,!as!an!error!resilient!scheme,!interleaving!is!applied!on!a!group!of!packets.! After! interleaving! technique,! RTP! packets! are! sent! over! vehicular! network! wireless! channel.! The! proposed! scheme! is! implemented! in! urban! area! of! vehicular!scenario,!in!which!vehicles!are!running!with!moderate!speed.!! ! RTP! media! streams! are! transmitted! through! a! wireless! channel.! The! channel! error! causes! packet! corruption! in! Receiver! 1! and! 2.! However,! the! number! of! packet!losses!is!different!due!to!different!distances!of!vehicles!with!respect!to!the! video! source.! Afterwards,! both! receivers! depacketize!the! RTP! video! packets.! After!that,!the!video!packets!are!deinterleaved!to!scramble!the!burst!losses,!to! separate!losses.!Next,!FEC!redundant!data!is!used!to!correct!corrupted!packets!in! a!given!block!of!packets!in!a!specified!frame.!Next,!it!can!be!compared!with!the! source! video! data.! In! this! architecture,! the! video! source! vehicle! receives! the! RTCP!feedback!from!each!receiver!to!accurately!capture!the!packet!loss.! ! RTP! is! designed! to! be! independent! of! the! underlying! transport! and! network! layers.!In!order!to!enable!real!time!transmission!and!play!out!at!the!receiver,!the! RTP!packet!header!carries!information!like!sequence!numbers!and!time!stamps.! A!receiver!uses!the!sequence!number!to!detect!loss!packets!and!time!stamp!to! determine!when!to!play!out!received!data.!On!the!other!hand,!Real!Time!Control! Protocol!is!used!to!monitor!the!QoS!of!the!ongoing!session.!This!feedback!signal! carries!statistics!information!(packet!loss,!round!trip!time,!and!jitter)!related!to! the!receivers!in!the!wireless!session.! ! The!intended!receivers!flood!RTCP!messages!to!the!network.!However,!we!used! the!proposed!method!in![253],!which!is!useful!for!single!source!and!a!group!of! receivers.!Thus,!the!unicast!RTCP!feedback!from!different!nodes!are!received!by! the!video!source!rather!than!it!is!flooded!into!the!whole!network.! ! The!periodic!RTCP!report!is!the!critical!parameter!that!must!be!considered!in!the! FEC!adaptation!system.!The!reason!for!this!is!that!channels!between!source!and! receivers! exhibit! varying! packet! loss! rates! over! time.! The! frequency! of! the! receiver!reports,!which!give!to!the!sender!an!estimate!about!the!network!loss! rate!and!other!parameters,!may!reduce!the!responsiveness!of!the!FEC!scheme,! leading! to! suboptimal! FEC! efficiency.! A! high! frequency! would! increase! the! responsiveness!with!channel!variations.!This!leads!to!high!variations!between!
Chapter!6!Robust!and!Scalable!Streaming!in! Heterogeneous!and!Dynamic!Scenarios! ! ! 86! successive! measurements! and! instability! due! to! excessive! feedback! traffic! overhead.!Low!frequency!would!have!good!stability!and!low!overhead!but!poor! responsiveness.!In!this!work,!the!receiver!sends!back!the!feedback!report!after!a! periodic!amount!of!time!to!achieve!the!tradeEoff!between!source!responsiveness! and!network!overhead.! ! ! ! ! ! ! ! ! ! ! ! ! ! Figure!6.19!Video!streaming!architecture!for!VANET! In! vehicleEtoEvehicle! video! communications,! the! video! source! receives! periodically!all!the!RTCP!reports!of!the!receivers.!The!packet!loss!rate,!which!is! carried! by! !theRTCP! report,! depends! on! the! distance! between! source! and! receivers.!Therefore,!the!proposed!scheme! uses!the!receiver!reports!based!on! vehicular!position!with!respect!to!the!source.!This!report!is!used!to!update!the! Receiver!1! Source! ! Packets! FEC!Packet! RTP!Packets! ! Corrupted!RTP!Packet! !!!!!!De!Packetized!Corrupted!RTP!Packet! ! ! Receiver!2! ! !
Part!II:!Scalable!and!Robust!Media!Streaming!! ! ! 87! amount!of!redundancy!and!interleaving!level!to!derive!effective!QoS!parameters.! Packet! level! FEC!with! interleaving! can! provide! reliability! for! video! geocasting! over!error!prone!vehicular!wireless! channel.!In!the!next! section!the!proposed! error!resilient!scheme!is!discussed.! 6.3.4 Vehicles.and.Communication.Model. ! Vehicles! are! assumed! to! be! equipped! with! a! Global! Positioning! System! (GPS).! Vehicles! also! transmit! periodic! beacons! [GP5].! Therefore,! vehicles! know! their! own!geographic!location!and!can!be!easily!synchronized.! ! Each! vehicle! broadcasts! a! beacon! (MAC! broadcast:! which! are! used! for! local! topology!sensing!only,!it!is!not!reEbroadcasted)!with!a!range!of!about!200!meters.! The!content!of!these!beacons!are!helpful!to!allow!vehicles!to!communicate!and! synchronize.! This! beacon! is! used! in! our! error! resilient! scheme! to! establish! communication!between!video!source!and!receivers!in!geocast!region.!! ! The! beacon! is! broadcasted! twice! a! second! and! contains! vehicles! information! such!as:!address!(ID),!location!and!speed.!Each!vehicle!maintains!a!data!base!to! store!information!of!vehicles!within!its!transmission!range!(as!is!introduced!also! in![GP5],!they!can!be!used!for!exchanging!context!information).!Upon!receiving!a! beacon,!each!vehicle!updates!its!data!base!with!new!vehicles!information.!The! database!is!checked!every!second!by!the!vehicle!in!our!simulated!scenario.! ! 6.3.5 The.FEC.Estimation.Algorithm. ! The!summary!of!the!proposed!algorithm!is!shown!Figure!6.20.!All!vehicles!in!the! same!communication!range!know!their!position!and!speed,!the!beacon!can!be! used! to! get! these! informations.! In! our! simulation! scenario,! the! source! and! receivers! are! always! in! the! same! radio! range.! In! other! words,! there! is! no! intermittent! connectivity! between! source! and! destinations.! When! source! receives! RTCP! feedback! from! all! receivers,! first! it! checks! the! distance! of! receivers!(we!have!experimented!this!technique,!but!it!creates!a!large!amount!of! overhead,!thus,!we!have!compared!the!distance!of!receivers!based!on!feedback! packet!loss!rate).!Then,!it!selects!the!RTCP!report!of!the!farthest!node!(highest! loss).!Next,!it!extracts!the!packet!loss!rate!(line!1,2).!If!packet!loss!rate!is!bigger! than!a!threshold,!FEC!redundancy!is!not!applied!to!video!packets.!The!reason!of! this! are:! (1)! low! value! of! Peak! Signal! to! Noise! Ratio! (PSNR)! to! guarantee! acceptable!video!quality,!(2)!to!improve!utilization!bandwidth!(line!3,4,5,6).! ! The! efficiency! of! FEC! recovery! is! reduced,! when! the! number! of! packet! loss! is! greater!than! the!calculated!FEC!redundancy!(which! is!relying!on!the!previous! RTCP!feedback!report).!Therefore,!the!new!value!of!feedback!packet!loss!report! is! compared! with! the! calculated! FEC! redundancy.! If! the! calculated! FEC! redundancy! is! greater! than! the! feedback! packet! loss! report,! the! value! of! FEC! redundancy! remain! the! same,! otherwise! the! new! value! of! FEC! redundancy! is! calculated!and!transmitted!along!with!media!packet!streams!(line!7,8,9,10).!!In! this!way,!we!can!keep!FEC!redundancy!to!protect!the!original!video!source!data.!
Chapter!6!Robust!and!Scalable!Streaming!in! Heterogeneous!and!Dynamic!Scenarios! ! ! 88! After! an! amount! of! FEC! redundancy! is! added! to! real! time! media! packets,! the! simple! interleaving! technique! is! applied! as! well.! This! technique! is! able! to! dynamically! adapt! the! interleaving! delay! according! to! the! wireless! channel! condition.!The!details!on!the!FEC!algorithms!can!be!seen!in![GP5].! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Figure!6.20!Feedback?based!FEC!estimation!algorithm! 6.3.6 Performance.Evaluation. ! In! the! following! sections,! through! simulation! based! study,! we! emphasize! the! ability! of! the! proposed! scheme! in! terms! of! higher! packet! loss! resiliency! and! better!perceived!video!quality.! 6.3.6.1 Simulation,Setup, ! In!this!section,!we!present!simulation!setup!to!evaluate!the!performance!of!the! proposed! error! resilient! scheme.! ! The! simulation! is! performed! using! network! simulator! (NSE2)! [255]!with! added! support! of! EDCA! developed! in! [254]!and! integrated! with! Evalvid![256].! Two! different! FEC! schemes! have! been! experimented:!one!with!fixed!FEC!(proactive!FEC:!in!which!the!amount!of!FEC!is! not!changed!in!the!ongoing!session)!and!the!other!with!the!proposed!protocol! (adaptively! changing! the! amount! of! FEC! and! interleaving! depth).! We! also! experimented!video!streaming!without!FEC.!We!measured!PSNR!quality!of!the! video!after!decoding!and!Packet!Error!Rate!(PER)!for!different!receiver!position.! !
Part!II:!Scalable!and!Robust!Media!Streaming!! ! ! 89! The!SUMO!tool![258]!has!been!employed!to!create!the!urban!scenario,!and!to! generate!mobility!traces!of!the!simulated!vehicles.!SUMO!interposes!vehicles!in! each! lanes! at! a! given! traffic! rate.! This! mobility! model! allows! us! to! simulate! vehicular! scenarios! such! as! speed! deceleration/accelerations! and! different! vehicular! traffic! conditions.! The! vehicle! which! is! assigned! as! video! source! is! generated!first!in!one!route!(each!route!has!its!own!parameters!such!as!speed,! acceleration,!deceleration).!Afterwards,!other!vehicles!are!generated!in!the!other! route.! This! is! helpful! to! control! the! distance! between! source! and! receivers.! A! vehicular! scenario! has! been! experimented,! in! order! to! show! the! effect! of! different!distances!on!the!video!quality!and!packet!loss!rate.! ! Table! 6E4! summarizes! our! simulation! settings.! All! vehicles! in! our! simulations! have!a!transmission!range!of!200!meter.!The!roadway!used!is!a!twoElane!road!of! 3! km! length.! Vehicles! enter! the! road! according! to! a! Poisson! distribution! and! travel! at! a! speed! between! (40E60)! km/hour.! The! simulation! is! run! for! 20! seconds,!resulting!in!a!total!of!25!vehicles!generated.! ! Table!6?4!Simulation!settings! Parameter! Settings! Transmission!Range!! 200m! Run!time! 20s! Vehicle!density! 25car/km! Number!of!lanes! 2! Road!length! 3Km! Communication!data!rate! 6Mbps! ! In! the! simulation,! the! Common! Intermediate! Format! (CIF)! [257]! Foreman! bit! stream!is!used!with!resolution!352x288!pixels!and!300!frames.!The!CIF!Foreman! sequence!is!encoded!with!a!quality!35.68!dB.!The!encoder!includes!three!types!of! frames:!Intra!frames!(IEframes)!that!are!independent!on!other!frames,!and!inter! frames! that! use! either! PEframes! or! BEframes! temporal! prediction! from! other! frames.!!A!number!of!mutually!dependent!frames!form!a!group!of!pictures!(GOP).! In!our!experiment,!the!GOP!size!is!set!to!12!frames.!Furthermore,!the!frame!sizes! of! I,! P! and! B! frames! are! set! to! 25,! 50! and! 225! frames! respectively.! Every! 0.5! seconds,!the!sender!receives!an!RTCP!packet!from!receivers!located!in!its!radio! range!with!a!report!of!the!current!Packet!Loss!Rate!(PLR).!After!that,!the!source! changes!amount!of!FEC!redundancy.!Furthermore,!a!1.5!second!playEout!buffer!is! used!to!reduce!the!jitter!of!video!frames!at!the!receiver.!Thus,!if!packet!arrives! after!decoding!deadline!is!discarded.!!In!order!to!make!the!results!more!precise,! each! simulation! experiments! are! executed! more! than! one! time! with! each! simulation!execution!lasting!20!second.!Later,!all!the!results!are!averaged.! ! In!our!simulations,!the!RS!(16,!12)!FEC!code!has!been!experimented!to!protect! the!transmitted!video!file.!This!FEC!code!is!applied!to!both!fixed!FEC!scheme!and! our!packet!level!adaptive!FEC!schemes.!Both!error!resilient!schemes!with!no!FEC! are!implemented!in!the!same!vehicular!scenario.!During!the!simulation,!one!of!
Chapter!6!Robust!and!Scalable!Streaming!in! Heterogeneous!and!Dynamic!Scenarios! ! ! 90! the!vehicles!is!the!video!source!and!the!others!in!its!communication!range!are! receivers.! We! restricted! the! traffic! density! to! less! number! of! receivers! to! demonstrate!the!effect!of!distance!on!the!packet!loss!and!video!quality.! 6.3.6.2 Results, ! In! this! simulationEbased! study,! the! source! first! applies! our! error! resilient! scheme,!Adaptive!Interleaved!FECEHigh!Packet!Loss!(AIFECEHPL)!in!which!the! source!takes!into!consideration!the!RTCP!feedback!with!highest!packet!loss!rate.! Next,! we! also! apply! Fixed! FEC! (FFEC)! (the! FEC! protects! the! media! packets! without!any!feedback).!Then,!NFEC!scheme!(No!FEC:!video!geocasting!without! FEC)!is!experimented!in!our!simulation!environment!to!evaluate!the!quality!of! transmitted!video.!Furthermore,!source!transmits!video!RTP!packets!over!real! vehicular! networks;! each! packet! contains! a! sequence! number! that! is! used! for! synchronization!of!media!stream!packets.!If!the!packet!is!successfully!received! by!the!destination,!the!destination!will!write!the!sequence!number!into!the!trace! file.!Subsequently,!the!receivers!trace!files!is!used!to!reconstruct!the!transmitted! video!file.!We!can!discriminate!between!receivers!distance!to!the!source!based! on!the!packet!losses!in!the!trace!files.!! ! As!a!consequence!of!variable!speed!of!vehicles,!the!distance!between!source!and! receivers!are!varied!with!time!for!both!receivers.!However,!the!average!distance! among!source!to!receiver1!is!lower!than!to!receiver!2.!Therefore,!the!average! video!quality!is!better!in!Figure!6.21!than!Figure!6.22.!!These!figures!depict!the! PSNR!values!of!the!video!frames!for!two!receivers!in!the!communication!range!of! the!source.!!We!can!observe!that:!(1)!the!video!qualities!are!improved!for!both! protection! schemes! (AIFECEHPL! and! FFEC)! against! the! scheme! without! any! protection.!(2)!As!the!distance!between!source!and!receivers!(vehicles)!increases! the!perceived!video!quality!decreases,!but!AIPFECEHPL’s!PSNR!is!still!marginally! higher!than!that!of!others!schemes.!This!is!because!the!proposed!!error!resilient! scheme:!(1)!adaptively!changes!the!amount!of!redundant!packets!in!response!of! the!RTCP!feedback!of!a!given!receiver;!(2)!takes!into!account!the!RTCP!feedback! with!highest!packet!loss!!value.!Moreover,!we!find!that!AIPFECEHPL’s!PSNR!is! almost! similar! to! FFEC! in! some! cases! (at! the! beginning! of! video! frame! transmission).! That! is! because! of! the! short! distance! between! source! and! receivers!at!the!beginning!of!geocast!session.! ! Figure!6.23!depicts!that!the!proposed!error!resilient!scheme!has!a!better!average! PSNR!for!different!distances!between!source!and!receivers.!The!trend!shows!that! the!average!value!of!PSNR!decreases!for!three!error!protection!schemes!as!the! distance!between!source!and!destination!increases.!This!is!because!the!longer! the! distance,! the!higher! the! packet! loss.! Hence,! this! leads! to!lower!perceived! video! quality.! However,! our! scheme! is! more! reliable! to! the!distance! variation! effect! due! to! dynamic! tuning! the! amount! of! FEC! and! taking! into! account! the! farthest!node!RTCP!report.!!! ! As! the! video! source! received! different! RTCP! messages! (feedback),! several! receiver!reports!were!averaged!to!get!the!packet!loss!rate.!In!our!simulation,!this! adaptive!packet!level!FEC!is!called!AIPFECEAggr.!The!measured!average!PSNR!
Part!II:!Scalable!and!Robust!Media!Streaming!! ! ! 91! values!of!two!adaptive!error!resiliency!schemes!are!plotted!in!Figure!6.24,!which! clearly! shows! the! AIPFECEHPL! scheme! has! much! better! PSNR! values! as! the! distance!increases.! ! To!compare!the!error!recovery!capability!of!the!proposed!scheme!(APFECEHPL)! with!other!schemes,!the!video!source!transmits!5267!video!packets!in!a!given! period! of! video! geocast! session.! Firstly,! we! transmit! the! video! packet! from! source!to!receivers!without!error!protection.!In!the!next!simulation!period,!we! have! repeated! the! video! transmission! by! applying! other! error! protection! schemes.!Subsequently,!during!off!line!analysis,!we!have!computed!the!number! of!loss!and!recovered!packets!through!a!comparison!of!receiver!and!source!trace! files.! Then,! we! have! recorded! the! number! of! received! and! lost! packets.! Our! proposed!mechanism!(AIFECEHPL)!recovered!a!total!of!174!RTP!media!packets! while!the!FFEC!approach!recovered!61!and!AIFECEAggre.!recovered!103!packets.! ! ! Figure!6.21!FEC!Comparison,!short!distance!between!source!and!receiver! ! ! ! ! ! ! ! ! ! ! Figure!6.22!FEC!Comparison,!long!distance!between!source!and!receiver! !
!Chapter!7!Future!Internet!Flexible!Architecture! ! ! 98! Besides,! existing! addresses! (locators! and! identifiers)! are! treated! as! another!characteristic!of!the!service/node/resource.!Furthermore,!when! used,! addressing! schemes! should! be! designed! to! be! dependent! on! the! location! of! entities! in! a! network,! but! route! independent.! This! semantic! contextEaware! serviceEderived! route! discovery! approach! provides! intrinsic!support!for!mobility,!multihoming!and!nomadism.! ! • Flexible! design! and! execution.! Network! functions! must! be! allocated! according!to!each!situation!and!not!in!a!monolithic!way.!Thus,!functions! must!be!allocated!all!along!the!route,!executing!just!the!desired!functions! at!each!hop,!section!of!hops!and!endEtoEend!and!applying!them!just!to!the! desired! transmission! unit! (bit,! frame,! packet,! etc.).! Flexible! support! for! different! semantic! schemes! or! vocabularies! for! identifying! services,! resources! and! nodes! and! to! describe! their! capabilities! must! be! also! devised.!This!flexible!support!must!be!also!extended!to!different!schemes! for!specifying!desired/requested!and!provided!QoS.! ! • Context?awareness!and!dynamic!adaptability!during!execution!time.! In! order! to! satisfy! QoS! and! QoE! requirements! for! requested! services,! context! conditions! must! be! thoroughly! considered! not! only! during! the! communication!establishment,! but! also! all!throughout!its! duration.! The! architecture!considers!the!capabilities!of!the!nodes,!services!and!network! links! to! establish! new! routes! and! to! manage! existing! ones.! As! a! result,! mechanisms!to!interchange!and!distribute!context!information!between! entities!(in!ad!hoc!and!structured!environments)!are!to!be!provided.! ! • Native!cross?layering.!CrossElayering!is!inherently!provided!in!the!sense! of! a! new! disposition! of! current! protocol! functionalities,! allowing! combinations!as!required!and!not!as!a!rigid!and!layered!structure!usually! imposes.!Eliminating!layers!automatically!translates!into!the!exclusion!of! redundant!functionalities!among!them!or!even!counteracting!those!that! could!degrade!the!quality!of!a!communication!in!a!network.! . • User! empowerment! in! service! choice! and! routing.! Given! the! diversification! and! popularity! of! the! Internet! and! the! maliciousness! of! some! of! their! players,! users! should! be! provided! with! mechanisms! that! give! them! more! control! over! their! communications.! This! control! is! reflected! in! flexible! routing! and! service! selection.! Thus,! a! service! requester!will!be!able!to!choose!from!the!set!of!discovered!services!the! specific! service! it! wants! to! consume! according! to! his! preferences.! In! addition,!and!if!so!desired,!the!requester!may!want!to!specify!preferred! and!trusted!entities!(carriers,!domains,!nodes,!providers)!and!blacklists!of! distrusted! or! malicious! entities.! In! this! way,! endEpoints! have! a! certain! degree!of!control!over!which!routes!their!communications!will!follow.!A! benefit! of! this! approach! is! that! this! is! performed! during! the! communication!establishment!and!not!after.! ! • Security.!Security!functions!must!be!fully!integrated!in!its!design.!In!our! opinion,! security! must! not! be! an! addendum.! Hence,! service!
Part!III:!ServiceEOriented!and!ContextEaware!Architecture! for!the!Future!Media!Internet! ! ! ! 99! discovery/consumption! takes! into! account! available! security! features.! Other! points! to! assure! are:! data! integrity! and! confidentiality,! plus! user! privacy! and! confidentiality.! Also,! we! believe! that! another! important! characteristic!is!traceability,!e.g.,!finding!the!path!to!the!traffic!source!for! a!specific!communication.!As! each! connection! is!established! for! service! consumption,! traceability! can! be! achieved! by! univocally! tagging! each! single! traffic! flow.! ! Therefore,! we! make! use! of! a! unique! tag! (Session! Identifier)!to!identify!and!route!each!traffic!flow.! ! A!fundamental!design!principle!followed!in!the!TARIFA!project!is!that!the!Future! Internet!architecture! must! be! designed! as!a!flexible! architecture,! adaptable!to! context!variations.!As!discussed!in![210],!a!possibility!would!be!to!design!this! network!architecture!able!to!work!with!small!devices! (e.g.!sensors)!in!limited! networks! like! (e.g.! wireless! sensor! networks).! Then,!it! should! be! easier! to! extrapolate! it! to! work! in! more! complex! environments,! without! capacity! restrictions!(e.g.!like!wired!computer!networks).!In!this!work,!authors!explain! they! want! to! avoid! the!design!of! complex! protocols! for! wired! and! backbone! networks.! Oppositely,! the! idea! is! to! design! simple! protocols! with! the! goal! to! adapt! them! to! environments! with! restrictions,! approach! that! poses! a! lot! of! implementation,!design!and!performance!issues.! 7.2 Services.Framework. ! The!proposed!solution!considers!three!basic!components:!Atomic!Services!(AS),! Atomic! Mechanisms! (AM)! and! Composed! Services! (CS).! ASs! are! individual! functions! or! roles! commonly! used! in! networking! protocols! (e.g.! acknowledgment,!sequencing,!flow!control,!etc.).!These!are!wellEdefined!and!selfE contained! functions,! used! to! establish! communications! to! create! CSs.! AMs! are! specific! implementations! for! each! AS,! which! provide! the! desired! atomic! mechanism!functionality.!An!AS!can!be!implemented!by!different!AMs,!as!shown! in!Table!7E2.!Finally,!CSs!are!a!combination!of!Atomic!Services!(AS)!that!work! together!to!provide!a!more!complex!service.!CS!logics!needs!to!be!specified!in!a! Workflow! (WF)! to! describe! the! composition! and! execution! process! of! functionalities!or!ASs!that!could!be!offered!by!different!implementations!or!AMs! [209]!(Figure!7.2).! ! The! composition! of! ASs! consists! in! discovering,! selecting,! combining! and! allocating!those!services!to!be!executed!along!the!path!from!a!Requester!Node! (RN)!to!the!End!Service!Node!(ESN)!going!through!different!Intermediate!Nodes! (IN).!In!this!context,!a!composition!process!orchestrated!by!the!RN!is!proposed! with! the! aim! to! empower! the! requester’s! control! over! the! communication! establishment.!The!RN!will!therefore!be!able!to!decide!which!discovered!services! best!meet!its!requirements!and!preferences!by!centralizing!the!process!of!service! selection,!composition!and!allocation.!This!framework!is!based!in!our!work!done! within!the!TARIFA!project.! ! ! !
!Chapter!7!Future!Internet!Flexible!Architecture! ! ! 100! ! ! Figure!7.2!Services!Framework! ! 7.3 Service.Discovery. ! As!described!in!section!5.5,!traditional!web!service!discovery!mechanisms!are! focused!on!enterprise!communications!and!uses!heavy!formats!based!on!XML.! Pervasive!Computing!Service!Discovery!Protocols!(SDP)!do!not!provide!a!unique! and! integrated! solution! able! to! work! in! a! global! heterogeneous! network.! We! hereby!propose!to!use!an!innovative!negotiation!protocol!introduced!in![210].!! ! This!negotiation!protocol!allows!discovering!a!service!into!the!network!taking! into!account!specific!requirements!established!by!the!requester.!In!addition,!it!is! simple!enough!to!be!able!to!work!in!small!and!constrained!environments!such!as! adEhoc! sensor! networks! without! infrastructure! support! and! larger! scenarios! with! infrastructure! support.! This! negotiation! protocol! integrates! service! discovery! and! service! allocation! of! services,! once! they! are! selected! and! combined.! ! The!service!discovery!process!consists!in!searching!in!the!network!for!services! under!certain!conditions,!by!means!of!a!Communication!Request!message!(Creq).! In!order!to!specify!the!criteria!that!will!guide!the!search,!a!semantic!negotiation! protocol! is! proposed.! This! message! should! specify! requester’s! service! requirements!in!terms!of:!! ! • Network!performance!parameters.! • Additional! constrains! (e.g.! geographic,! domain! restrictions! or! specific! attributes!definition!for!certain!services).! • Required!functionalities.!! !
Part!III:!ServiceEOriented!and!ContextEaware!Architecture! for!the!Future!Media!Internet! ! ! ! 101! Moreover,! service! requirements! may! be! differentiated! in! two! types! of! parameters:!restrictive!and!nonErestrictive.!Restrictive!parameters!are!those!that! are! completely! necessary! to! establish! a! communication! with! the! desired! end! service.!NonErestrictive!ones!represent!nonEmandatory!parameters!which!allow! optimizing! the! communication.! Considering! the! inclusion! of! service! requirements! in! the! request,! we! propose! the! following! generic! definition! of! a! Creq!message!where,!QoS_Requirements[i],!Context[j],!and!AS[k]!correspond!to! lists! of! QoS! requirements,! context! parameters! and! AS! attributes! respectively.! Additionally,! effects! can! be! specified! as! desired! highElevel! features! for! the! communication,!like!security!or!reliability.!Resources!of!a!service!such!as!a!film! provided!by!a!streaming!service!can!be!specified!as!another!extra!parameter.! ! Creq)=)Session_ID)&)End_Service_Name)&)QoS_Requeriments[i](min/max))&) Context[j](constraints,)preferences))&)AS[k](mandatory/optional))[&)Effects])[&) Resources]) ! Using! this! type! of! requests,! information! about! the! capabilities! of! nodes! is! discovered!through!the!network.!In!this!sense,!this!request!can!be!propagated! through! the! network! in! different! ways,! taking! into! account! the! network! knowledge!of!the!service!requester.!The!default!operation!performed!in!a!node! when!receiving!a!request!will!be!to!evaluate!if!it!can!provide!the!service!(Figure! 7.3).! If! that! is! the! case,! the! node! answers! with! a! Communication! Response! message!(Cresp)!that!will!be!transferred!through!the!reverse!path.!A!clear!benefit! of!performing!this!operation!by!each!node!is!that!it!allows!to!face!dynamic!and! frequent!context!changes.!In!the!event!the!node!may!not!be!able!to!provide!the! ESN,!it!will!propagate!the!request!to!its!neighbours!until!the!requested!service!is! found.! ! ! ! Figure!7.3!Node!logics!in!Creq!processing! One!important!issue!when!propagating!a!service!request!is!to!limit!the!scope!of! the! request! so! as! not! to! flood! the! entire! network! or! propagate! it! indefinitely.! Depending! on! the! kind! of! network,!several! approaches! can! be! adopted.! In! a! network!without!infrastructure!support!like!a!sensor!adEhoc!network!(Figure!7.4! a),! a! Time! To! Live! (TTL)! counter! can! be! set.! Oppositely,! if! the! network! has! infrastructure!support!(Figure!7.4!b),!dedicated!directory!nodes!can!perform!the! discovery! process! within! a! network! domain.! A! scalable! solution! providing! interdomain!service!discovery!is!a!challenging!issue,!although!this!topic!is!out!of! the!scope!of!this!article.!Calculating!the!optimal!path!whilst!considering!different!
!Chapter!7!Future!Internet!Flexible!Architecture! ! ! 102! constraints! is! an! NP! complete! problem![211].! However,! a! near! optimal! path! could! be! computed! taking! into! account! the! topology,! capacity! and! context! constraints!by!means!of!specific!heuristics.! ! It! is! remarkable! that! the! proposed! solution! is! agnostic! to! the! underlying! technology,! including! networks! and! devices! thanks! to! the!use! of! wellEdefined! interfaces!for!service!definition.!Moreover,!the!heterogeneity!of!the!network!can! be!faced!by!consulting!nodes!capabilities,!services!and!resources!thanks!to!the! availability! of! context! information.! Each! node! evaluates! the! incoming! service! request!and!determines!if!it!has!enough!resources!and!therefore!can!meet!QoS! requirements!to!deliver!the!demanded!services.!Due!to!the!complexity!of!solving! both,!service!and!path!selection!processes!at!the!same!time!in!a!heterogeneous! environment,!the!process!can!be!divided!into!subEprocesses:!services!discovery! and!services!composition.!! ! ! ! Figure!7.4!a)!Network!without!infrastructure!b)!Network!with!infrastructure!support! ! Services!discovery!is!the!process!of!identifying!the!nodes!that!can!provide!the! desired!end!service,!as!well!as!the!ASs!that!may!be!required!in!the!nodes!of!the! communication!path!ranging!from!the!RN!to!the!ESN.!This!phase!is!divided!into! three!steps!as!well.!In!the!first!step,!requester!requirements!are!mapped!out!to!a! service!request.!Secondly,!the!nodes!that!receive!the!query!evaluate!if!they!are! able!to!provide!the!demanded!service.!Finally,!context!information!is!consulted! to! guarantee! that! the! service! can! be! provided! under! the!required! QoS! parameters.! ! Service!composition!process!consists!in!a!prioritized!selection!and!combination! of!the!end!service!and!intermediate!ASs!among!all!the!candidates!found!during! the! service! discovery.! This! allows! optimizing! the! network! resources! during! connection!setup!by!selecting!those! services! which! minimise! the! overall! costs! when! providing! a! service.! Service! selection! must! take! into! account! domain! policies!and!the!effects!that!the!usage!of!a!service!produces!over!the!network! operation!(e.g.!delay,!congestion,!cost,!etc.).!This!is!further!detailed!in!section!7.4.! !
Part!III:!ServiceEOriented!and!ContextEaware!Architecture! for!the!Future!Media!Internet! ! ! ! 103! Furthermore,! we! propose! a! generic! definition! of! a! Cresp.! The! requester! will! receive! ‘N’! response! messages! that! specify! ‘N’! candidate! paths.! Each! of! them! contains!the!identifiers!of!the!M!path!nodes,!with!their!QoS!requirements,!ASs,! AMs.!A!Cresp!is!defined!as:! % Cresp)=)SessionID,)Node[m])(nodeID,)QoSRequirements[j],)AS[k],)AM[l]))) ! Where,! Node[m],! QoSRequirements[i],! AS[k]! and! AM[l]! are! lists! of! the! corresponding!parameters.! ) ! ! Figure!7.5!Negotiation!Process! Finally,!the!last!message!considered!in!the!negotiation!protocol!is!the!allocation! message!(Call).!It!is!used!to!specify!to!each!node!in!the!selected!path!which!ASs! and! AMs! must! be! executed.! For! this! purpose,! WFEbased! representations! are! used.!A!communication!allocation!message!(Call)!can!be!defined!as:! ! Call)=)SessionID,)Node[m])(nodeID,)WF))
!Chapter!7!Future!Internet!Flexible!Architecture! ! ! 104! Where,! Node[m]! is! a! list! of! nodes! in! the! endEtoEend! selected! path.!Figure! 7.5! shows!the!whole!negotiation!process.! 7.3.1 Scalability. ! Scalability!is!always!a!critical!issue,!even!more!considering!current!evolution!of! network!technologies,!types!and!number!of!devices,!number!and!heterogeneity! of! users! connected! to! the! network! and! amount! of! information! exchanged! through!the!network.!Scalability!can!be!limited!in!network!domains!because,!for! instance,!the!use!of!flooding!mechanisms!used!during!discovery!that!limit!the! network! domain! size! and! scope.! Hence,! semantic! identification! will! not! scale! appropriately! outside! local! domains! unless! some! infrastructure! support! is! available.!Besides,!clustering!strategies!are!needed!to!make!the!semantic!routing! approach!scalable.! ! Therefore,!as!proposed!in![GP13],!attributes!related!to!domains,!used!as!labels,! or!identifiers!to!distinguish!between!administrative!domains!and!networks!can! be! used.! The! main! difference! with! current! Internet! scheme! is! that! the! information!used!to!define!and!label!different!domains!is!not!the!same!as!that! used!nowadays.!Currently,!network!prefixes!and!addresses!are!used.!They!are! tightly!coupled!with!routing!protocols.!Nevertheless,!the!FN!should!works!with! semantic!attributes!to!achieve!such!flexibility.!FN!naming!and!addressing!scheme! should!not!be!constrained!by!their!form!and!meaning!as!is!the!case!of!current!IP! addresses!and!domain!names.! ! Hence,!any! type! of! attribute! is! supported!and!identifiers!could!take!any! form.! They!could!be!anything!that!allows!identifying!and!locating!a!service!in!a!domain.! As! examples,! service! identifiers! could! be! a! geographical! (virtual! or! not)! coordinate!bounding! the!domain!area,!a! random! label,!an!IP!address!or!other! legacy/existing! addressing! schemes! requiring! no! changes! in! their! original! architecture.! Using! one! type! of! attribute! or! another! will! depend! on! the! considered!scenario!and!required!routing!information!(e.g.!geographical!routing! will!require!the!use!of!coordinates).!! ! Thus,!high!scalability!in!structured!environments!could!be!achieved!by!means!of! service! discovery! that! rely! on! special! entities! providing! the! required! infrastructure/signaling!services!whilst!avoiding!flooding.!Some!approaches!can! be! adopted! such! as! introducing! the! use! of! a! semantic! resolver! instead! of! performing!semantic!flooding.!The!goal!of!a!semantic!resolver!element!would!be! to!process!semantic!descriptions!and!map!them!to!identifiers/locators.!! ! And!the!following!infrastructure!services/entities!would!be!required!according! to![210]:! ! • Semantic! resolver:! resolves! semantic! descriptions! and! maps! them! to! identifiers/locators.!This!includes!mapping!identifier!attributes!to!locator! ones! and! retrieving! information! from! Context! Manager! (CM)!and! resolving!it.!These!resolution!services!should!be!designed!to!concretize!
Part!III:!ServiceEOriented!and!ContextEaware!Architecture! for!the!Future!Media!Internet! ! ! ! 105! semantic! identification! descriptions! into! more! concise! and! directly! routable!identifiers!making!extensive!use!of!domain!related!attributes.! ! • Context! Manager:!manages!context!information!for!a!specific!network! domain! maintaining! a! knowledge! plane! (Tuple! space/DHTs/Directory)! with!identifiers!and!related!profiles.!Nodes!feed!the!shared!space!with!its! own! information! on! node! and! service! capabilities,! whilst! monitoring! services!update!link!and!network!state.!! ! • Dynamic!Point!of!attachment/configuration!manager:!provides!initial! configuration! parameters! and! manages! locator! assignment! (mobility).! Provides! coupling! between! client! configuration! and! infrastructure! services! feeding! the! CM! with! the! assigned! locator! and! the! client! with! domainErelated!configuration!data.! 7.4 Service.Composition. ! The!RN!to!empower!requesters’!control!over!the!communication!will!orchestrate! services.! The! requester! will! always! decide! which! services! will! be! chosen! according! to! the! discovered! ones.! This! selection! will! be! done! by! means! of! choosing!a!selection!of!the!ASs!that!the!requester!desires!to!receive!considering! requirements! are! met.! To! achieve!this,! it! is! important! to! have! an! expressive! semantic!negotiation!protocol!to!allow!matching!the!requested!services!with!the! services!available!in!each!node!until!the!end!service.! ! The! information! discovered! in! the! network! is! organised! in! a! graph! structure! where!nodes!of!the!graph!are!the!nodes!of!the!network.!However,!the!graph!can! be!represented!as!a!tree!of!disjoint!branches!since!the!Cresp!obtained!from!the! discovery!process!can!be!directly!mapped!into!the!structure!shown!in!Figure!5.!! ! This!work!divides!the!composition!process!to!create!a!CS!into!four!phases.!To! solve!the!service!composition!process,!we!divide!the!process!into!the!following! main!subEprocesses:!Filtering,!AM!Scoring,!AS!Composition!and!Path!Selection.! ! In!this!research!we!explored!different!composition!algorithms.!Each!of!them!has! its! own! properties! in! terms! of! response! time,! performance,! memory! usage,! accuracy,! etc.! It! remains! as! future! work! evaluating! and! comparing! different! algorithms!for!performing!service!composition!and!selection!tasks.!Note!that!in! this! thesis! we! have! validated! mechanisms! to! combine! different! network! level! services.!However,!this!composition!should!be!very!fast!in!order!to!not!delay!the! establishment!of!a!requested!communication.!In!this!thesis,!we!implemented!in!a! real! prototype!(section! 7.6)! a! service! composition! algorithm! based! on! A*! in! order!to!achieve!an!accurate!solution!for!the!different!combinations!of!services! we!could!calculate.!Nevertheless,!we!need!to!evaluate!if!we!need!such!kind!of! flexibility,!full!flexibility,!when!dealing!with!bigger!services!sets!(more!variables! and!cases!to!evaluate)!at!network!level.!Obviously,!we!can!apply!this!algorithm!at! higher!levels,!such!as!application,!where!we!can!benefit!from!more!processing! power!capabilities.!However,!at!network!level!we!can!not!assume!this.!A!way!of!
!Chapter!7!Future!Internet!Flexible!Architecture! ! ! 106! solving!this!situation!is!to!store!preEestablished!compositions!of!services!in!the! form!of!a!template!and,!then,!decide!which!fits!better!in!each!situation!according! to!the!communication!goals.!In!this!sense,!the!study!of!the!fuzzy!logic!algorithm! implemented,!simulated!and!evaluated!in![GP5]!and![GP9]!(section!6.2)!would!be! considered!as!a!candidate!algorithm!for!deciding!which!template!of!services!will! be!used!for!a!communication,!which!atomic!service!or!atomic!mechanism!will!be! used!during!the!composition!process!or!which!parameters!should!be!adjusted!in! order!to!obtain!the!desired!effect.!Using!this!kind!of!fuzzy!algorithm!implies!the! need!to!identify!the!specific!parameters,!rules!and!input!functions!(membership! functions!and!fuzzy!rules)!to!apply!according!to!the!problem!space!to!be!solved.!! 7.4.1 Filtering. ! This! phase! consists! in! filtering! all! received! Cresp! messages! according! to! the! requirements!specified!by!the! RN.! When! specifying!the!Creq!a!constraint!or!a! preference! defining! a! maximum,! a! minimum! or! a! range! of! possible! costs! acceptable!by!the!user!can!be!set!up.!These!filters!are!represented!by!specific! rules,!which!can!be!solved,!for!example,!by!means!of!a!Constraints!Satisfaction! Problem! (CSP)! method.! The! filtering! process! is! an! inherent! part! of! service! discovery.! However,! a! secondary! filtering! phase! is! applied! once! all! the! communication!responses!are!received!in!the!requester!side!to!validate!that!all! of!them!meet!QoS!requirements!along!the!endEtoEend!path.! 7.4.2 AM.Scoring. ! During! this! phase,! the! AM! that! implements! each! AS! is! selected! according! to! specific! scoring! functions.! It! takes! into! account! different! specific! attributes! related!to!the!AS,!for!instance!the!QoS!parameters!that!they!can!provide!and!the! priorities!of!the!RN.!For!each!AS,!a!set!of!possible!AMs!is!scored!and!the!best!one! is! selected.! In! our! preliminary! implementation,! the! AM! scoring! is! an! isolated! process! considering! each! AM! separately! regardless! AMs! interconnection! relationships.!! ! We!propose!to!use!a!generic!weighting!function!(eq.!9)!to!score!the!AMs,!where! weights! may! vary! depending! on! the! preferences! introduced! by! requesters.! Herein,!it!is!possible!to!define!tradeEoffs!between!different!parameters!such!as! the!quality!provided!by! the! network,!requirements!and! the! price! to!pay!for! a! service.! However,! scoring! functions! could! be! defined! for! each! AS! in! order! to! consider!specific!requirements!as!shown!in!section!8.1.3,!where!a!score!metric! for!audiovisual!contents!is!proposed.! ! (eq.)9)))ScoreAM))=)A)·)a)+)B)·)b)+)C)·)c)+....+)Weightn)·)paramn)=) =) 𝑊𝑒𝑖𝑔ℎ𝑡!·𝑝𝑎𝑟𝑎𝑚! ! !!!)) ) ) An!alternative!to!the!scoring!function!would!be!to!apply!the!fuzzy!logic!algorithm! for!deciding!between!specific!ASs!or!AMs.!In!this!case,!the!system!would!need!to! allow!the!parametrization!of!each!service!with!specific!membership!functions.! Then,!we!could!run!the!fuzzy!engine!like!the!one!introduced!in![GP9]!and![GP5].!
Part!III:!ServiceEOriented!and!ContextEaware!Architecture! for!the!Future!Media!Internet! ! ! ! 107! 7.4.3 AS.Composition. ! Usually,!an!operation!can!be!offered!by!several!distinct!combinations!of!ASs.!For! instance,!a!reliable!service!can!be!provided!by!means!of!acknowledgment,!error! detection!and!retransmission!functions,!or!by!applying!forward!error!correction.! Depending!on!the!combinations,!provided!QoS!may!vary.!Thus,!those!best!suited! to!satisfy!requested!priorities!will!be!chosen.! ! Figure!7.6!AS!composition!process! Note!that!the!RN!composes!the!services!per!each!node!in!the!path!(RN,!INs!and! ESN),! and! generates! the! corresponding! WFs.! Considering! the! described! architecture,!once!all!services!are!discovered!thanks!to!the!discovery!process,!RN! should!be!able!to!create!a!tree!graph!(Figure!7.6)!with!all!discovered!services!at! each!node.!Our!solution!evaluates!first!the!different!dependencies!at!each!hop!as! well!as!the!input!and!output!attributes!among!ASs,!and!concatenates!those!that! could!be!executed!within!a!node!in!order!to!satisfy!a!communication!goal.!Then,! the!best!branch!of!services!is!selected!and!the!final!CS!is!generated!for!each!node.! Our! first! implementation! of! the! service! composer! component! applies! A*! algorithm![212]!for! searching! the! best! solution! taking! into! account! the! nodes! with!best!scoring.!! ! Despite! the! A*Ebased! algorithm! was! easy! to! implement! in! a! real! prototype! (within! the! context! of! the! TARIFA! project)! and! offered! great! flexibility! for! selecting! between! many! previously! calculated! combinations! of! services! in! different! nodes,! this! algorithm! presents! some! scalability! problems! and! is! computational!complex.!In!our!tests!we!used!a!“reduced”!set!of!services,!but!in! practice,!we! can! expect! to! have! a! bigger! number! of! services! and,! also,!
!Chapter!7!Future!Internet!Flexible!Architecture! ! ! 114! ! ! Figure!7.8!a)!Adapted!multimedia!communication!use!case!and!b)!Implemented!testbed! ! 7.7 Preliminary.Results. ! The! time! required! to! establish! an! endEtoEend! communication! (TeEe)! and! the! resource!consumption!of!the!process!were!measured!in!our!testbed.!Concretely,! different! communication! requests,! asking! for! different! requirements! and! network!functionalities!were!tested.!! Table!7E5!specifies!the!highElevel!communication!goals!for!each!test.!
Part!III:!ServiceEOriented!and!ContextEaware!Architecture! for!the!Future!Media!Internet! ! ! ! 115! ! Table!7?5!Scenario!specification! Goals! Scenario! 1! (S1)! Scenario! 2! (S2)! Scenario! 3! (S3)! Scenario! 4! (S4)! data_transmission! RN! RN! RN! RN! data_forwarding! IN! IN! IN! IN! data_reception! ESN! ESN! ESN! ESN! decoding! RN! RN! RN! RN! encoding! ESN! ESN! ESN! ESN! security! E! RN,ESN! E! RN,ESN! reliability! E! E! RN,ESN! RN,ESN! ! In!practice,!these!goal!effects!are!associated!to!different!ASs!or!combinations!of! them.!Additionally,!each!AS!can!be!implemented!by!different!AMs.!As!an!example,! imagine!we!have!an!encoding!goal!which!can!be!provided!by!video_coding!and! audio_coding!ASs.!Each!AS!can!be!then!provided!by!AMs!like:!MPEGE1,!MPEGE2,! MP3,! WMA,! etc.! Regarding! performance! parameters,! the! average! total! consumption!during!the!process!of!negotiation!is!shown!in!Table!7E6.! ! Table!7?6!Nodes!resources!consumption! Node.Type. CPU. RAM. Requester.Node.(RN). 13%" 224,30"KB" Intermediate.Node.(IN). 5%" 113,46"KB" End.Service.Node.(ESN). 9%" 192,37"KB" ! The!time!required!for!negotiating!the!endEtoEend!communication!(TeEe)!in!each! scenario!is!shown!in!Figure!7.9.!Concretely,!in!this!figure!we!show!the!results! obtained!for!the!longest!path!(P4)!of!our!testbed.! ! Note! that! in! our! tests,! Tpropagation! is! almost! negligible! as! we! use! dedicated! links!in!a!local!testbed.!Tforwarding!is!also!constant!as!all!the!involved!nodes! perform!a!lookup!into!its!local!databases!of!ASs,!and!all!of!them!have!the!same! size.!Regarding!Tresponse,!it!is!slightly!different!in!the!ESN!than!in!the!IN!as!it! has!to!insert!more!data!into!the!Cresp.!In!this!case,!each!node!inserts!into!the! Cresp! information! about! the! AS,! AMs! and! QoS! parameters! that! the! node! can! offer.! ! The! gathered! results! are! preliminary! results! for! the! different! scenarios! introduced!in!Table!7E5.!The!most!representative!value!is!the!time!required!for! negotiating! the! services! that! will! be! used! (TeEe)! and! the! most! influential! parameter! is! the! composition! time! needed! to! decide! which! services! to! use! (Tcomposition).!Composition!can!be!a!very!demanding!process!if!full!flexibility! and!the!best!possible!decisions!are!to!be!achieved.!!Mostly,!its!value!depends!on! the! number! of! goals! to! successfully! target! and! the! number! of! ASs! and! AMs!
!Chapter!7!Future!Internet!Flexible!Architecture! ! ! 116! supported! by! a! node.! As! specified! in! section! 7.4,! the! proposed! composition! algorithm!must!calculate!all!the!possible!combinations!between!ASs!in!order!to! select! the! best! ones.! The! more! services,! the! more! combinations! must! be! calculated.!However,!in!future!work,!some!techniques!for!improving!this!process! will! be! studied.! Even! though,! once! a! composition! is! performed,! the! resulting! workflow!of!services!could!be!stored!for!future!reuse!so!as!to!avoid!calculating! again!all!the!combinations!of!services.! ! Finally,! note! that! in! the! presented! prototype,! monitoring! functions! are! not! implemented.!An!efficient!monitoring!system!that!provides!context!information! is!especially! important! for!the! development! of!this! solution.! In!the! future,! we! expect! to! be! able! to! implement! specific! monitoring! mechanisms! to! get! real! context!data.! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Figure!7.9!End?to?End!time!and!composition!time! ! ! ! !
Part!III:!ServiceEOriented!and!ContextEaware!Architecture! for!the!Future!Media!Internet! ! ! ! 117! Chapter.8 Future.Internet.Service.Provisioning. ! Thanks! to! the! architecture! fundamentals! introduced! in! Chapter! 7,! we! now! introduce!how!services!can!be!provided!in!the!Future!Internet!specially!focusing! in!two!main!aspects.!!The!first!one!introduces!how!SOA!paradigm!can!be!applied! to!contextEaware!multimedia!communications.!In!addition,!a!scoring!function!for! selecting!different!service!implementations!is!presented!and!particularized!for!a! case!of!selecting!transcoding!functions!taking!into!account!different!video/audio! quality!assessment!metrics.!In!this!case,!we!focus!on!specific!video!transcoding! functions,!however,!other!functions!like!the!ones!introduced!in!section!Chapter!6! could!be!added!in!order!to!create!intelligent!networks!able!to!adapt!to!context! conditions! and! specific! requirements.! The! second! aspect!is! Future! Internet! economics.! This! PhD.! Thesis!proposes!costing! framework! for! dealing! with! socioeconomic!parameters!within!Future!Internet!architectures.!In"this"context"it" is#necessary#to#introduce#a#framework#for#cost#and#price#that#enables#requesters# and$ providers$ to$ interact$ and$ create$ new$ business$ models$ for$ the$ Future$ Internet."! ! The$solutions$presented$here$were$published$in$[GP2],'[GP7]!and$[GP8].! ! 8.1 ContextRaware. Multimedia. Service. Composition. using. Quality.Assessment. !! There!are!emerging!services,!which!offer!contents!in!multiple!ways!and!different! formats.!Popularity!of!video!services!such!as!Youtube!or!Hulu,!have!made!video! traffic! in! the! Internet! the! most! present! one.! Moreover,! the! heterogeneity! of! devices!connected!to!the!network!is!also!rising!(e.g.!handheld,!PC,!TV,!etc.)!and!it! usually! requires! the! creation! or! the! adaptation! of! services! and! resources! specifically! for! each! target! platform.! This! situation! leads! to! generic! and! static! systems! that! do! not! provide! the! content! adapted! to! the! final! device! or! too! complex!systems!that!require!a!big!effort!in!development!and!maintenance!tasks.! ! In!this!scenario,!the!necessity!of!contextEaware!systems!appears.!Their!goal!is!to! offer!services!adapted!to!the!context!of!users!whilst!maximizing!the!Quality!of! Service!(QoS)!and!Quality!of!Experience!(QoE)!of!the!user!and!allowing!a!more! efficient! usage! of! resources.! However,! their! deployment! requires! precise! and! efficient!monitoring!and!data!management!systems.!One!promising!approach!to! efficiently! provide! contextEaware! services! is! using! ServiceEOriented! Architectures! (SOA),! which! divides! Services! in! simpler! ones! and! couples! only! those!that!are!required!or!preferred!for!a!specific!context.! ! Solutions!based!on!this!type!of!architectures!provide!some!clear!benefits:!loose! coupling,! implementation! neutrality,! flexible! configurability,! granularity,! task! distribution,! energy!efficiency,! efficient! use! of! resources,! etc.! The! division! of! services!could!be!done!based!on!different!aspects!such!as!location,!capabilities,!
!Chapter!8!Future!Internet!Service!Provisioning! ! ! 118! functionalities,! etc.! As! said,! in! this! work! we! follow! a! RBA! decomposition! approach! where! complex! services! are! divided! into! indivisible! or! atomic! functionalities.!Examples!of!these!functionalities!are:!encoding,!acknowledgment! or!retransmission.!Additionally,!no!matter!how!the!decomposition!is!done,!there! are! many! approaches! or! visions! of! doing! the! composition! process.! However,! there!are!some!points!to!be!taken!into!account!and!some!common!problems!that! appear!in!most!of!current!techniques:! ! • Considering! services! as! selfEcontained,! selfEdescribing,! modular! applications! that! can! be! published,! located,! and! invoked! across! the! network,!service!composition!process!can!be!defined!as!the!combination! of!those!services!required!to!create!new!processes!and!services.! ! • Fulfillment!of!preconditions!when!a!service!that!can!provide!the!desired! effects!exists![111].! ! • Generation! of! several! effects.! It! is! possible! that! a! service! request! is! associated!to!multiple!effects!that!can!be!satisfied!by!different!services.! ! • Knowledge!and!context!data!acquisition!and!management.! ! These!problems!denote!a!close!relationship!between!optimal!compositions!and! contextEawareness.!Thus,!how!to!obtain!and!analyze!the!context!is!an!important! issue,!in!order!to!provide!a!good!ground!for!the!service!composition!process.!In! this!framework,!we!review!different!methods!that!could!be!applied!to!evaluate! the! quality! of! multimedia! services! and! how! to! apply! multimedia! quality! assessment! to! enhance! a! multimedia! service! composition! process.! ContextE awareness!features!are!especially!relevant,!as!the!ubiquity!of!mobile!devices!and! the! proliferation! of! wireless! networks! is! enabling! permanent! access! to! the! Internet!at!all!times!and!all!places.!The!next!step!to!an!Internet!of!Services!is!an! Internet!of!contextEaware!Services.!!! ! According!to!the!definition!provided!by!Dey!in![104],!context!is!any!information! that!can!be!used!to!characterize!the!situation!of!an!entity,!where!an!entity!is!a! person,!place,!or!object!that!is!considered!relevant!to!the!interaction!between!a! user!and!an!application,!including!the!user!and!applications!themselves.!ContextE awareness!refers!to!the!capability!of!an!application!or!service!to!be!aware!of!its! physical!environment!or!situation!and!responding!intelligently!(proEactively!or! reactively)!based!on!such!context.!So,!it!is!important!to!compose!services!and! dynamically! adapt! them! according! to! the! context! information! and! changes! in! order! to! provide! personalized! and! customized! services! to! users.! This! should! allow!improving!the!QoS!and!QoE!of!users!while!optimizing!the!usage!of!network! and! computational! resources.! Revising! literature! related! to! contextEawareness! [215][216],!we!define!a!consensus!classification!of!the!context!according!(but!not! limited)!to!the!following:! • User! context:! user! characteristics,! user! location,! user! preferences,! and! environmental!constraints!of!the!user!(e.g.!working!place,!home,!etc.).! !
Part!III:!ServiceEOriented!and!ContextEaware!Architecture! for!the!Future!Media!Internet! ! ! ! 119! • Device!context:!type!and!capability!of!the!device.! ! • Service! context:! service! availability,! minimum! required! QoS! level! for! providing! the! service,! and! additional! parameters! that! define! specific! attributes!for!a!service.! ! • System! resource! context:! CPU,! memory,! processor,! disk,! I/O! devices,! and!storage.! ! • Network! context:! bandwidth,! traffic,! topology,! and! other! parameters! related!to!network!performance.! ! On! the! subject! of! service! composition,! several! approaches! can! be! found! in! literature! tackling! service! composition! [217][218][219][220].! For! example,! in! [219]!authors! propose! a! classification! system! in! the! form! of! taxonomy,! for! semantic!web!service!composition!approaches,!that!could!be!generalized!to!the! global! concept! of! service! composition,! and! applied! to! compose! services! at! network!level.!Unlike!other!solutions,!our!approach!uses!the!discovery!process! to!find!those!services!to!be!composed!all!along!the!endEtoEend!path!attending!to! the! requirements! specified! by! the!requester! and,! consequently,! assuring! a! certain!level!of!QoS.!Regarding!to!the!quality!assessment!process,!an!overview!on! different!metrics!and!techniques!is!presented.!Multimedia!quality!metrics!can!be! classified!into!three!groups!taking!into!account!in!which!way!a!reference!signal!is! needed!to!measure!the!quality:!! ! • Full! Reference! (FR),! which! compares! two! entire! signals,! a! reference! signal!(usually!the!original!one)!and!a!compared!signal!(usually!the!coded! one).! ! • Reduced! Reference! (RR),! which! only! compares! some! signal! characteristics! (blocking,! blurring,! ringing,! masking,! etc.)! previously! detected.! ! • Non! Reference! (NR),! which! does! not! use! any! reference! signal! to! determine!the!quality!of!a!signal.!! ! Each! of! them! is! used! depending! on! the! availability!of! an! undistorted! signal! (reference! signal).! The! most! used! metrics! are! FR! (e.g.! PSNR),! due! to! its! low! complexity,!but!as!a!drawback,!both!signals!are!needed:!the!original!signal!and! the! coded! signal.! Additionally,! methods! for! quality! assessment! can! also! be! divided!into!two!categories:!objective!and!subjective.!Objective!methods!aim!to! mathematically!estimate!the!impairment!introduced!to!media!resources!during! compression! or! transmission! whilst! the! Subjective! ones! aid! in! the! statistical! analysis!of!sample!ratings!generated!by!humans.!In!this!work!we!used!different! objective!quality!metrics!for!estimating!the!quality!of!a!received!media!resource.! For!video!we!used!Peak!SignalEtoENoise!Ratio!(PSNR)!and!Structural!Similarity! (SSIM)![221],!while!PSNR,!audio!SSIM![222]!and!Perceived!Audio!Quality!(PEAQ)!! [223]were!used!for!audio!quality!assessment.!
!Chapter!8!Future!Internet!Service!Provisioning! ! ! 120! 8.1.1 Multimedia.Quality.Assessment. AMs!need!to!be!selected!according!to!several!parameters!such!as!performance,! quality!of!service!or,!in!case!of!multimedia!applications!and!services,!parameters! such!as!the!perceptual!quality.!Quality!assessment!can!be!used!for!measuring!the! quality!of!multimedia!communications.!The!goal!is!to!select!the!best!AM!for!each! communication,! and! best! means! that! it! can! provide! the! highest! possible! perceptual! quality.! This! section! proposes! to! use! quality! metrics! for! deciding! which!is!the!best!AM!to!use!when!an!AS!of!the!type!transcoding!is!used.!This!AS! mainly! consists! on! adapting! a! content! taking! into! account! the! context! of! the! requester.! We! introduce! a! scoring! function! that! uses! the! measured! objective! quality!and!the!compression!ratio!provided!by!different!codecs.!However,!other! parameters! can! be! added,! such! as! performance! ones! (e.g.! CPU,! energy! consumption).! 8.1.2 Multimedia.Quality.Analyzer.. ! We! have! developed! a! multimedia! quality! analyzer! module! (Figure! 8.1)! that! calculates! a! score! for! each! codec! supported! by! the! multimedia! transcoding! service.!In!this!case,!each!codec!corresponds!to!an!AM,!implementations!of!the!AS! named!”transcoding”.!We!use!a!FR!system!that!can!use!the!metrics!defined!in! Table!8E1!for!determining!the!obtained!quality.! ! ! Table!8?1!Used!Full!Reference!Metrics! Media. Metrics. Image" PSNR,"SSIM" Video" PSNR,"SSIM" Audio" PSNR,"SSIM,"PEAQ" ! ! ! ! Figure!8.1!Quality!analyser!module! ! PSNR! is! an! objective! quality! metric! used! to! calculate! the! ratio! between! the! maximum!possible!power!of!a!signal!(in!this!case!an!audio!or!video!stream)!and! the!power!of!the!corrupting!noise.!It!is!commonly!used!to!calculate!the!effect!of! losses!in!a!video!or!audio!signal.!SSIM!is!a!metric!for!calculating!the!similarity!
Part!III:!ServiceEOriented!and!ContextEaware!Architecture! for!the!Future!Media!Internet! ! ! ! 121! between!two!images,!which!lies!in!the!assumption!that!human!visual!perception! is! highly! adapted! for! extracting! structural! information! from! a! scene.! Its! application! to! audio! measurement! is! still! being! studied.! Finally,! PEAQ! is! a! standardized! algorithm! for! objectively! measuring! the! perceived! audio! quality.! The!inputs!of!the!quality!analyzer!module!are:!! ! 1. a!media!resource!(image,!video!or!audio)!in!raw!format.! 2. the!same!media!resource!coded!with!a!supported!codec.! 3. the!same!media!resource!decoded!to!raw!format.!! ! (1)!and!(2)!are!used!to!evaluate!the!compression!ratio!and!to!obtain!the!file!with! losses!due!to!the!effect!of!coding.!(3)!is!used!to!compare!the!resulting!resource! with!the!original!one!in!raw!format!(input!of!the!multimedia!analyzer)!and!to! measure! the! differences! and! impairments.! In! our! system,! this! process! is! performed!offline,!when!the!system!starts!or!a!new!codec!is!added!to!the!system.! Then,!the!system!performs!all!the!analyses!and!stores!the!results!(scores)!into!a! table!which!is!looked!up!when!necessary!by!the!decisionEmaking!algorithm.! ! 8.1.3 Score.Parameter.Definition. ! The! use! of! lossy! codecs! allows! the! compression! of! the! resource! size.! But,! intrinsically,!it!also!reduces!the!user!quality!perception.!So,!it!must!be!found!a! tradeEoff!of!the!compression!ratio!and!the!perceptual!quality.!A!way!to!decide! which!codec!is!better!than!another!is!to!consider!the!perceptual!quality!and!the! compression!ratio!of!a!coded!media!resource.!Thus,!it!can!be!said!that!a!codec!is! better!than!other!if!this!presents!a!better!perceptual!quality!and!compression! ratio!relationship.!This!can!be!expressed!according!to!(eq.!11)! ! (𝑒𝑞.11)!!𝑠𝑐𝑜𝑟𝑒 =(𝐴∙𝑝𝑒𝑟𝑐𝑒𝑝𝑡𝑢𝑎𝑙_𝑞𝑢𝑎𝑙𝑖𝑡𝑦)!+((1−𝐴)∙!𝑐𝑜𝑚𝑝𝑟𝑒𝑠𝑠𝑖𝑜𝑛_𝑟𝑎𝑡𝑖𝑜)) ! Where,! 0! ≤A≤1.A! is! a! weight,! which! determines! the! relevance! of! each! parameter! considered! in! the! scoring! function.! Hence,! the! relevance! of! each! parameter!can!be!changed.!The!weight!that!specifies!an!equitable!relationship! between!perceptual!quality!and!compression!ratio!is!obtained!for!A!=!0.5.!The! score!parameter!is!defined!in!the!R!set!and!can!take!values!from!E1!to!1: 𝑠𝑐𝑜𝑟𝑒!∈!ℝ,−1≤𝑠𝑐𝑜𝑟𝑒 ≤1) ! Where!E1!and!1!indicates!respectively!the!worst!and!the!best!perceptual!quality! and!compression!ratio!relation.!The!compression!ratio!parameter!is!defined!in! the!R!set!and!it!can!also!take!values!between!E1!and!1:! 𝑐𝑜𝑚𝑝𝑟𝑒𝑠𝑠𝑖𝑜𝑛_𝑟𝑎𝑡𝑖𝑜!∈!ℝ, !−1≤𝑐𝑜𝑚𝑝𝑟𝑒𝑠𝑠𝑖𝑜𝑛_𝑟𝑎𝑡𝑖𝑜 ≤1) ! where! E1! indicate! that! there! is! no! compression! between! the! original! and! the! coded!resource,!but!there!has!been!an!increment!in!the!total!number!of!bits,!and!
!Chapter!8!Future!Internet!Service!Provisioning! ! ! 122! a!positive!value!(less!than!1)!indicates!a!reduction!of!the!total!number!of!bits.! The!compression!ratio!parameter!mathematical!expression!is!defined!in!(eq.!12).! ! (𝑒𝑞.12)!𝑐𝑜𝑚𝑝𝑟𝑒𝑠𝑠𝑖𝑜𝑛_𝑟𝑎𝑡𝑖𝑜 =! ! =𝑜𝑟𝑖𝑔𝑖𝑛𝑎𝑙_𝑟𝑒𝑠𝑜𝑢𝑟𝑐𝑒_𝑛𝑢𝑚_𝑜𝑓_𝑏𝑖𝑡𝑠 −𝑐𝑜𝑑𝑒𝑑_𝑟𝑒𝑠𝑜𝑢𝑟𝑐𝑒_𝑛𝑢𝑚_𝑜𝑓_𝑏𝑖𝑡𝑠 𝑜𝑟𝑖𝑔𝑖𝑛𝑎𝑙_𝑟𝑒𝑠𝑜𝑢𝑟𝑐𝑒_𝑛𝑢𝑚_𝑜𝑓_𝑏𝑖𝑡𝑠 ) ! The!perceptual!quality!parameter!can!take!values!between!0!and!1!and!it!is!also! defined!in!the!R!set:! 𝑞𝑢𝑎𝑙𝑖𝑡𝑦!∈!ℝ,0≤𝑠𝑐𝑜𝑟𝑒 ≤1 where!0!indicates,!in!perceptual!quality!terms!defined!by!ITUER!in![224],!very! annoying!perceptual!quality,!and!1!indicates!no!difference!between!the!original! and!coded!resource.!Some!of!the!considered!quality!metrics!do!not!take!values! between!the!defined!ranges.!So,!they!must!be!normalized.!The!quality!metrics!to! be!normalized!are:! ! 0≤𝑃𝑆𝑁𝑅 ≤∞,! ! !−4≤𝑃𝐸𝐴𝑄 ≤0! ! It!is!not!necessary!to!normalize!the!SSIM!quality!metric!as!its!output!range!fits! into!the!perceptual!quality!parameter!range.!More!details!are!shown!in![225].!! 8.1.4 Combining.Audio.and.Video.. ! The! scoring! of! audiovisual! contents! should! take! into! account! the! relationship! between! audio! and! video,! not! only! considering! their! individual! scores! in! an! independent!manner.!The!goal!is!to!avoid!bad!combinations!of!audio!and!video! profiles,! for! instance! when! obtaining! combined! profiles! with! very! good! audio! and!very!poor!video!(or!viceversa).! ! (𝑒𝑞.13)!𝑠𝑐𝑜𝑟𝑒(𝑎𝑢𝑑𝑖𝑜𝑄,𝑣𝑖𝑑𝑒𝑜𝑄)=! ! =(𝑠𝑐𝑜𝑟𝑒!"!"# +𝑠𝑐𝑜𝑟𝑒!"#$%)− 𝐴⋅𝑠𝑐𝑜𝑟𝑒!"#$% −𝐵⋅𝑠𝑐𝑜𝑟𝑒!"#$% 𝐴!+𝐵!! ! In!(eq.!13)!we!define!a!combined!score!as!the!sum!of!individual!qualities!and!the! substraction!of!each!point!(videoQ!and!audioQ)!to!the!line!defined!by!the!optimal! quality!(AxEBy=0).!A!and!B!coefficients!are!defined!by!the!R!parameter!(eq.!14).! This!parameter!can!be!introduced!by!default!(system!administrator)!or!by!the! user!as!a!preference.! (eq. 14) 𝐴=0.5∙𝐵=𝑅,𝑅∈[0,0.5] 𝐴=(1−𝑅)∙𝐵=0.5,𝑅∈0.5,1 𝑅∈[0,1]! !
Part!III:!ServiceEOriented!and!ContextEaware!Architecture! for!the!Future!Media!Internet! ! ! ! 123! Figure! 8.2! shows! how! the! quality! function! looks! like! for! an! example! value! of! R=0.66,!which!corresponds!to!a!4:3!relation!between!audio!and!video.!Thus,!we! give!a!little!bit!more!priority!to!video!than!to!audio.!However,!this!relation!can!be! tweaked!according!to!user!preferences.! ! ! ! ! ! ! ! ! ! ! ! ! Figure!8.2!Quality!function!(R=0.66=4/3)! ! 8.1.5 Proof.of.Concept. ! We!have!implemented!a!quality!assessment!tool!(Multimedia!Quality!Analyzer)! in!Java!that!is!able!to!perform!the!calculation!of!the!defined!score!parameter!in! order!to!verify!its!behavior!and!to!test!different!common!codecs!against!network! loss! effect.! The! quality! assessment! tool! is! able! to! use! PSNR,! SSIM! and! PEAQ! metrics.!The!testbed!scenario!is!composed!of!three!basic!elements:!! ! 1. Streaming!media!server.! 2. Streaming!client!where!the!media!resource!is!analyzed.! 3. Controlled!network!over!which!losses!are!introduced.! ! The!media!resource!server!acts!as!a!video!streaming!server.!It!has!been!used!the! FFMPEG!transcoding!software!(libavcodec!52.10.0)[226].!This!transcoder!allows! transcoding! multimedia! resources! with! a! wide! range! of! supported! codecs.! FFMPEG!also!supports!streaming!over!a!network!interface.!In!our!case,!we!used! UDP/RTP!to!stream!the!content!over!the!network!and!to!notice!the!loss!effect.!In! order! to! remotely! control! this! transcoder! a! webEservice! interface! which! publishes!the! transcoding! service! has! been!deployed.!The!Analyzer!Client!is!a! Java! application! that! realizes! requests! to! the! transcoding! webEservice! and! receives! the! streaming! sent! by! the! server.! Once! it! receives! the! coded! video! resource,!it!decodes!the!video!and!analyzes!its!perceptual!quality.!The!decoding! process!is!done!using!the!FFMPEG!framework!too.!It!is!mandatory!that!the!client! gets!the!original!resource!in!raw!format!to!allow!the!analyzer!module!to!perform! the! resource! analysis.! The! Controlled! Network! consists! on! a! PC! running! the! DummyNet![227]!network!emulator,!which!permits!to!emulate!networks!with!a! specific! bandwidth! and! Packet! Loss! Rate! (PLR).! The! analyzed! codecs,! configuration!and!input!resources!are!shown!in!Table!8E2,Table!8E3!and!Table! 8E4!respectively.!It!has!been!chosen!these!multimedia!resources!because!they!are!
!Chapter!8!Future!Internet!Service!Provisioning! ! ! 130! costing! framework! should! maintain! its! simplicity! in! order! to! be! feasible! and! implementable.!Thus,!being!able!to!run!in!realEtime!nodes.!! ! Regarding! to! service! composition! process,! unlike! other! solutions,! presented! approach!defines!a!preliminary!discovery!process!that!finds!those!services!to!be! composed!all!along!the!endEtoEend!path!considering!the!requirements!specified! by!the!requester!and!assuring!a!certain!level!of!QoS.! ! Furthermore,! note! that! the! composition! process! defined! is! complex! in! computational!terms.!In!order!to!avoid!the!calculation!of!the!combinations!and! scores!every!time!a!service!is!requested,!past!compositions!can!be!stored!and! reused.!Thus,!in!static!environments!only!new!or!rare!services!will!be!created.! On! the! contrary,! very! dynamic! environments! will! make! this! method! computationally!heavy!and!not!suitable!for!nodes!with!low!processing!capacities.! ! Service! composition! is! foreseen! to! be! a! key! enabler! for! creating! flexible! and! scalable! architectures! for! the! Future! Internet.! Thus,! in! this! context,! it! is! fundamental! to! create! a! suitable! cost! model! for! dealing! with! services! and! to! create!a!powerful!environment!to!develop!new!business!models.! !
!! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Part.IV: Conclusions.and.Future.Work. !
Part!IV:!Conclusions!and!Future!Work! ! ! 133! Chapter.9 Conclusions. ! This! PhD.! Thesis! reports! the! author’s! research! done! in! the! fields! of! media! streaming!and!serviceEoriented!Future!Internet!architectures,!basic!elements!to! advance!towards!a!Future!Media!Internet.!! ! Internet! is! becoming! a! huge,! heterogeneous! and! dynamic! network! that! is! growing!beyond!its! architectural! limits.! The! scaling! up! of! required! bandwidth! (mainly! motivated! by! multimedia! traffic),! the! number! of! communicating! nodes/services!and!network!technologies!(wirless,!mobile,!fixed)!are!leading!the! current!Internet!to!a!load!and!architectural!crisis!which!in!turn!makes!it!difficult! to! provide! services! efficiently! and! adapted! to! the! requirements! and! context! conditions! of! users/requesters.! Even! more,! the! endEtoEend! argument! and! layered!architecture!design!principles!of!the!current!Internet!are!no!longer!valid! to!face!this!situation.!Consequently,!the!Future!Internet!design!should!address! the!shortcomings!of!current!TCP/IPEbased!Internet!architecture.! ! Multimedia!streaming!applications!are!the!most!hungryEbandwidth!applications! and,!fundamentally,! current! Internet!traffic! is! video.!This! trend!is! expected! to! grow!in!the!future!with!the!constant!appearance!of!multimedia!capable!devices,! digital! content! creation! and! improvement! in! network! technologies.! Thus,! Internet! is! evolving! towards! a! Future! Media! Internet,! motivated! by! users! demands! asking! for! video! and! multimedia! contents! everywhere.! In! order! to! allow!Future!Media!Internet!to!provide!the!best!possible!quality!of!experience!to! users,!content! adaptation,! personalization! and! seamless! delivery! are! crucial! issues.!However,! to! achieve! this,!we! need! to! find!efficient!solutions! for! media! distribution!and!adaptation!in!high!heterogeneous!and!dynamic!environments.! Error!propagation!and!packet!loss!take!place!frequently!over!today!IP!networks,! even!more!if!considering!networks!without!infrastructure!support!like!mobile,! vehicular,!sensor!networks,!etc.!These!effects!can!considerably!reduce!the!video! quality! at! the! receiver! nodes.! According! to! this,! handling! packet! loss! and! providing!error!resilience!are!decisive!in!streaming!applications.!As!seen!in!This! PhD!Thesis!we!made!studies!and!contributions!in!challenging!environments!such! as! P2P! dynamic! networks! and! VANETs.! These! scenarios! were! excellent! to! demonstrate!the!benefits!of!the!different!robust,!scalable!and!reliable!proposed! mechanisms!(MDC,!SVC,!NC,!FEC)!for!media!delivery.! ! In!this!work!we!worked!and!validated!on!how!to!take!advantage!of!synergies! among! different! techniques! for! facing! network/device! heterogeneity! and! dynamism.! We! explored! different! streaming! systems! and! have! provided! solutions!in!necessary!areas!covering!media!distribution,!media!coding,!media! adaptation! and! media! signalling.! More! specifically,! we! covered! device! capabilities! recognition,! delivery! context! characterization,! content! adaptation,! context! acquisition! mechanisms,! content! negotiation,! and! application! layer! distribution!protocols!optimization.!Solutions!on!these!areas!allowed!improving! media! streaming! in! challenging! scenarios! such! as! the! dynamic! and! heterogeneous!peerEtoEpeer!networks!or,!even,!vehicular!adEhoc!networks.!!
!Chapter!9!Conclusions! ! ! 134! ! In!this!research!we!explored!source!coding!techniques!(mainly!MDC!and!SVC).! Understanding!them!helps!to!choose!adequate!techniques!that!will!make!able!to! optimize! resource! usage! and! to! improve! substantially! the! overall! distribution! system! quality! and! performance.! These! schemes! allow! distributing! media! resources!in!heterogeneous!networks,!where!many!different!kind!of!devices!are! connected!(from!fullEfeatured!desktop!PCs!to!a!limited!mobile!devices!such!as!a! PDA).! Every! client! connected! to! the! network! can! have! different! features! or! capabilities!(two!of!the!most!common!ones!are!available!bandwidth!depending! to!the!network!access!and!display!resolution).! ! When! applying! these! kinds! of! techniques,! the! user! experience! is! not! only! improved!in!terms!of!better!resolution!at!the!receiver.!The!user!experience!is! improved!when!talking!about!continuity!at!viewing!time!too.!Suppose!there!are! lots!of!losses!in!the!network!and!the!user!is!displaying!a!media!resource!sent!via! a! P2P! application.! At! a! given! instant,! it! can! stop! receiving! one! out! of! many! descriptors/layers!but! the! resource! can! continue! being! displayed! although! at! less! resolution! (less! quality,! but! the! reception! continues).! Once! the! network! conditions!are!restored,!and!more!descriptors!can!be!received,!the!resource!can! add!the!new!descriptors!received!in!order!to!improve!the!resolution.!This!means,! better! quality.! Note! that! MDC! and! SVC! approaches! behave! differently! in! that! situation.!MDC!offers!completely!independence!among!descriptors,!that!is,!just! one!descriptor!is!necessary!to!start!receiving!a!valid!bitstream!to!be!displayed.!In! contrast,! the! dependency! among! layers! introduced! by! SVC! adds! a! specific! constraint!that!consists!on!the!need!of!receiving!layers!in!a!specific!order,!thus,! first! it! must! be! received! the! base! layer! (minimum! required)! and,! then,! the! successive!dependent!enhancement!layers.!The!use!of!one!technique!or!another! depends!on!the!capabilities!of!the!receivers!and!the!final!application!goal!and! constraints!(e.g.!storage!capacity).! ! MDC! and! SVC! provide! very! interesting! features! such! as! scalability!and!error! resiliency.! However,! the! main! disadvantage! of! these! techniques! is! that! they! introduce!a!new!processing!stage!before!transmitting!and!this!operation!can!be! expensive! in! terms! of! processing! cost! and,! consequently,! extraEdelay! can! be! added!at!transmission!time!(there!must!be!a!tradeEoff!between!processing!cost! and!the!overall!introduced!delay).!This!can!be!a!critical!point!when!talking!about! a!live!streaming!service,!specially!when!interactivity!is!required.!Nevertheless,! the! choice! between! the! two! techniques! will! be! determined! by! the! specific! application!or!service!considered!and!according!to!specific!requirements.! ! Moreover,!in!this!work!we!also!studied!the!performance!of!flexible!MDC!systems! with!incentiveEbased!mechanisms!for!redistribution.!In!order!to!carry!out!this! evaluation,! a! testEbed! has! been! developed! to! allow! the! simulation! of! MDC! systems!and!the!use!of!incentives.!The!gathered!results!show!that!the!proposed! solution!clearly!improves!the!considered!metrics!and!the!overall!behaviour!of! the!system!compared!to!the!performance!of!the!reference!system.!These!results! can!be!used!as!reference!or!guideline!for!further!developments.!As!an!additional! outcome!of!this!work!we!have!developed!a!simulation!software!which!is!a!valid! testEbed!that!can!be!used!for!future!studies!(based!on!P2PTVSim).!In!order!to!
Part!IV:!Conclusions!and!Future!Work! ! ! 135! provide! a! more! comprehensive! validation! of! this! system! other! measurements! and!simulations! should!be!performed!to!complement!the!results!of!this!work.! More! specifically,! the! measure! of! the! overhead! introduced! by! the! use! of! MDC! should! be! considered! in! order! to! see! if! it! is! worth! deploying! these! kind! of! techniques,!and!trying!to!define!the!optimal!overhead!to!be!introduced!(tradeEoff! between!number!of!descriptors!and!overhead).!Also!PSNR!quality!measurements! could! be! performed! by! selecting! a! specific! MDC! technique! and! running! the! corresponding! simulations.! To! complete! these! results,! the! effect! of! churn,! concretely!the!impact!of!flashEcrowds,!is!desired!to!be!evaluated!in!order!to!see!if! the! proposed! solution! performs! satisfactorily! under! these! conditions.! Taking! into!account!the!obtained!results,!another!line!of!work!that!we!are!starting!is!the! use!of!MDC!for!systems!or!applications!with!low!starEup!delay!requirements!and! the!corresponding!approaches!to!it.! ! In! conclusion,! sourceEcoding! techniques! are! suitable! for! distributed! delivery! networks!that!exploit!the!benefits!of!path!and!terminal!diversity!to!face!network! loss.! Moreover,! they! are! promising! techniques! to! be! applied! with! more! revolutionary! approaches! such! as! network! coding.! As! introduced! in! this! research,! we! applied! NC! operations! implemented! above! the! MAC! layer! while! MDC!operations!are!embedded!at!the!application! layer! in! a! VANET! streaming! scenario.! Thus,! we! proposed! a! joint! sourceEnetworkEcoding! mechanism! assuming!a!crossElayer!implementation.!The!MDC!descriptions!are!adapted!with! NC!generations.!This!two!stage!coding!mechanism!increases!the!robustness!of! video! streaming! in! such! networks.! Moreover,! the! NC! redundancy! is! adjusted! using! a! fuzzy! inference! system! controller.! Then,! the! tuning! of! the! amount! of! redundancy! was! based! on! vehicular! traffic! density! and! SNR! of! the! communication!channel.!NSE2!simulations!were!successfully!carried!and!showed! significant!gains!in!terms!of!average!video!quality,!application!layer!throughput! and!average!packet!loss!rate.!The!video!streaming!with!NC!has!been!compared!to! the! proposed! joint! coding! approach! and! the! proposed! scheme! gives! better! performance.!! ! As! said,! the! proposed! system! also! used! fuzzy! logic! mechanisms! to! adapt! the! quantity!of!redundant!data!that!must!be!introduced!in!the!transmission!system! in!order!to!improve!the!network!transmission!robustness.!This!mechanism!was! also!integrated!in!an!adaptive!beaconing!rate!control!approach!called!ABR![GP5]! to! tune! the! frequency! of! beaconing! rate! in! response! to! vehicular! traffic! characteristics!(APPENDIX!V!).!This!adaptive!feature!of!the!ABR!approach!makes! it!suitable!for!rapid!arrival!and!departure!characteristics!of!vehicular!networks! (sparse! and! dense! scenarios).! Simulations! using! a! realistic! city! scenario! have! shown! that! the! ABR! approach—in! contrast! to! a! fixed! beaconing! scheme— compromises! between! beaconing! load! and! cooperative! awareness! in! different! vehicular!densities!and!emergency!ratios.!That!is,!we!also!showed!that!beaconing! load! is! reduced! on! the! cost! of! cooperative! awareness! between! vehicles,! if! channel!error!is!considered.! ! In!addition,!in!this!thesis!we!explored!other!mechanisms!to!provide!robustness! and!reliability!to!video!streaming!communications.!Specifically,!we!proposed!a! FEC!mechanisms!that!can!be!adapted!according!to!the!information!contained!in!
!Chapter!9!Conclusions! ! ! 136! the! RTCP! reports! exchanged! between! the! source! and! the! destination.! We! contributed!in!the!proposal!of!an!error!resilient!scheme!based!on!packet!level! FEC!and!packet!interleaving!technique!for!reliable!video!geocasting!over!VANET.! The!proposed!scheme!has!used!RTCP!feedback!to!optimize!FEC!redundancy!and! packet!interleaving!level!as!a!function!of!channel!variations!in!a!vehicular!traffic! condition!(packet! loss! rate! indicated! in! the! RTCP! report).! The! source! vehicle! selects!(in!the!geocast!region)!the!RTCP!report!of!the!farthest!receiver!vehicle.! This!is!because!longer!distance!yields!higher!packet!loss,!hence!lower!perceived! video!quality,!thus!selecting!RTCP!of!farthest!node!could!recover!largest!amount! of! packet! loss! of! the! nodes! in! geocast! region.! Therefore,! we! achieved! the! improvement! of! video! quality! and! protection! efficiency! whilst!respecting! transmission!constraints.!NSE2!extensive!simulations!were!successfully!carried! out!for!significant!gains!in!terms!of!average!video!quality!and!packet!recovery.! The! video! transmission! without! FEC! or! with! fixed! amount! of! FEC! has! been! compared!to!the!proposed!error!resilient!mechanism!and!the!proposed!scheme! gives!better!performance.!This!technique!can!be!used!in!combination!with!the! above!mentioned!(MDC,!SVC)!to!provide!extra!robustness!in!the!packet!delivery! process.! ! However,!our!contributions!work!mainly!at!application!level.!This!is!the!easiest! way! to! introduce! solutions! to! the! current! Internet! as! it! imposes! a! rigid! and! monolithic!layered!architecture!that!was!introduced!assuming!the!original!endE toEend!argument!where!network!intelligence!was!only!place!at!the!edges!and!the! network!role!was!focused!on!data!transport.!Another!way!of!introducing!more! efficient! solutions! is! by! complex! and! particular! crossElayer! implementations.! However!their!main!drawbacks!are!complexity!and!the!fact!that!they!cannot!be! reused.!SubElayering!is!another!possibility,!implementing!specific!functionalities! but!limiting!their!global!deployment.!Thus,!in!this!situation,!we!need!a!shift!from! a! network! following! the! endEtoEend! argument,! building! a! new! network! architecture!that!provides!more!intelligence!to!the!network!side!whilst!leaving! decisionEmaking! processes! to! the! edges.! Such! a! shift! is! required! to! combat! heterogeneity!and!to!be!able!to!create!intelligent!networks!that!can!provide!all! kind!of!services!in!an!adapted!manner!according!to!context!conditions!and!the! requirements! of! the! different! stakeholders! of! the! Future! Internet.! All! the! proposed! mechanisms! (e.g.! MDC,! SVC,! NC! and! FEC! operations),! existing! techniques! and! future!functionalities! could! be! represented! as! services! to! be! discovered!and!composed!according!to!specific!communication!and!users!goals.! This! new! flexible! and! adaptable! architecture! is! fundamental! to! achieve! real! seamless!media!provisioning!and,!hence,!to!go!forward!towards!a!Future!Media! Internet!that!meets!the!expectations!of!users!and!all!kind!of!stakeholders.! ! The! ServiceEOriented! Architecture! (SOA)! paradigm! offers! fundamental! design! principles! that! can! guide! the! Future! Internet! development! towards! a! more! flexible!and!scalable!Internet!based!on!functional!pieces!called!services!that!can! be!combined!according!to!requesters’!needs.!In!our!work,!we!propose!to!take!as! a! base! a! cleanEslate! and! serviceEoriented! architecture! (TARIFA! project)! that! focuses!on!services!combination!and!adaptation!to!context!conditions!by!means! of! three! main! processes:! service! abstraction,! service! discovery! and! service! composition.! These! processes! are! necessary! to! enable! Future! Internet! service!
Part!IV:!Conclusions!and!Future!Work! ! ! 137! provisioning! in! an! adapted! manner,! satisfying! the! specific! requirements! demanded! by! the! communication! requester! and,! additionally,! maximizing! the! QoE!and!making!an!efficient!usage!of!network!resources.!! ! To!achieve!this,!one!important!feature!of!the!proposed!solution!is!that!routing! functions! are! integrated! into! a! semantic! service! discovery! protocol! that! evaluates!context!conditions!hopEbyEhop!when!a!communication!is!requested.!In! addition! to! this,! we! also! propose! a! service! negotiation! protocol! which! would! enable!us!to!find!and!compose!services!to!meet!requesters’!requirements!in!an! efficient! manner.! This! guarantees! the! demanded! QoS! whilst! providing! appropriate!QoE!to!service!requesters.!Furthermore,!as!the!research!community! contemplates!cleanEslate!designs!for!Future!Internet!architectures,!models!and! implementations! for! assessing! its! development! viability! of! new! network! architectures!are!especially!needed.!In!this!paper,!we!provide!the!main!details!of! a!first!implementation!of!the!proposed!serviceEoriented!solution!and!discuss!the! preliminary! results! we! have! gathered.! These! results! establish! the! grounds! on! which! the! proposed! cleanEslate! architecture! will! undeniably! enable! a! more! flexible,!scalable!and!dynamic!Future!Internet.! ! New! functionalities! can! be! added! in! an! easy! and!flexible! way,! allowing! the! proliferation!of!new!applications!while!adapting!architectures!to! past,!present! and! future! requirements.! Concretely,! regarding! streaming! services,! advanced! video!coding!techniques!(e.g.!MDC,!SVC!or!MVC!for!next!3D!formats),!network! transmission! operations! (e.g.! Network! coding,! FEC! coding),! video! adaptation! (e.g.!using!quality!assessment!tools),!protocol!operations!(e.g.!publish,!subscribe,! P2P!distribution),!etc.!could!be!natively!placed!in!the!network,!and!instantiated! only!if!required,!to!enable!transparent!mediaEaware!networks!and!save!network! resources.!In! addition,! networks! will! be! able! to! adapt! according! real! data! gathered!from!the!network!(loss,!delay)!by!means!of!using!quality!assessment! tools,! decision! algorithms! such! as! the! fuzzyEbased! algorithm! proposed! in! this! thesis,!etc.!and!avoiding!implementing!more!complex!methods!at!higher!levels! (application).! ! The! architectural! concepts! introduced! in! this! research!does!not! suppose! yet! another!cleanEslate!approach.!It!presents!a!radical!view!of!the!Future!Internet,! where!the!necessary!functionalities!for!accomplishing!communications,!in!user! devices!and!in!the!network!and!at!all!levels!are!considered!as!services.!Services! are!not!fixed!but!dynamically!composed!where!and!when!necessary,!with!respect! to! user! service! requirements,! network! transfer! capabilities! and! surrounding! context!in!the!user!and!the!network!environments.!! ! Composition!of!basic!networkElevel!services!calls!for!a!cleanEslate!approach!to! the! Internet,! while! composition! of! higher! level! (transport! and! application)! services! prompts! for! an! evolutionary! approach.! Nevertheless,! composition! of! communication! services! manifests! itself! as! a! revolutionary! way! of! looking! communications! and! building! communication! systems.! Thus,! the! concepts! introduced! in! this! work! can! be! introduced! gradually! in! current! networks! and! will! allow! preparing! the! road! to! more! revolutionary! changes! at! the! network! level.!!
!Chapter!9!Conclusions! ! ! 138! ! There!are!many!algorithms!that!can!be!used!for!service!composition;!they!have! been! widely! explored! in! the! Web! Service! domain! (application! level)! to! create! complex!services!and!mashups.!However,!in!the!Future!Network!we!will!need!to! evaluate!which!is!the!most!appropriate!one!that!can!be!used!according!to!the! kind!of!services!to!be!composed!and!desired!communication.!Depending!on!the! level! where! the! service! is! (application,! transport! or! network),! different! constraints! should! be! considered.! Composing! network! services! should! be! fast! enough!to!allow!establishing!communications,!not!only!between!two!nodes!in!a! domain,!but!also!in!a!multidomain!scenario.!Thus,!delay!is!a!critical!parameter!to! take! into! consideration.! In! addition,! involved! devices! will! present! strict! processing! limitations! (routers).! On! the! contrary,! we! can! find! application! services! that! can! benefit! from! more! powerful! processing! capabilities! that! will! allow! creating! more! complex! and! flexible! compositions.! It! remains! as! future! work!to!explore!the!requirements!introduced!at!each!level.!In!so!doing,!we!will! be!able!to!find!guidelines!for!selecting!a!composition!method!or!another.!! ! In!this!PhD!Thesis!we!proposed!a!composition!method!based!on!the!combination! of!services,!and!the!A*!algorithm!for!the!final!selection.!The!final!result!is!a!set!of! combined!services!(chain!of!services)!that!will!be!used!to!establish!the!requested! communication.!Despite!the!A*Ebased!algorithm!was!easy!to!implement!in!a!real! prototype!and!offered!great!flexibility!for!selecting!between!many!precalculated! combinations! of! services! in! different! nodes,! this! algorithm! presents! some! scalability!problems!and!is!computational!complex.!An!alternative!algorithm!or,! even,!complementary!step! in! the! composition! process,! could!be! a!fuzzyEbased! algorithm!such!as!the!one!proposed,!simulated!and!evaluated!in!this!thesis!for! deciding! which! parameters! have! to! be!adjusted! in! different! environments! or! which! services,! mechanisms! or! already! calculated! compositions! to! establish! a! specific!communication.! ! The!last!part!of!this!PhD.!Thesis!introduced!two!main!innovations!clearly!beyond! current!state!of!the!art.!Firstly,!a!ServiceEOriented!framework!able!to!deal!with! (existing)! functionality! at! all! levels! (connectivity,! transport,! application)! by! considering! the! provided! service! and! not! the! technology! behind! the! functionality.!All!these!service!functionalities!can!be!seen!as!services!thanks!to! suitable! serviceEoriented! abstractions!that!allow! including!existing! functionality/protocols!as!well!as!new!functionality!in!a!flexible!way.!Secondly,! this! research!presents! a! novel! serviceEoriented! cleanEslate! architecture! generalizing!InformationECentric!Networking!(ICN)!approaches.!In!addition,!the! serviceEoriented! framework! would! be! the! first! cleanEslate! architecture! completely!aligned!with!the!work!done!within!the!ISO!WGE7!Future!Networks.! ! !
Part!IV:!Conclusions!and!Future!Work! ! ! 139! Chapter.10 Future.Work. ! Most!of!the!research!introduced!here!has!been!validated!by!means!of!simulators,! proofEofEconcept! prototypes! and! small! testbeds.! However,! it! still! remains! necessary!to!demonstrate!the!feasibility!of!the!proposed!solutions!in!larger!and! real!scenarios.!In!addition,!it!would!be!necessary!to!compare!the!performance!of! the!proposed!Future!Internet!mechanisms!with!current!Internet!developments! in!order!to!identify!the!benefits!and!required!capacity!to!move!these!proposals! forward! and! schedule! a! realistic! migration.! Obviously,! it! will! be! difficult! to! surpass!the!performance!of!current!solutions!in!a!shortEmid!period!of!time,!but! at!least,!we!are!setting!the!basic!guidelines!for!a!more!flexible!Future!Internet! able! to! grow! in! a! clean! manner! according! to! new! services!and! applications! requirements! and! users! demands.! By! now,! we! have! attracted! the! interest! of! standardization!bodies!such!as!the!ISO!(ISO/IEC!JTC1!SC6!WG7)!where!we!are! participating! in! the! design! of! the! Future! Network,! introducing! the! presented! serviceEoriented! architecture! principles! and! the! defining! service! composition! problem!statement!and!requirements.!Thus,!there!is!still!a!long!way!ahead!in!the! standardisation!of!these!issues.! !! In! order! to! advance! towards! a! Future! Internet! where! seamless! service! provisioning! will! come! true,! it! remains! necessary! to! cover! future! work! on! serviceEoriented!architectures,! service! composition! and! service! provisioning.! This!includes!addressing!different!issues!such!as:!! ! • Compare! and! evaluate! service! composition! methods! in! order! to! find! tradeoffs!between!parameters!in!order!to!achieve!efficient!mechanisms!in! different!environments,!according!to!context!parameters!and!situations.! ! o Optimal! service! composition! requires! solving! the! tradeEoff! between:!flexibility,!temporal!overhead!and!performance.!On!the! one! hand,! late! composition! (like! lateEbinding)! enables! highest! degree!of!flexibility!by!taking!into!account!more!and!more!accurate! input! data.! On! the! other! hand,! at! runEtime! service! composition! must!be!performed!in!few!milliseconds,!rarely!a!few!seconds!are! acceptable.!FN!architecture!will!solve!this!tradeEoff!by!splitting!the! service! composition! into! several! epochs! (e.g.! design! time,! deployment!time,!run!time,!etc.).!Complex!and!long!running!tasks! will!be!performed!“early”!while!simple!and,!thus,!fast!tasks!can!be! performed!“late”.!Note!that!service!composition!also!involves!the! task!of!selecting!a!service!of!the!next!lower!level.! ! • Explore!service!validation!mechanisms!to!ensure!that!the!communication! will!meet!user!expectations.! ! o The! service! composition! task! can! potentially! deal! with! a! huge! volume!of!variables!during!the!decission!process!according!to!the! required!or!desired!decisionEmaking!accuracy!and!performance.!In!