1 / 18

Cross Layer Architectures for Tactical Ad Hoc Networks equipped with Space-Time Code Processing Capabilities

Cross Layer Architectures for Tactical Ad Hoc Networks equipped with Space-Time Code Processing Capabilities. Presented by Prof. J.J. Garcia-Luna-Aceves UC Santa Cruz PI: Srikanth V. Krishnamurthy, UC Riverside Student: Gentian Jakllari UC Riverside. Premise and Motivation.

donelle
Download Presentation

Cross Layer Architectures for Tactical Ad Hoc Networks equipped with Space-Time Code Processing Capabilities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Cross Layer Architectures for Tactical Ad Hoc Networks equipped with Space-Time Code Processing Capabilities Presented by Prof. J.J. Garcia-Luna-Aceves UC Santa Cruz PI: Srikanth V. Krishnamurthy, UC Riverside Student: Gentian Jakllari UC Riverside

  2. Premise and Motivation • Ad Hoc Networks with omni-directional antenna capabilities are limited in capacity • Sophisticated antenna equipment -- space-time encoding and decoding capabilities becoming the reality. • Antennas are becoming smaller. • New challenge is in developing suitable network architectures to exploit the presence of these capabilities. • Layered approach fails to effectively exploit these capabilities : Need for layers to work together -- a cross layered approach.

  3. Architectural Outlook Discover and Maintain Appropriate Routes; Feedback To Lower Layers on Topology Construction Network Layer Support Scheduling based On Interference Zones and Generated Traffic MAC Layer Physical Layer Adaptive Antennas Provide Feedback To Higher Layers On Interference Zones/ Tune In Response to Needs

  4. Outline • Objectives • Discussion of Approach • MAC Layer Design • Preliminary Simulations and Results • Routing Interactions and Higher Layer Dependencies • Future Plans.

  5. Objectives • Design and development of a cross-layer architecture towards exploiting the physical capabilities • Adapt to changes in traffic conditions • Adapt to mobility • Adapt to changes in network topology

  6. Approach • MAC Layer to support searching for neighbors, maintaining connectivity in scenarios of mobility and flexibility to smart scheduling approaches. • Multi-path routing strategy to provide reliability via redundancy -- tightly intercoupled with the MAC layer. • Interactions with transport layer (or applications) to provide adaptability to changes in traffic patterns/requirements.

  7. The MAC Layer • Full exploitation of directed (weighted) transmissions • Many of the solutions at the MAC layer for use with directional antennas still rely on omni-directional reception of RTS/CTS messages. • Need to direct antennas correctly • The communicating pair must be aware of where and when and with what weighting co-efficients to point their antennas correctly in order that they can successfully exchange information. • Neighbor Discovery • Each node should be aware of the location of its neighbors, and the channel conditions on the link to each neighbor -- a difficult challenge in conditions of mobility.

  8. Design Approach at MAC layer • Divide Time into three phases • Searching -- Allow for the routing protocol to search for new neighbors • Polling -- Periodically re-establish contact with known neighbors to refresh channel weights and to possibly schedule data transfers • Data Transfer --Exchange actual data with neighbors

  9. The Basic Timing Diagram Search Segment Data Poll 1 2 A B 1 2 Pilot tone Sub-slots to facilitate handshakes during search Includes PSON / RPSON control messages to indicate use/non-use of the particular polling slot.

  10. Advantages of our Scheme • Obviates the need for omni-directional transmissions. • Proactive maintenance of neighborhood information (polling) makes it robust to mobility. • Provision of pilot tones prior to data access allows refinement of channel weights. • Scheduled access considerably reduces the possibility of collisions. • Provides an interface with the routing layer (searching for and maintaining neighbors).

  11. Preliminary Simulations and Results • Assume directional antennas • Use OPNET simulator • For now: We call our MAC : PMAC for polling based MAC. • Compare with prior scheme using Circular RTS messages [Korakis et al : Mobihoc 2003] and IEEE 802.11 standard. • With the Circular RTS, if a node’s position is unknown, the RTS message transmitted directionally and sequentially in all directions to try and reach the neighbor.

  12. Simulation Parameters

  13. Simulation Results: Grid Topology • 16 nodes and No mobility • Under heavy load CRTS suffers from collisions due to asymmetry in gain due to omni-directional transmission of CTS messages. • In PMAC all the transmission are directional. Thus, the gain is always symmetric and this leads to a significant increase in network throughput -- collisions are especially reduced at high loads.

  14. Simulation Results: Random Topology • 15 nodes: Nodes move with a speed of 10 m/s. • Both protocols offer significant improvement over 802.11 • CRTS requires a high control overhead per data packet sent (circular transmissions) while it is much smaller for PMAC. • CRTS requires a overhead proportional to the number of elements of the antenna array while for PMAC it is constant. • Thus, one would expect that the benefits with PMAC would increase with narrower beamwidths -- also applicable with adaptive antenna arrays.

  15. Topology Control • Polling each and every neighbor is expensive -- too many polling slots. • Whom to poll ? -- Traffic pattern dependent. • Input from higher layers. • Connectivity also depends on routing -- if a route is via a neighbor, link to the neighbor to be maintained.

  16. Routing : Enforcing Parallelism • Our objective is to integrate the MAC protocol with a multipath routing protocol. • Compute maximally disjoint paths to provide for parallel streaming if possible. • Can reduce delays (improve quality of service) during congested periods -- allows for bypassing congested areas.

  17. Interactions with MAC layer • Tuning the topology based on routing decisions. • In times of partitions include an aggressive search phase to look for new neighbors or paths to excluded partitions. • Choose paths (and therefore links that ought to be maintained) based on the optimization of desired metrics of interest -- energy efficiency, sustained data rate etc.

  18. Future Plans • Inclusion of appropriate physical layer models into simulation framework. • Include adaptive antennas (space-time processors into framework). • Provide a unified framework with MAC/routing/transport layers. • Investigate the interactions between layers and tune design choices. • And of course, work with other team members towards ensuring the success of this project !

More Related