ima offloading paper

This is one contribution to:

http://localhost/wiki/doku.php?id=work_dai_labor:research:horizon_x:thesis

• Motivation
  • why offloading network (Wifi) and not 3g/lte
    • APs, hotspot popular cheap. Reduce number of private APs.
      • Available in infra and end-user-device. Use civil frequencies.
    • Timely traffic data exchange. More delay over umts???
    • Disadvantages of umts/LTE: cost? coverage?
      • uplink congestion with sensor data.
      • delay is too large for emergency data (> 100ms)
      • Broadband providers prefer offloading networks due to coverage and cost of capacity.
  • Future IoT, USA V2V regulation.
  • IMA
• Related works
  • Telematik NENA. network technologies mixing: https://github.com/denis-martin/nena/tree/master/include
  • Standard
    • TIA TR-48 Vehicular, TR-50 smart device comm
    • ETSI TC M2M
    • ITU-T USN Vehicle network, smartgrid
  • CCNx for MANET, DTN
• contribution
  • Models, Formular?
  • Can this model achieve 5G performance?
  • Is this economically applicable?
    

    * Ideas:
      * simulation
        * ns3 model
      * NENA uses userspace, large messages --> for smart devices (sensor, cars)
      * Research on real access technology agnostic
      * Integration with current IP/http based service platform

1. Understanding network models: simulation?
2. Identify problems –> todos

• hetNet primer:
  • http://en.wikipedia.org/wiki/Picocell
  • http://en.wikipedia.org/wiki/EnodeB
• Interference management is the most significant issue in HetNets.
• 3GPP defines typical HetNet deployments
• White paper, “A Comparison of LTE Advanced HetNets and Wi-Fi” , Qualcomm, 2011

WiFi APs can provide 230% performance gain in terms of DL cell average throughput

Picos (HetNets) can provide even higher gain: 920% for DL cell average throughput

Improved gain of HetNets come from well defined macro pico coordination

• Roadmap: http://cost-winemo.org/wgroups.html
• Related project / research: http://www.greenicn.org/deliverables/publications/
• http://en.wikipedia.org/wiki/Information-centric_networking
• http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg
• ICN conference: http://conferences2.sigcomm.org/acm-icn/2014/cfp.php

1. [1] http://cost-winemo.org/stsm/16-2012.pdf
2. [2]

• DTN, CCN arche, proto

• Requirements:

  • From scenarios (1)
    1. Location-based information collection based on availability in distributed heterogeneous networks.
    2. Message ferrying and data muling in vehicular networks
    3. Alarming in case of local emergencies and imminent danger
  • Results:
    • Naming scheme [1]: We therefore defined a naming scheme based on broadcast names that supports flexible discovery of available services and enables the selection of single content sources after the discovery.
    • We also discussed options to combine CCN as an overlay to the Bundle protocol to support delay-tolerant CCN [1].
    • We identified requirements to support adaptive Interest retransmission mechanisms based on current environment information or past requesting results. These requirements and other existing work on adaptive beaconing will be the starting point when designing adaptive multi-hop communication mechanisms.
    • To support intermittent communication in environments where no end-to-end connectivity can be achieved, agent-based collection protocols can be developed. The election of good agents is not an easy task and may include the detection of social structures. Also, the selection of an indefinite number of agents may enable denial-of-service attacks. We therefore defined a simplified protocol based on the CCN naming scheme and temporal contracts to support data muling in vehicular networks where node mobility and topology is limited.
    • CCN communication requires pull-based message exchanges. However, in certain situations push-based mechanisms may be beneficial to obtain user-awareness mmediately. For example, in emergency situations notification messages may be used to warn other nodes of imminent threats. Periodic Interest re-expressions require either frequent transmissions or result in long detection delays. Long-living interests are dangerous and may prevent the retransmission of Interests if new content sources become available. We therefore designed two different content notification mechanisms based on Interest and Data beacons and discussed the differences regarding the notification performance.
  Edit

  IETF ICNRG

  Survey

