System Architecture Design

More documents

Recommendations

Info

pSHIELDSystem Architecture DesignPUillustrated in Figure 3 B. Such downward flow of information is termed as Hints in [6]. As anexample, the applications can inform the link layer about their delay requirement and the linklayer can then treat packets from the delay sensitive applications with priority [7].3) Back and forth information flow: Two layers, performing different tasks, can collaborate with eachother at run-time. Often, this manifests in an iterative loop between the two layers, withinformation flowing back-and-forth between the layers, as highlighted in Figure 3 C.Figure 3 - Different kinds of cross-layer design proposals (boxes represent the protocollayers).3.1.2.2 Existing and new CLAs3.1.2.2.1 A classic CLACross-layer design proposals that we looked at in Section 3.1.2.2 demonstrate the violation of layeredarchitectures at the protocol design phase itself. Hence, a question that naturally comes up is, “Can therebe architectures that are general enough such that protocols for wireless networks can be designedwithout violating them?” In fact, this is a complicated question. Determining what the new architecturesshould look like requires the study of not only the performance issues from a communication ornetworking viewpoint, but also an understanding of the implementation related issues. Nevertheless,some preliminary proposals have been made in the literature.These can be put into two categories:1) Allowing the layers to communicate with each other (Figure 4 A)2) A shared database across the layers (Figure 4 B)A. Allowing the layers to communicatePUD2.3.2Issue 5 Page 20 of 122
pSHIELDSystem Architecture DesignPUA straightforward way to allow information sharing between the layers is to allow them to communicatewith each other, as depicted schematically in Figure 4 A. Practically speaking this means making thevariables at one layer visible to the other layers at run-time. Notice that under strictly layeredarchitectures, every layer manages its own variables and its variables are of no concern to other layers.There are many ways in which the layers can communicate with one another. For instance, protocolheaders may be used to allow flow of information between the layers. Alternatively, the extra “inter-layer”information could be treated as internal packets. The work in [8] presents a comparative study of severalsuch proposals and goes on to present another such proposal, namely, the Cross-layer signallingshortcuts (CLASS).CLASS allows any two layers to communicate directly with one another. Similarly, the Hints andNotifications proposal discussed in [6] makes network layer the hub of inter-layer communication. Theseproposals are appealing in the case where just a few cross-layer information exchanges are to beimplemented in systems that were originally designed in conformance with the layered architectures. Inthat case, one can conceivably “punch” a few holes in the stack while still keeping it tractable. However, ingeneral, when variables and internal states from the different layers are to be shared between thedifferent layers as prescribed by such proposals, a number of implementation issues relating to managingshared memory spaces between the layers may need to be resolved.B. Shared database across the layersThe other architecture proposal recommends a common database that can be accessed by all the layers,as illustrated in Figure 4 B. See for instance references [9] and [4]. In one sense, the common database islike a new layer, providing the service of storage/retrieval of information to all the layers.The shared database approach is particularly well suited to vertical optimizations. An optimizationprogram can interface with the different layers at once through the shared database. The main issue hereis the design of the interactions between the different layers and the shared database.Figure 4 - Proposals for architectural blueprints for wireless communications.PUD2.3.2Issue 5 Page 21 of 122
Page 1 and 2: Project no: 100204pSHIELDpilot embe
Page 3 and 4: Contents1 Executive Summary .......
Page 5 and 6: FiguresFigure 1 - A generic embedde
Page 7 and 8: Figure 45 - pSHIELD Security Agent
Page 9 and 10: MGFMIPSMLNeLNFMRFPNMPNMPSNoLNVMOLOS
Page 11 and 12: Issue 5Page xi
Page 13 and 14: pSHIELDSystem Architecture DesignPU
Page 19: pSHIELDSystem Architecture Design3.
Page 31 and 32: pSHIELDSystem Architecture Design
Page 39 and 40: pSHIELDSystem Architecture Design
Page 47 and 48: pSHIELDSystem Architecture Designen
Page 71 and 72:
pSHIELDSystem Architecture DesignPU
Page 73 and 74:
Page 75:
Page 80 and 81:
Page 82:
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
Page 94 and 95:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
show all

System Architecture Design

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?