• ICN Scenarios: http://trac.tools.ietf.org/group/irtf/trac/attachment/wiki/IcnBaselineScenarios/draft-irtf-icnrg-scenarios-02.txt

* Dannewitz et al. [N-Scen] no eveluation
* Distributed Mobility Management (DMM) Working Group IETF
* Xylomenos et al. [PSIMob] as well as [EEMN] argue that an information-centric architecture can avoid the complexity of having to manage tunnels to maintain end-to-end  connectivity
* Lindgren [HybICN] explores this scenario further for an urban setting.  He uses simulation and reports sizable gains in terms of reduction of object retrieval times   and core network capacity use.
* The benefits from capitalizing on the broadcast nature of wireless access technologies has yet to be explored to its full potential in the ICN literature, including quantifying possible gains in terms of energy efficiency [E-CHANET].
* Obviously, ICN architectures must avoid broadcast storms.  Early work in this area considers distributed packet suppression techniques which exploit delayed transmissions and overhearing; examples can be found in [MobiA] and [CCNMANET] for ICN-based mobile ad-hoc networks (MANETs), and in [RTIND] and [CCNVANET] for vehicular scenarios.
* Metrics
  * Handover latency: defined in [RFC5568] as the "period during which the mobile node is unable to send or receive packets". This metric should be considered in ICN performance evaluation studies dealing with mobility.
  * Network overhead, such as, for instance, the amount of signaling necessary to minimize handover latency, is also a metric that should be considered when studying ICN mobility management.

To summarize, mobile networking scenarios should aim to provide 596 service continuity for those applications that require it, decrease 597 complexity and control signaling for the network infrastructure, as 598 well as increase wireless capacity utilization by taking advantage of 599 the broadcast nature of the medium. Beyond this, mobile networking 600 scenarios should form a cross-scenario platform that can highlight 601 how other scenarios can still maintain their respective performance 602 metrics during periods of high mobility.

• Jacobson et al. [CBIS]

Muscariello et al. [SHARE], for instance, presented early work on an 641 analytical framework that attempts to capture the storage/bandwidth 642 tradeoffs that ICN enables and can be used as foundation for a 643 network planning tool. In addition, Chai et al. [CL4M] explore the 644 benefits of ubiquitous caching throughout an information-centric 645 network and argue that “caching less can actually achieve more.” 646 These papers also sit alongside a variety of other studies that look 647 at various scenarios such as caching HTTP-like traffic [CCNCT] and 648 BitTorrent-like traffic [BTCACHE]. We observe that much more work is 649 needed in order to understand how to make optimal use of all 650 resources available in an information-centric network. In real-world 651 deployments, policy and commercial considerations are also likely to 652 affect the use of particular resources and more work is expected in 653 this direction as well. 654 655 In conclusion, scenarios in this category, would cover the 656 communication-computation-storage tradeoffs that an ICN deployment 657 must consider. This would exercise features relating to network 658 planning, perhaps capitalizing on user-provided resources, as well as 659 operational and economical aspects of ICN and contrast them with 660 other approaches. An obvious baseline to compare against in this 661 regard is existing federations of IP-based Content Distribution 662 Networks (CDNs), such as the ones discussed in the IETF CDNI WG.

including stored and streaming A/V distribution, file distribution, 678 mirroring and bulk transfers, versioned content services (cf. 679 Subversion-type revision control), as well as traffic aggregation. 680 681 Decentralized content dissemination with on-the-fly aggregation of 682 information sources was envisaged in [N-Scen], where information 683 objects can be dynamically assembled based on hierarchically 684 structured subcomponents. For example, a video stream could be 685 associated with different audio streams and subtitle sets, which can 686 all be obtained from different sources. Using the topology depicted 687 in Fig. 1 as an example, an application at C1 may end up obtaining, 688 say, the video content from I1, but the user-selected subtitles from 689 Px. Semantics and content negotiation, on behalf of the user, were 690 also considered, e.g., for the case of popular tunes which may be 691 available in different encoding formats. Effectively this scenario 692 has the information consumer issuing independent requests for content 693 based on information identifiers, and stitching the pieces together 694 irrespective of “where” or “how” they were obtained. 695 696 A case in point for content dissemination are vehicular ad-hoc 697 networks (VANETs), as an ICN approach may address their needs for 698 information dissemination between vehicles better than today's 699 solutions, as discussed in the following section. The critical part 700 of information dissemination in a VANET scenario revolves around 701 “where” and “when”. For instance, one may be interested in traffic 702 conditions 2 km ahead while having no interest in similar information 703 about the area around the path origin. VANET scenarios may provide 704 fertile ground for showcasing the ICN advantage with respect to 705 content dissemination especially when compared with current host- 706 centric approaches. That said, information integrity and filtering 707 are challenges that must be addressed. As mentioned above, content 708 dissemination scenarios in VANETs have a particular affinity to the 709 mobility scenarios discussed in section 2.3.

In summary, scenarios in this category aim to exercise primarily 737 scalability, cost and performance attributes of content 738 dissemination. Particularly, they should highlight the ability of an 739 ICN to scale to billions of objects, while not exceeding the cost of 740 existing content dissemination solutions (i.e., CDNs) and, ideally, 741 increasing performance. These should be shown in a holistic manner, 742 improving content dissemination for both information consumers and 743 publishers of all sizes. We expect that in particular for content 744 dissemination both extreme as well as typical scenarios can be 745 specified drawing data from current CDN deployments.

Users "on wheels" are interested in road safety, traffic efficiency,

751 and infotainment applications that can be supported through vehicle- 752 to-vehicle (V2V) and vehicle-to-infrastructure (V2I) wireless 753 communications. These applications exhibit unique features in terms 754 of traffic generation patterns, delivery requirements, spatial and 755 temporal scope, which pose great challenges to traditional networking 756 solutions. VANETs, by their nature, are characterized by challenges 757 such as fast-changing topology, intermittent connectivity, high node 758 mobility, but also by the opportunity to combine information from 759 different sources as each vehicle does not care about “who” delivers 760 the named data objects. 761 762 ICN is an attractive candidate solution for vehicular networking, as 763 it has several advantages. First, ICN fits well to the nature of 764 typical vehicular applications that are geography- and time-dependent 765 (e.g., road traveler information, accident warning, point-of-interest 766 advertisements) and usually target vehicles in a given area, 767 regardless of their identity or IP address. These applications are 768 likely to benefit from in-network and decentralized data caching and 769 replication mechanisms. Second, content caching is particularly 770 beneficial for intermittent on-the-road connectivity and can speed up 771 data retrieval through content replication in several nodes. Caching 772 can usually be implemented at relatively low cost in vehicles as the 773 energy demands of the ICN device are likely to be a negligible 774 fraction of the total vehicle energy consumption, thus allowing for 775 sophisticated processing, continuous communication and adequate 776 storage in the vehicle. Finally, ICN natively supports asynchronous 777 data exchange between end-nodes. By using (and redistributing) 778 cached named information objects, a mobile node can serve as a link 779 between disconnected areas. In short, ICN can enable communication 780 even under intermittent network connectivity, which is typical of

vehicular environments with sparse roadside infrastructure and fast 790 moving nodes. 791 792 The advantages of ICN in vehicular networks were preliminarily 793 discussed in [EWC] and [DMND], and additionally investigated in 794 [DNV2V] [RTIND] [CCNHV] [CCDIVN] [CCNVANET] [CRoWN]. For example, 795 Bai and Krishnamachari [EWC] take advantage of the localized and 796 dynamic nature of a VANET to explore how a road congestion 797 notification application can be implemented. Wang et al. [DMND] 798 consider data collection where Road-Side Units (RSUs) collect 799 information from vehicles by broadcasting NDN-like INTEREST packets. 800 The proposed architecture is evaluated using simulation in a grid 801 topology and is compared against a host-centric alternative based on 802 Mobile IP. See Fig. 3 for an indicative example of an urban VANET 803 topology. Their results indicate high efficiency for ICN even at high 804 speeds. That said, the authors point out that as this work is a 805 preliminary exploration of ICN in vehicular environments, many issues 806 remain to be evaluated, such as system scalability to large numbers 807 of vehicles and the impact of vehicles forwarding Interests and 808 relaying data for other vehicles.

As mentioned in the previous section, due to the short communication 831 duration between a vehicle and the RSU, and the typically short time 832 of sustained connectivity between vehicles, VANETs may be a good 833 showcase for the ICN advantages with respect to content 834 dissemination. Wang et al. [DNV2V], for instance, analyze the 835 advantages of hierarchical naming for vehicular traffic information 836 dissemination. Arnould et al. [CCNHV] apply ICN principles to safety 837

 information dissemination between vehicles with multiple radio

846 interfaces. In [CCDIVN], TalebiFard and Leung use network coding 847 techniques to improve content dissemination over multiple ICN paths. 848 Amadeo et al. [CCNVANET][[CRoWN] propose an application-independent 849 ICN framework for content retrieval and distribution where the role 850 of provider can be played equivalently by both vehicles and RSUs. 851 ICN forwarding is extended through path-state information carried in 852 Interest and Data packets, stored in a new data structure kept by 853 vehicular nodes, and exploited also to cope with node mobility. 854 855 Typical scenarios for testing content distribution in VANETs may be 856 highways with vehicles moving in straight lines, with or without RSUs 857 along the road, as shown in Fig. 4. With a NDN approach in mind, for 858 example, RSUs may send Interests to collect data from vehicles 859 [DMND], or vehicles may send Interests to collect data from other 860 peers [RTIND] or from RSUs [CCNVANET]. Fig. 2 applies to content 861 dissemination in VANET scenarios as well, where C0 represents a 862 vehicle which can obtain named information objects via multiple 863 wireless peers and/or RSUs (I2 and I3 in the figure). Grid 864 topologies such as the one illustrated in Fig. 3 should be considered 865 in urban scenarios with RSUs at the crossroads or co-located with 866 traffic lights as in [CRoWN]. 867 868 _/ _/ 869 |RSU| |RSU| 870

871 _ _ _ _
872 /\ /\ /\ /\
873 _ _ oo oo_ oo_ oo_ _ _ 874 _ _ _ _
875 /\ /\ /\ /_\
876 o o o o o o o o
877

878 879 Figure 4. Highway VANET topology. 880 881 To summarize, VANET scenarios aim to exercise ICN deployment from 882 various perspectives, including scalability, caching, transport, and 883 mobility issues. There is a need for further investigation in (i) 884 challenging scenarios (e.g., disconnected segments); (ii) scenarios 885 involving both consumer and provider mobility; (iii) smart caching 886 techniques which take into consideration node mobility patterns, 887 spatial and temporal relevance, content popularity, and social 888 relationships between users/vehicles; (iv) identification of new 889 applications (beyond data dissemination and traffic monitoring) that 890 could benefit from the adoption of an ICN paradigm in vehicular 891 networks (e.g., mobile cloud, social networking).

DTN community to integrate ICN 976 principles, e.g., the Bundle Protocol Query Block [BPQ] has been 977 proposed for the DTN Bundle Protocol [RFC5050]. Whilst, similarly, 978 initial steps have also been taken in the ICN community, such as 979 [SLINKY]. In fact, the SAIL project has developed a prototype 980 implementation of NetInf running over the DTN Bundle Protocol.

Within the DTN community, the 1001 majority of simulations are performed using the Opportunistic Network 1002 Environment (ONE) simulator [ONE], which is referred to in this 1003 document.

Recent concrete ICN-based contributions have 1413 been formulated for home energy management [iHEMS], geo-localized 1414 services [ACC], smart city services [IB], and traffic information 1415 dissemination in vehicular scenarios [RTIND]. Some of the proposed 1416 ICN-based solutions are implemented in real testbeds while others are 1417 evaluated through simulation.