A System for Modeling Architecture for Resource Constraint Devices and Methods Thereof
BACKGROUND
The invention relates generally to resource constraint devices, and more particularly, to modeling architecture for resource constraint devices.
Sensor networks are a class of wireless networks whose primary motive is environment sensing. They could consist of nodes with sensing and communication devices embedded in them. On the hardware side, these nodes could be small devices are comparable to a quarter. They can form the basis for many "smart" environments, like hospitals, conference rooms, smart homes or battlefields. Primary operation in wireless sensor networks (WSNs) could be sensing the environment and reporting the same, to a base station or relaying information for other nodes. Mobile Ad hoc Networks or MANETs are a class of networks which are infrastructure less in nature, and require no pre-deployed set up to communicate. These are self collaborative in nature, and can automatically set up a network and discover routes to a destination on the fly. These use intermediate nodes to route data to a destination not directly reachable. Or in other words, they use multiple short hops rather than a single hop from source to destination. This aspect particularly makes them a natural choice as a networking component for WSNs, since it wiser to use multiple short hops as it conserves energy for the source node and dissipates small amounts evenly at the intermediate nodes.
The basic communication process consists of sending data from source to destination. Primarily, it is the case of two applications wanting to communicate with each other. Hence, application at source generates information, which is encoded and transmitted to destination, and the destination application decodes the same. This entire process is logically partitioned into a definite sequence of events or actions, and individual entities then form "layers" of a communication "stack". Traditionally, the process of communication was formally organized as the ISO-OSI reference model stack. This stack consists of seven layers, Application to Physical.

While a pervasive computing set-up requires many individual components, ad hoc networks fit the bill perfectly for the networking support required. Challenges to system design in MANETs are: (i) accounting for their inherent dynamism, (ii) bandwidth and interference, and (iii) energy and network lifetime.
Furthermore, the Internet architecture and its component protocols are admirably suited to their purpose, and have witnessed immense popularity and growth in usage population for the past three decades. However, its very success and stability tends to inspire almost all of networking research, where most of research is an attempt to migrate the same successful Internet design while patching up parts to fit the new scenario. This mode of operation only proves disastrous, if not worse, especially in scenarios like WSNs where requirements are completely different.
In addition to this, the individual modules designed for WSNs are often validated over a set of workloads that are at least thought to be representative of the entire application gamut of WSNs. This is not a very valid assumption, since the application types and their requirements are varied. Applications range from point- to point (P2P) to broadcast to anycast. Some applications demand reliable communication while others do not, and some have real time constraints (like low latency) while others do not. Hence, it is not very appropriate to assume that a given module performing over a particular workload or tuned to do well for one application may be generally applied everywhere. On the other hand, it is almost impossible to come up with a module that handles all of the application types successfully.
Accordingly, there is a need for a technique that to identify aspects that a successful stack must posses, and advocate their inclusion in future designs rather than protocol migration from the Internet (referred hereinafter "stack aware architecture"). In addition to this, the Internet design needs to be validated for "stack aware" properties. Furthermore, taxonomy of application types needs to be designed for WSNs and list functions that each application type demands. Also, there needs to be a design of a basic blueprint of a dynamic stack that maps requirements for an application to available modules on a per packet basis based on preamble processing of the stack.

BRIEF DESCRIPTION
In one embodiment of the present technique, a communication system in a wireless sensor network adapted to provide a communication link between a plurality of nodes is disclosed. The system includes a protocol stack encapsulating a plurality of fundamental network protocol layers that correspond to an open system interconnection (OSI) model, wherein each of the layers comprises a plurality of modules. The system further includes a preamble module adapted for defining a set of requirements for at least one application. Further, the system includes a communication module adapted for communicating data between the plurality of nodes by selecting one or more modules from at least one of the layer of the stack to form an optimal combination of modules indicative of the preamble module defined, wherein the optimal combination is based on quality of service (QoS) desired by the at least one application.
In another embodiment of the present technique, a method in a wireless sensor network adapted to provide a communication link between a plurality of nodes comprising a protocol stack encapsulating a plurality of fundamental network protocol layers that correspond to an open system interconnection (OSI) model, wherein each of the layers comprises a plurality of modules is disclosed. The method includes defining a set of requirements for at least one application using a preamble module. The method further includes communicating data between the plurality of nodes by selecting one or more modules from at least one of the layer of the stack to form an optimal combination of modules indicative of the preamble module defined, wherein the optimal combination is based on quality of service (QoS) desired by the at least one application using a communication module. It should be noted that the selection of the one or more modules from the at least one layer is based on the selected modules in preceding layers and available modules in succeeding layers.
DRAWINGS
These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with

reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
FIG. 1A is a schematic representation of Internet architecture of the ISO/OSI Network Model, in one embodiment of the present technique;
FIG. IB is a tabular column depicting the possible layers of a stack for wireless sensor networks, in one embodiment of the present technique;
FIG. 2 is a block diagram of a communication system in a wireless sensor network adapted to provide a communication link between a plurality of nodes, in one embodiment of the present technique;
FIG. 3 depicts bits of a byte preamble for wireless sensor networks, in one embodiment of the present technique;
FIG. 4 depicts an exemplary path of a packet from application layer to physical layer, in one embodiment of the present technique; and
FIG. 5 is a flowchart depicting a method in a wireless sensor network adapted to provide a communication link between a plurality of nodes, in one embodiment of the
present technique.
DETAILED DESCRIPTION
The following description is full and informative description of the best method and system presently contemplated for carrying out the present invention which is known to the inventors at the time of filing the patent application. Of course, many modifications and adaptations will be apparent to those skilled in the relevant arts in view of the following description in view of the accompanying drawings and the appended claims. While the system and method described herein are provided with a certain degree of specificity, the present technique may be implemented with either greater or lesser specificity, depending on the needs of the user. Further, some of the features of the present technique may be used to advantage without the corresponding use of other features described in the following paragraphs. As such, the present

description should be considered as merely illustrative of the principles of the present technique and not in limitation thereof, since the present technique is defined solely by the claims.
As a preliminary matter, the definition of the term "or" for the purpose of the following discussion and the appended claims is intended to be an inclusive "or" That is, the term "or" is not intended to differentiate between two mutually exclusive alternatives. Rather, the term "or" when employed as a conjunction between two elements is defined as including one element by itself, the other element itself, and combinations and permutations of the elements. For example, a discussion or recitation employing the terminology "A" or "B" includes: "A" by itself, "B" by itself and any combination thereof, such as "AB" and/or "BA." It is worth noting that the present discussion relates to exemplary embodiments, and the appended claims should not be limited to the embodiments discussed herein.
The present invention relates to resource constraint devices, and more particularly to dynamic and adaptive stack for wireless sensor networks.
As will be appreciated by people skilled in the art, to best understand the present invention it is important to be familiar with the environment in which it is used.
As discussed earlier, the basic process of communication was formally organized as the ISO-OSI (International Standard Organization - Open System Interconnection) reference model stack. This stack consists of seven layers, namely, Application, Presentation, Session, Transport, Network, Ethernet and Physical. Each of the layers will be described in greater detail in the subsequent sections to follow. However, some of the critical elements of the stack will be explained in the following section.
Transmission Control Protocol (TCP) is a transport layer protocol used by an application in one host to communicate with an application in another host. This is accomplished by services provided by the protocol layers beneath the transport layer in both hosts. As a connection-oriented protocol TCP requires the establishment of a connection between the two hosts before two applications are able to communicate. TCP manages the connection and once both applications have communicated all

required information between themselves, the connection is released as if the connection is two simplex connections as opposed to a single duplex connection. The information may be transferred between applications on different hosts is a byte stream. The transport layer hides message transfer details such as segmentation, ordering and duplication from the applications and provides end-to-end acknowledgement.
The Internet Protocol (IP) layer provides certain services to the transport layer protocol including hiding the details of the physical and data link layers and the services provided by them from the transport layer protocol. The IP layer provides a datagram delivery service. A datagram is a unit of data less than an entire message. A message may be, for example, a file, which may be quite large. Since there is a maximum size for a message (or file), the message may have to be segmented and transferred in smaller units. These smaller units are thus called datagrams. Each datagram is sent over the network as a separate entity and may, in fact, follow separate paths to the destination host. At the destination host, the datagrams are reassembled in proper order (usually in a buffer area) by the transport layer. Each node on the network sends any datagrams on to a next node only considering the final destination and only acknowledges receipt of the datagram to the preceding node. That is, the IP layer does not provide end-to-end acknowledgement. End-to-end acknowledgement is a service of the transport layer protocol. Should any node-to-node acknowledgements not be received by the preceding node, the datagram or datagrams unacknowledged will be retransmitted. The transport layer in the destination host will also acknowledge any duplicated datagrams (else receipt of duplicate datagrams will continue resulting in a clogged network) and ignore them.
Routing between network nodes is accomplished by means of routing tables. These routing tables can be static or dynamic and result in datagrams being forwarded from a source host to a destination host one node at a time. The intermediate nodes are
often called "hops."
The acronym, TCP/IP, is also used to refer to a five layer protocol model similar to the ISO/OSI seven layer protocol models. The TCP/IP model does not have the

equivalent to layers 5 and 6 of the ISO/OSI protocol model. A protocol model defines the protocol layers and the interfaces between the layers. When implemented in software, hardware or firmware or possibly field programmable gate arrays (FPGAs), the implementation provides the actual services. This layered approach allows for ease of upgrading so long as the interface to the layer immediately above or below is not altered. Layering also allows for complete substitution. For example, should a new physical medium become available then so long as the interface between layer two and layer one remain the same, an old physical layer implementation module can be removed and a new implementation module substituted. In the alternative, the new implementation module could be added as another option. That is, the protocol suite defines the rules and the implementation provides the services that allow the communications to take place between applications on different hosts. The implementation of the TCP layer provides for the application to require a certain Quality of Service (QOS) as specified by a set of parameters including but not limited to priority, transmission delay, throughput etc.
Another well-known transport layer protocol is known as User Datagram Protocol (UDP), which is a connectionless transport protocol. The basic data transfer unit is the datagram. A datagram is divided into header and data areas as it is for the IP layer. An additional header over and above the IP header is used. The UDP header contains source and destination addresses (ports), a UDP length field (the length includes the 8 byte header and the data) and a UDP checksum. The UDP data includes the IP header and data. The IP layer supports UDP as a connectionless transport protocol for use in transmitting, for example, one time request-reply type messages or applications where time is of greater importance than accuracy.
TCP is used by applications on different hosts to communicate over a assumed unreliable network. To accomplish such communication much is added to the protocol in order to ensure that the information transferred over the network is valid. This addition has a cost and that cost is increased overhead with the attendant increase in bandwidth. A UDP header is eight bytes, the TCP header is 24 bytes and an IP header is a minimum of 20 bytes. Therefore, UDP/IP headers are a minimum of 28 bytes and TCP/IP headers are a minimum of 44 bytes. This is fairly large in terms of

overhead and bandwidth utilization particularly over wireless networks. There are other significant problems with using standard TCP/IP over wireless networks principally in the area of flow control. The UDP/IP protocol combination, while not offering any guarantees to users, is expected to be reliable. Wireless networks tend, however, by their nature to be lossy. Several solutions have been proposed when the network is not homogeneous. That is, when the network has both wireless and wire line portions. One suggestion is to use indirect TCP and another is to use snooping.
Other protocols such as Serial Line IP (SLIP) and Point to Point Protocol (PPP) have been developed. SLIP is not a standard and both are for point to point connections only so are not available for uses in networks. CDPD vendors indicate that they provide an integrated TCP/IP stack but it is not known the cost in terms of bandwidth
overhead.
Quality of Service in the present context refers from the standpoint of an application. An application may be defined as a program at a host that wants to use services offered by another remote application or pass a message or information to another remote application. This application, which will make use of a communication stack will have certain requirements from the stack that defines the most optimum way of exchanging information with another remote application. It would be based on the following axes:
Reliability
Real Time constraints
Other metrics that help the stack decide the best way to fragment and send datagram (including estimate of a strong link and load balancing) from an application would be
based on the following:
The type of data it carries (normal data, critical control information,
streaming bytes etc)
The application type (broadcast, anycast, multicast or point-to-point)

Under such conditions, writing protocols that make the most efficient use of the available resources is of major importance.
Referring now to drawings, FIG. 1A is a schematic representation of Internet architecture 10 of the ISO/OSI Network Model, in one embodiment of the present technique. The standard model for networking protocols and distributed applications is the International Standard Organization's Open System Interconnect (ISO/OSI) model. As illustrated earlier, it defines seven network layers. Each of the seven layers will be explained in greater detail in the subsequent sections to follow.
The first layer is the Physical layer 12, which defines the cable or physical medium itself, e.g., thinnet, thicknet, unshielded twisted pairs (UTP). All media are functionally equivalent. The main difference is in convenience and cost of installation and maintenance. Converters from one media to another operate at this level.
The second layer is the Data Link layer 14, which defines the format of data on the network. A network data frame, aka packet, includes checksum, source and destination address, and data. The largest packet that can be sent through a data link layer defines the Maximum Transmission Unit (MTU). The data link layer handles the physical and logical connections to the packet's destination, using a network interface. A host connected to an Ethernet would have an Ethernet interface to handle connections to the outside world, and a loopback interface to send packets to itself.
Ethernet addresses a host using a unique, 48-bit address called its Ethernet address or Media Access Control (MAC) address. MAC addresses are usually represented as six colon-separated pairs of hex digits, e.g., 8:0:20:11: ac: 85. This number is unique and is associated with a particular Ethernet device. Hosts with multiple network interfaces should use the same MAC address on each. The data link layer's protocol-specific header specifies the MAC address of the packet's source and destination. When a packet is sent to all hosts (broadcast), a special MAC address is used.
The third layer is the Network layer 16. The network layer uses Internetwork
Protocol (IP) as its network layer interface. IP is responsible for routing, directing
datagrams from one network to another. The network layer may have to break large

datagrams, larger than MTU, into smaller packets and host receiving the packet will have to reassemble the fragmented datagram. The Internetwork Protocol identifies each host with a 32-bit IP address. IP addresses are written as four dot-separated decimal numbers between 0 and 255, e.g., 129.79.16.40. The leading 1-3 bytes of the IP identify the network and the remaining byte identifies the host on that network. For large sites, usually subnetted like ours, the first two bytes represents the network portion of the IP, and the third and fourth bytes identify the subnet and host respectively.
Even though IP packets are addressed using IP addresses, hardware addresses must be used to actually transport data from one host to another. The Address Resolution Protocol (ARP) is used to map the IP address to it hardware address.
The fourth layer is the Transport layer 18, which has been explained earlier too. The transport layer subdivides user-buffer into network-buffer sized datagrams and enforces desired transmission control. Two transport protocols, Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), sits at the transport layer. Reliability and speed are the primary difference between these two protocols. TCP establishes connections between two hosts on the network through 'sockets1 which are determined by the IP address and port number. TCP keeps track of the packet delivery order and the packets that must be resent. Maintaining this information for each connection makes TCP a stateful protocol. UDP on the other hand provides a low overhead transmission service, but with less error checking. NFS is built on top of UDP because of its speed and statelessness. Statelessness simplifies the crash recovery.
As illustrated, the stack includes the fifth layer of Session layer 20, which defines the format of the data sent over the connections. The NFS uses the Remote Procedure Call (RPC) for its session protocol. RPC may be built on either TCP or UDP. Login sessions use TCP whereas NFS and broadcast use UDP.
The sixth layer is the Presentation layer 22, wherein External Data Representation (XDR) sits at layer. It converts local representation of data to its canonical form and

vice versa. The canonical uses a standard byte ordering and structure packing convention, independent of the host.
The last layer is the Application layer 24, which provides network services to the end-users. Mail, ftp, telnet, DNS, NIS, NFS are examples of network applications.
As will be appreciated by a person skilled in the art, although the OSI model is widely used and often cited as the standard, TCP/IP protocol has been used by most Unix workstation vendors. TCP/IP is designed around a simple four-layer scheme. It does omit some features found under the OSI model. Also it combines the features of some adjacent OSI layers and splits other layers apart. The four network layers defined by TCP/IP model are as follows.
Layer 1 - Link. This layer defines the network hardware and device drivers. The layer 2- network layer is used for basic communication, addressing and routing. TCP/IP uses IP and ICMP protocols at the network layer 16. The layer 3- transport layer handles communication among programs on a network. TCP and UDP fall within this layer. In the layer 4 - application layer, the end-user applications reside at this layer. Commonly used applications include NFS, DNS, arp, rlogin, talk, ftp, ntp and traceroute.
FIG. IB is a tabular column depicting the possible layers of a stack 26 for wireless sensor networks, in one embodiment of the present technique. The figure shows possible layers and corresponding possible modules that can be present at such layers.
Application 24 can be of monitoring types (where nodes report phenomena to a monitoring terminal) or communication 25 (where some control information is exchanged between motes/terminal).
TCP and UDP 30 form possible Transport layer modules. TCP provides reliable in order delivery, with complete congestion and flow control. It requires a session to be set-up between end nodes before communication can begin, and is a bulky implementation. It could be recommended for data that requires high reliability and in-order delivery.

UDP provides unreliable delivery, no congestion or flow control. It is, however, fast and simple to implement. Real time data would find such a protocol ideal.
Network layer 16 could have IP 32 based routing and addressing (ideal for point2point connections), or could prefer location based or geography based routing and addressing strategies (as in protocols such as SPEED, Geographic Forwarding or GF, Implicit Geographic Forwarding or IGF).
Medium Access 34 has metrics like high goodput (ratio of sent packets to attempt to send), low energy consumption and light implimentations. Possible modules are B-MAC 36 and S-MAC 36. Much debate has happened on the pros and cons for these two modules. B-Mac is proven to consume lesser memory and energy, but the results for both are comparable. Both protocols, however, are more suited as compared to IEEE 802.11 PSM (power saving mode).
Energy Efficiency modules 40 available are SPAN 42, which are more suited for ad hoc networks. SPAN 42 reports network lifetime 20 times greater than without it. IEEE 802.11 might be more suited for operability for most 802.11 enabled campuses.
The stack consists of layers, and layers consist of component modules. Modules are compiled code programs that take a datagram appropriate as an input for that layer and output an encapsulated datagram that is appropriate as an output for that layer. Many modules can be present as an option at any layer. Modules typically export an API which is called at the service access points (the junctions between two layers).
However, there is couple of issues with the conventional layers. There is a very high degree of harmony among the layers in the stack. As stated, TCP accounts for reliable in-order data flow. TCP is connection oriented while its layer beneath (IP) is connectionless. This aspect of IP gives the stack 26 the goodness of connection oriented and connectionless approaches. Packets using IP are routed independently, and this takes care of load balancing and growing congestion in the network. The IP Datagram is fundamental to the Internet Protocol. A datagram has enough information in it to carry it from source to destination; there is no advance set-up required within the network to do this. The network makes a best effort to send the packet across, best

effort meaning that if something goes wrong, the network does nothing, it tried its best. This form of unreliable service is the most basic building block of the Internet. A note may be made on the highly cited ability of IP to "run over anything". Most of the technologies over which IP runs today did not exist when IP was invented, and no protocol has proved to be too bizarre for IP; it has even been claimed that IP can run over a network that consists of two tin cans and a string. IP also provisions packet fragmentation when gateway routers have packet size restrictions. TCP is end to end, and hence takes care of most of end system processing. IP is hop-by-hop, and hence takes care of hop to hop packet processing. Functions provided in either protocol do not interfere or overlap with each other. In others words, the stack are so designed that every layer is as if designed for the other layers present.
Moreover, the stack 26 as it stands today has evolved with time and experience. As the size of the Internet grew, newer problems (like congestion, WAN routing, minor problems with previous modules etc.) started emerging.
In addition to these, there are some other issues too. These may be summarized as below:
Reliability: Some applications, like habitat monitoring, require reliability. It is wise to allow link-layer acknowledgement to provision for reliable communication.
Gray Areas: Gray areas have an effect on MAC as well. Using link strength estimation is hence a key to success here as well.
Adaptable functions: Most of MAC research is highly tuned for one particular application, and the module is often validated with that one class. Studies have shown the diversity in application types: traffic patterns are erratic with low and high workloads, and generic MAC protocols are sensitive to this. An interesting case is that of B-MAC that uses a small core channel access function and allows applications to a certain degree a level of freedom to use specific functions.
Preamble sampling: When nodes send out data (typically broadcast), nodes in the receiving range would have to sample through the preamble to determine the course

of their action with it. This has been an active area of pursuit, with researchers arguing for long or short preambles.
Switching States: Switching between sleep to awake is a crucial phase, and care must be taken to not produce excessive control messages. Most protocols broadcast a variety of control messages to notify neighbors of their transitions.
Uniform Energy Dissipation: Network lifetime is the primary target for energy conservation techniques. This means no single node must end up dissipating too much energy in seclusion, and when possible, neighboring nodes should cyclically take up the load to ensure a uniform (at least an "almost" uniform) energy dissipation model. As is obvious, this part is easier stated than achieved.
Apart from the aforesaid issues in transport, network, medium access, application and energy efficiency, there are issues that are generally applicable to WSNs in general, like:
Wireless Medium: Wireless mode of data transport brings in its own flavors of problems, like lossy links, high biterror rates, issues of security (medium is broadcast).
Creating robust and reliable systems: it is envisioned that WSNs in future will be used for small devices, which may be conveniently embedded in environments, or even thrown about here and there. These nodes would form a network, and sustain themselves. With diminishing hardware costs, one can even imagine them to cost lesser than a standard battery. In the sense, one can throw away a mote rather than recharge its battery. Hence, these motes would hardly be attended to. This brings reliable and sustained operations into focus.
Security, Confidentiality and Authentication: These issues are persistent in all of networking. The issue here is constrained processing and memory, which might affect complex implementations.
Micro nature of stack: Environment monitoring is a prime application. Nodes in WSNs are constrained for processing and memory, and the internetworking problem

is nowhere close to the complexity of the Internet. At a bare minimum, it is sufficient to be able to form connected graphs with strong links with neighboring nodes. Further, nodes receiving packets for forwarding must do this "on-the-fly". The concept of "store-process-forward" is not recommended because: memory and processor are in demand, and some applications are sensitive to this additionally induced latency.
Scalability: Needless to say, the network should be capable of scaling to a large number.
Therefore, to cope with the above problems, and also acknowledging memory, processor and energy limitations, a dynamic stack is proposed. The architecture would consist of a series of micro functions pre-compiled. Using guidelines of "stack aware" architectures, attention is paid to application demands first.
The following four guidelines is indicated for calling a stack architecture "stack aware":
1) Application Demands: Application driven research has been the foundation of excellent science contributions from the Computer Science community. Computer communication is really about two applications talking to each other. Hence, protocols are merely there to facilitate this, i.e., protocols and modules are primarily designed with the application requirements as the central theme.
2) Adaptable and room for modification: Change is inevitable, most certainly so in computer networks. If a protocol works in a particular environment, research will
push it further to try performing it in newer environments. As our requirements change, one will evolve continuously. Room for modification is hence a positive thing. While optimizing design to suit the environment is a good thing, it should not be hopelessly rooted to that environment alone. A basic property of any stack is its modular (and replaceable) design. At any point of time, one should have the space to reconsider our design, and/or add/replace modules as per our needs.

3) Layers leverage benefits of using one another: The crux of the concept: layers should be so designed that they appear to be "designed for each other". Lower layers should be aware of the predominant nature of applications using them. Functions in layers should ideally not overlap, and more importantly not interfere. Layers should be aware of what other layers expect from them, and the environment in which they operate (like wireless networks, optical fibre etc.).
4) Implementation Experience: Implementation is perhaps the biggest eye opener. Once implemented, the exercise gives a very precise picture of our standing and reveals caveats in the design. In other words, good stack architectures are not purely a theoretical exercise. The stack is to be designed with the application demands and the medium constraints in mind.
With respect to the protocol, it should be noted that the protocol should be stateless. It does not maintain the states of nodes outside its transmission range. This boils down to a list of neighbors only, with an added metric of link estimation. The beacons used could facilitate this. Beacons additionally can provide estimations of congestion at that node also. When a packet is to be sent, nodes use geography information rather than IP addresses.
As indicated earlier, with regard to energy efficiency, there are many modules available for energy efficiency. SPAN and GAF 42 notably are for ad hoc networks, and MAC has the popular 802.11 DCF in power saving mode (PSM) and more recently SMAC, B-MAC and IGF specifically for WSNs. SPAN and GAF use a lot of control messages, especially when making transitions from sleep to awake and vice versa (IGF scores over these on these grounds). Grid sizes in GAF are static and nodes require geography information. SPAN uses a variety of control messages. IGF uses both geography information and has lesser number of control messages. With a metric of conserving bandwidth and energy, IGF would make a better choice. SMAC implementations are a lot more bulky than B-MAC, and SMAC deals with lot of synchronization which makes it a little complex. BMAC is an interesting architecture, since it allows nodes freedom to select use of acknowledgement and in its core uses a small and easy to implement channel access method. Also note that

acknowledgements, if used, should be provided at the Link Layer. This has a specific advantage: it allows for link-layer re-transmissions (when necessary) which does not bother higher layers.
In order to minimize the issues with the conventional stack 26, a preamble is added to the application payload. The bits in this byte are purported to precisely describe application demands.
FIG. 2 is a block diagram of a communication system 40 in a wireless sensor network adapted to provide a communication link between a plurality of nodes, in one embodiment of the present technique. As illustrated, the system 40 includes a protocol stack 42, a preamble module 44, a communication module 46, a categorization module 48 and multiple nodes 50. The protocol stack 42 encapsulates multiple fundamental network protocol layers 52 that correspond to the open system interconnection (OSI) model, wherein each of the layers comprises of multiple modules 46. The preamble module 44 may be adapted to define a set of requirements for at least one of the application. The set of requirements may be specified by at least one user 54 and the preamble module 44 is defined based on a type of the at least one application. In one embodiment of the present technique, the type of the application may be at least one of a home security monitoring system wherein on occurrence of a phenomenon requires the stack to re-orient itself to a higher relay bandwidth, a remote region wherein the application will need to align the stack to reduce reliable transmission in the event of low battery or a sparsely populated sensor region where more reliable messaging is needed. The communication module 46 may be adapted for communicating data between the multiple nodes by selecting one or more modules from at least one of the layer of the protocol stack 42 to form an optimal combination of modules 46 indicative of the preamble module 44 defined. It should be noted that the optimal combination is based on quality of service (QoS) desired by the at least one application.
As will be appreciated by a person skilled in the art, in one embodiment of the present technique, the selection of one or more modules 46 from the at least one layer 44is randomly updated based on any change in the requirement of the at least one

application. Further, the selection of one or more modules from the at least one layer is dynamically updated based on any change in overall system context. It should be noted that an application in the present context refers to at least one of critical information or Reliability (combination of acknowledgements and re-transmissions, if required) or Link estimate for a strong outgoing link or Load balancing and congestion estimate or combinations thereof. In another embodiment of the present
As indicated above, the system 40 includes the categorization module 48 adapted to categorizes the at least one application into one or more categories for defining the preamble module. It should be noted that the categories includes at least one of the type of application or type of packets they carry or checking for real time packets or combination thereof.
In certain implementation of the present technique, the selection of the one or more modules 46 from the at least one layer 52 is based on the selected modules 46 in preceding layers and available modules in succeeding layers. In other words, while selecting a particular module from a particular layer, the module selected in the preceding layer and the module to be selected in the succeeding layer is also considered. In addition to this, the set of requirements defined in the preamble is also a factor while selecting the modules of any layer.
Considering the preamble module 44, it should be noted that the preamble module 44 includes at least one of a acknowledgement flag or a link estimated flag or data type flag or a retransmission flag or an application type or a real time flag or a load balance flag or combinations thereof.
FIG. 3, illustrates, bits of a byte preamble 60, in one aspect of the present technique. The stack is "dynamic" because based on preamble processing; it invokes specific functions from the available pool. Hence, an application wanting reliability gets it, and the ones not wanting it will not. As illustrated, the preamble consists of the following fields:
1) Acknowledgment Flag 62: This flag facilitates use of Link Layer acknowledgements to be used. It should be noted that this does not entail a

retransmission. This would only notify the upper layer of the ACK packet, depending upon the choice of solicitRetx() used. Default value for this is decided with the application type and data packet in question.
2) Link Estimate Flag 64: This would be used by application where loss is not tolerated. A good example might be a control packet. Enabling this ensures a strong link as a metric for the next candidate node, possibly even a trade off between short paths for it.
3) Data Type Flag 66: Packets are broadly classified as control information (which takes a higher priority) and data packets. The sensitivity of a data packet is further estimated on the application type.
4) Retransmission Flag 68: This flag indicates want of a retransmission upon failure of packet delivery. This requires Ack-Flag to be set.
5) Application Type 70: This is a two bit mandatory field, along with data-type flag, can help define default parameter values for other fields. Applications types are classified as point-to-point, multicast, broadcast and anycast.
6) Real Time Flag 72: This bit is also mandatory. Real time data is sent on a greater priority (and at par with control messages), compared to normal data. Real Time Data is also liable to undergo load balancing procedures, unlike control messages.
7) Load Balance Flag 74: When this flag is set, a forwarding node takes into
consideration load balancing as criteria in the next candidate hop selection. Packets
may be routed to a node that is less loaded with a possible tradeoff for a shortest path.
To be setting the fields, a set of API's is allowed to the application programmer. This offers flexibility in designing a wide variety of application types with specific tailor made requirements from the networks. An entire host of decisions can be taken based on the fields set.

An exemplary set of API's required by applications and the required macros is described below. Similar notation to that of TinyOS implementations is used to describe one aspect of the present technique.
Macro Usage
//Packet Type #define BEACON 1
#defme ACK 2
#defme CONTROL 3
#defme DATA 4
//Application
#define P2P 1
#define BCAST 2
#define MCAST 3
#defme ACAST 4
Interface used by application to Stack
interface ApplicationlnterfaceToStack {
//Acknowledgement
command result_t Enable Ack();
command result_t DisableAck();
//Link Estimation Decision
command result_t UseLinkEstimate();

command result -t; DiableLinkEstimate();
//Packet Type command result -t; DefinePacketType(int);
//Retx
command result-t SolicitRetx(int flag);
//Application type
command resultj; Define ApplicationType(int);
//Real Time Nature
command result_t IsRealTime(int flag);
//Load Balance
command result_t BalanceLoad();

Going by the bits in the preamble, a corresponding set of API's is exported to the application:
1) Enable Ack(), DisableAck(): This would set or unset link layer acknowledgement for packets delivered. Using this only informs the application layer of packet delivery status. The application is free to take action upon its discretion, like a retransmission.
2) UseEstimateLink(int flag): This would be used by application where loss is not tolerated. A good example might be a control packet. Enabling this ensures a strong link as a metric for the next candidate node, possibly even a trade off between a short path for it.
3) DefinePacketType(int flag): Used to define the type of packet generated, broadly a "data" packet or a "control" packet. All nondata packets are loosely classified to be of

control type by making the field in the preamble a flag type. This is done with a rationale that control packet is more sensitive to loss than a data packet.
4) DefineApplicationType(int): Used to define application as point-to-point,
multicast, broadcast or anycast
5) IsRealTime(int flag): This is further used to describe the nature of the application, in being real-time (latency sensitive but loss tolerated) or not real time (latency tolerated, but not loss). Real time data is sent on a greater priority (and at par with control messages), compared to normal data. Real Time Data is also not liable to undergo load balancing procedures, unlike control messages.
6) BalanceLoad(int flag): This bit lets dynamic load balancing to take place when a packet is at a node. When a packet is to be forwarded, depending upon the selections it has made, a suitable next candidate node is decided. Upon invocation of this function, a trade-off to a shorter path may be made to balance network traffic and curb growing congestion.
7) SolicitRetx(int flag): Most of the application types, broadly, do not require
retransmissions. It is wiser to make provisions to send sensitive data on a strong
channel than to send it on a pre-defined path and tolerate loss by retransmitting. Use
of this API enables link-layer retransmissions.
The general set of APT s described is a loose definition of a possible implementation. Providing API's allows application programmers to accurately describe their application demands and leave details of implementation to the lower layers with an assurance that resources are used in the most efficient fashion. Few of the rules that follow as an inherent inference to our classification of application types and demands in general are mentioned below:
1) A SolicitRetx() call is undefined when DisableAck() is called. Logically, one cannot make a provision for a retransmission if there are no acknowledgements.
2) Control messages, real time data and anycast messages are by default not provided an acknowledgement. Using the first clause, this would mean SolicitRetx() is also not

provided. Control messages are of a higher priority and it makes sense to send them on the strongest link possible to ensure they reach intended destinations(s). In case of real time data, loss of a frame/packet or two is usually tolerable, but latency is not. As an example, for a real time streaming application sending frames captured, a delayed or retransmitted frame is as good as a lost one. Likewise, an anycast packet has no specific destination in mind, and it makes sense to transmit it one time on a strong link.
3) Real Time and Broadcast Data packets are not given link estimates. Note that it is possible for an application programmer to write programs that make inefficient use of resources. For example, a real time application using acknowledgements, no load balancing and allowing retransmission of frames is possible to write with the given API's. The design hence depends upon the judiciousness of the programmer also. When unsure, one can proceed with only the required definitions (like type of data, application type and IsRealTime(flag)), and let the stack decide the best combination of activities to be performed.
Table 1 below is a schematic representation of some of the default definitions of different parameters as understood by the stack design, in certain implementation of the present technique.


Table 1.
Applications are classified on the parameters of the type of application they are (p2p, broadcast, anycast or multicast), the type of packets they carry (data or control) and whether they are real time or not. Such taxonomy is as shown in FIG. 3. The "Defaults" column lists the default action the stack takes when specific parameters are not asked for by the application code. Note that an explicit API call should naturally override the defaults, since the motive is to give flexibility and freedom to the

application programmer. The compilation is only a possible "default" setting. The control packets are rated as sensitive to loss. They are not provided acknowledgements (something like a beacon or an ACK packet itself would be a control packet). It is ensured that they are sent on the best possible link out of the given links to candidate nodes. Load balancing is disabled for p2p, but enabled for others. P2P data packets are provided with reliability (ACK's and retransmissions), are sent on strong links and are prone to be distributed for load balancing as well. Providing reliability here is more sensible compared to other applications like broadcast or a multicast since traffic is highly directional. The same is not true, however, for real time p2p data, where the sheer number of packets that may be transported might prove disastrous for a reliable communication. A general trend for real time streams is ensured, wherein reliable communication is disabled, disable link estimations and disable load balancing. Load balancing is disabled because the data is sensitive to latency. Also, there should not be any out of order packets, with varying delay times (a delayed packet is as good as a lost one). Broadcast, multicast and anycast data further are not provided reliability. In addition, the link estimate is also enabled for anycast data, never so for broadcast data. In order to explain certain application of the different parameters, two scenarios are taken to explain the same.
Scenario 1: Capturing temperature of entities in Zone "X" of a plant
This is a typical example of an application that captures a monitored entity and reports the same back to a base station or a monitoring terminal. An end user would typically be interested in data such as this. This is a multicast connection (to all sensor nodes in the vicinity of Zone X), Real Time in nature (can be continuously monitored for as long as the end user wants), is a "data" oriented application (no control information), demands load balancing for the route back to the end user (it would be appropriate to use load balancing), does not require link estimate (a best fit would be enough), no acknowledgements required (since it's a real time data) . In other words, this would by default ensure that no link estimate is made, and no acknowledgements or retransmissions take place. This is because a real time data has strict time bounds, and needs to be at the destination in a certain time. Reliability is not important here as in the former case, time to deliver data is. The application can tolerate a few losses in

frames, but can make no compromise on the time it takes to route a packet. Hence, the default settings choose no ack's, no retransmission, no link estimates, and no load balancing as well (in load balancing, sometimes a packet may deliberately choose a longer route so as to avoid growing network congestion at some point).
An exemplary sample run through the stack would look like this:
Application: 1. Candidate node selection (on a shortest path metric AND load balancing) 2. Send to candidate node 3. Send till sending buffer is full 4. close session 5. Energy efficiency determines when the node goes to sleep 6. medium access 7. physical layer.
Summarizing, the requirements for this application are:
No link estimate
No acknowledgements
No retransmissions
No congestion estimation
No dynamic load balancing, but can be provisioned at route acquisition
As can be seen, the requirements are for a lightweight transmission scheme that adds little to a basic communication. A possible run of protocols for this would be: Application, UDP, SPEED, SMAC, GAF and wireless medium. This is because UDP is a lightweight, fast, but an unreliable service. SPEED uses direction over IP for better route acquisition, SMAC unlike its counterpart BMAC does not provide any link layer acknowledgements or retransmissions.
Scenario 2: Sending control information to a particular mote
This is another typical application wherein and end user at a monitoring terminal sends a message or critical control information to either a specific mote (point-to-

point communication) or to motes in a general area (like motes in the boiler room). The information is critical and needs to be sent reliably. Losses cannot be tolerated, and it also has to reach the destination fast. One immediately sees the requirements for link estimation (to send on the strongest link), no load balancing, acknowledgements and re-transmissions on failure, control packet type data (critical). An exemplary run through the stack would look like the following:
Application 1. Candidate node selection 2. Estimate link to find candidate node 3. Use Load balance on the candidate nodes to arrive at the required candidate node 4. Send packet to candidate node 5. Send link layer acknowledgement to sender node 6. Wait for receiver to send an acknowledgement 7. If an ack is received, bring down session, else, retransmit packet until an ack is received from the destination 8. Energy efficiency determines when this node will go to the sleep mode 9. Medium access 10. Physical wireless link.
Referring back to FIG. 3 of 8 bits being numbered 0 to 7 (in order, from left to right). Bit 2 (Data type) as well as Bits 4, 5 (application type) need to be defined. Once this is done, most of the other parameters are inferred.
An application programmer would hence specify Bit 2 as 0 (denoting data), as well as application type to be 01 (p2p data). This is not a real time data, and is elastic in nature (the network makes the best effort to deliver this with accuracy, but no guarantee is given on how much time it might take).
It should be noted that an application in the present context refers to
Critical information
Reliability (combination of acknowledgements and re-transmissions, if
required)
Link estimate for a strong outgoing link
Load balancing and congestion estimate

These set of requirements are in fact in direct contradiction to Scenario 1. Protocol choices would include the following: Application, TCP, IP, BMAC, SPAN and wireless physical medium. TCP is connection oriented and highly reliable, IP ensures in-order delivery of the data at destination and has provisions for load balancing, TCP/IP takes care of growing congestion, BMAC is lightweight and provides for an additional link layer reliability in transmission, and SPAN is a highly energy efficient module.
It should be noted that in one aspect of the present technique, the selection of one or more modules from the at least one layer is dynamically updated based on any change in overall system context. In other words, it is possible for the stack to base decisions on the modules required from the context of the physical conditions (like battery charge left on the mote or growing congestion on neighboring nodes for example).
All nodes in the network exchange amongst themselves control information like battery level at the given node, congestion growing flag and signal strength. This packet also acts as the beacon for discovering neighbors that are likely to route packets.
Based on the above information, as well as a combination of modules selected in forming application specific requirements, the stack is in a position to adapt module selections on the fly. This is further elucidated:
Battery strength: Each node in its advertising beacon informs other nodes in the neighborhood about its remaining battery life. This helps nodes to making a better judgment of who to send packets to when wanting to route information.
Each node maintains a common battery threshold. If the battery level of a given node is less than this threshold, the node will normally not take in requests to route data, and might send a considerable amount of network time in the "sleep" mode (where battery consumption is at a minimum). Likewise, before sending a packet to another neighbor, the node checks to see the last battery life estimated provided by that neighbor. If it is less than the threshold, the packet is not normally sent (unless the data is critical and the given neighbor is the only neighbor).

Congestion indication flag: This is also advertised by nodes along with beacon information. This indicates growing congestion at a node which acts as a relay for traffic passing through it. If packets are dropped at that node due to buffer overflow because of growing congestion, this flag is set until the buffer queue length is less than the buffer size (usually, a threshold is again applied here). This is beneficial for routing data packets and datagrams of a large transfer size, whereby no one particular node is congested and traffic is evenly distributed. This also ensures that nodes do not go down because of an uncontrolled upsurge of packets at a node which is a bottleneck for many communication paths, and hence keeping such nodes accessible when critical information is to be relayed on a shortest path.
When a node wants to send data, it will normally send it to a neighbor with least congestion if load balancing is a criteria for the applications datagram. Again, if the information is critical and a given node is the only neighbor available, this would be over-ridden.
Signal strength estimation: Each beacon that is received at a node also acts as an intrinsic source of signal strength to that node available (based on the strength at which at the beacon was received). This allows a node to estimate signal strength if the application datagram has a demand for a node with the highest signal strength (critical data).
Besides this, the stack also chooses modules depending upon the modules already selected as well. For example, if modules are so selected such that control messages are minimum (because available signal strength is low), this standard will be consistently maintained across module selection at all the layers. This is done dynamically for every packet. This aspect of the stack makes it most attractive for large unattended networks of sensors. The network will adapt to the present conditions and will ensure a very high network lifetime and hence prolonged and accurate monitoring of the given phenomenon.
As indicated earlier, the present technique is not concentrated more on individual layers, the theme has been on making a harmonious stack rather than deal with

advancements in every layer. From the preceding sections, it should be clear that such architecture makes an efficient use of resources. One could imagine an integration to be of the following type: a stateless routing protocol; minimal neighbor information estimating link strength, congestion, constructed using beacons or acknowledgements; link layer acknowledgement and a retransmission mechanism; a medium access mechanism and finally interface to the physical medium.
The set of API's affect the routing protocol as well as the link layer. The choice of next candidate routing node would be based on suitability (in terms of a node being a "candidate" node if it can take the packet to destination). A candidate node would then be put to a test of link estimate and load balancing tests (if they are enabled) in that order. At the end of the entire process, the appropriate node is selected and the packet forwarded.
A note may be added on finding the "candidate node". This may be found using "direction", using addresses or any suitable mechanism. The end result would be a set of nodes who can "potentially" take the packet forward towards the destination.
FIG. 4 depicts an exemplary path 80 of a packet from application layer 81 to physical layer, in one embodiment of the present technique. Actions upon receiving a packet at a destination or at an intermediate hop would be similar in nature with suitable changes to the calling functions. The packet starts at a candidate node 82. The packet stops at the routing and the link-layer 84. At the routing layer, once a pool of candidate nodes 82 are identified, one can perform link estimate 86 (of a higher priority) and then a load balance test 88 may be run, based on settings in the preamble. The set of processes feeds into the Packet* SendTo (node*) function 90, which would prepare the packet to be sent the selected node. In addition to this, there are modules for energy efficiency 92 and medium access 94, which are explained earlier. Protocols may be used from the choice of available ones present or ones to come. The packet is finally pushed through the physical NIC card 96.
The packet at Link Layer 84 takes another decision. If ACK 98 is demanded, the bits are appropriately set. Alternately, if a bi-directional session is already running

between two nodes, one can use this packet to piggyback pending ACK's for the destination. If retransmission is solicited, the packet is additionally buffered handled by the Retransmission (Retx > Buffer Packet) module 100. In addition, various modules are formulated for energy efficiency 92 and medium access 94. Protocols may be used from the choice of available ones present or ones to come. The question remains as to how "stack aware" such architecture would really be. The guidelines as prescribed earlier are executed to investigate: • Application demands: The entire architecture is to ensure applications get the best and most suitable service they require from the stack. • Adaptability: Modular nature ensures adaptability since functions (or layers) may be conveniently added or replaced. • Layers leverage benefits of using one another: This is an important issue, since one has to make sure that protocols selected ensure this property. At one level, when applications make appropriate function calls, they already ensure much of this property to a good degree. Care must be taken to ensure that the set of protocols selected must also have this property. • Implementation Experience: Tested protocols already in the community make good choices. Implementations of them working together may be an issue.
As will be appreciated by those skilled in the art, though reference is made to the above scenarios, however, other similar scenarios known in the art may also be used with the present technique.
FIG. 5 is a flowchart depicting a method in a wireless sensor network adapted to provide a communication link between a plurality of nodes comprising a protocol stack encapsulating a plurality of fundamental network protocol layers that correspond to an open system interconnection (OSI) model, wherein each of the layer comprises a plurality of modules. The method starts in step 120, wherein a set of requirements is defined by at least one user for at least one application using a preamble module. At step 122, data is communicated between the plurality of nodes by selecting one or more modules from at least one of the layer of the stack to form an optimal combination of modules indicative of the preamble module defined, wherein the optimal combination is based on quality of service (QoS) desired by the at least one application using a communication module. It should be noted that the selection

of the one or more modules from the at least one layer is based on the selected modules in preceding layers and available modules in succeeding layers.
As will be appreciated by a person skilled in the art, the selection of one or more modules from the at least one layer is dynamically updated based on any change in overall system context. Further, as described earlier, the preamble module is defined based on a type of the at least one application. The method further includes a categorization module adapted to categorizes the at least one application into one or more categories for defining the preamble module. In certain implementation of the present technique, the method includes mapping the set of requirements for the at least one application to available modules in at least one of the layers of the protocol stack on a per packet basis based on the processing of the preamble module. It should be noted that wherein the selection of one or more modules from each of the layers is randomly updated based on any change in the requirement of the at least one application. In certain implementation of the present technique, the specific embodiments are described with respect to the
As will be appreciated by those ordinary skilled in the art, the foregoing example, demonstrations, and method steps may be implemented by suitable code on a processor base system, such as general purpose or special purpose computer. It should also be noted that different implementations of the present technique may perform some or all the steps described herein in different orders or substantially concurrently, that is, in parallel. Furthermore, the functions may be implemented in a variety of programming languages. Such code, as will be appreciated by those of ordinary skilled in the art, may be stored or adapted for storage in one or more tangible machine readable media, such as on memory chips, local or remote hard disks, optical disks or other media, which may be accessed by a processor based system to execute the stored code. Note that the tangible media may comprise paper or another suitable medium upon which the instructions are printed. For instance, the instructions may be electronically captured via optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.

The sequence of instructions as explained in the method steps may include but not limited to, program code adapted to define a set of requirements for at least one application using a preamble module. The sequence of instruction further includes program code adapted to communicate data between the plurality of nodes by selecting one or more modules from at least one of the layer of the stack to form an optimal combination of modules indicative of the preamble module defined, wherein the optimal combination is based on quality of service (QoS) desired by the at least one application using a communication module. It should also be noted that the selection of the one or more modules from the at least one layer is based on the selected modules in preceding layers and available modules in succeeding layers. Further, the sequence of instruction includes a categorization module comprising program code adapted to categorize the at least one application into one or more categories for defining the preamble module and a program code adapted for mapping the set of requirements for the at least one application to available modules in at least one of the layers of the protocol stack on a per packet basis based on the processing of the preamble module of the protocol stack.
While, the following description id presented to enable a person of ordinary skill in the art to make and use the invention and is provided in the context of the requirement for a obtaining a patent. The present description is the best presently-contemplated method for carrying out the present invention. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles of the present invention may be applied to other embodiments, and some features of the present invention may be used without the corresponding use of other features. Accordingly, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest cope consistent with the principles and features described herein.
Many modifications of the present invention will be apparent to those skilled in the arts to which the present invention applies. Further, it may be desirable to use some of the features of the present invention without the corresponding use of other features.

Accordingly, the foregoing description of the present invention should be considered as merely illustrative of the principles of the present invention and not in limitation thereof.

WE CLAIM:
1. A communication system in a wireless sensor network adapted to
provide a communication link between a plurality of nodes, the system comprising:
a protocol stack encapsulating a plurality of fundamental network protocol layers that correspond to an open system interconnection (OSI) model, wherein each of the layers comprises a plurality of modules;
a preamble module adapted for defining a set of requirements for at least one application; and
a communication module adapted for communicating data between the plurality of nodes by selecting one or more modules from at least one of the layer of the stack to form an optimal combination of modules indicative of the preamble module defined, wherein the optimal combination is based on quality of service (QoS) desired by the at least one application;
wherein, the selection of the one or more modules from the at least one layer is based on the selected modules in preceding layers and available modules in succeeding layers.
2. The system as recited in claim 1, wherein the set of requirements is defined by at least one user.
3. The system as recited in claim 1, wherein the preamble module is defined based on a type of the at least one application.
4. The system as recited in claim 1, wherein the preamble module includes at least one of a acknowledgement flag or a link estimated flag or data type flag or a retransmission flag or an application type or a real time flag or a load balance flag or combinations thereof.
5. The system as recited in claim 1, wherein the selection of one or more modules from the at least one layer is randomly updated based on any change in the requirement of the at least one application.

6. The system as recited in claim 1, wherein the selection of one or more
modules from the at least one layer is dynamically updated based on any change in
overall system context.
7. The system as recited in claim 1, wherein the preamble module comprising a set of API's exported to the at least one application.
8. The system as recited in claim 1, further comprising a categorization module adapted to categorizes the at least one application into one or more categories for defining the preamble module.
9. The system as recited in claim 8, wherein the categories includes at
least one of the type of application or type of packets they carry or checking for real
time packets or combination thereof.
10. A method in a wireless sensor network adapted to provide a
communication link between a plurality of nodes comprising a protocol stack
encapsulating a plurality of fundamental network protocol layers that correspond to an
open system interconnection (OSI) model, wherein each of the layers comprises a
plurality of modules, the method comprising:
defining a set of requirements for at least one application using a preamble

module; and
communicating data between the plurality of nodes by selecting one or more modules from at least one of the layer of the stack to form an optimal combination of modules indicative of the preamble module defined, wherein the optimal combination is based on quality of service (QoS) desired by the at least one application using a communication module;
wherein, the selection of the one or more modules from the at least one layer is based on the selected modules in preceding layers and available modules in succeeding layers.

11. The method as recited in claim 10, wherein the selection of one or more modules from the at least one layer is dynamically updated based on any change in overall system context.
12. The method as recited in claim 10, wherein the preamble module is defined based on a type of the at least one application.
13. The method as recited in claim 10, further comprising a categorization module adapted to categorizes the at least one application into one or more categories for defining the preamble module.
14. The method as recited in claim 10, further comprising mapping the set of requirements for the at least one application to available modules in at least one of the layers of the protocol stack on a per packet basis based on the processing of the preamble module.
15. The method as recited in claim 10, wherein the selection of one or more modules from each of the layers is randomly updated based on any change in the requirement of the at least one application.
16. A computer program product used in a wireless sensor network tangibly embodying a plurality of instructions for providing a communication link between a plurality of nodes comprising a protocol stack encapsulating a plurality of fundamental network protocol layers that correspond to an open system interconnection (OSI) model, wherein each of the layers comprises a plurality of modules, the computer program product comprising computer-readable media having computer-readable code, the computer program product comprising the following computer-readable program code for effecting actions in a computing platform:
program code adapted to define a set of requirements for at least one application using a preamble module; and
program code adapted to communicate data between the plurality of nodes by selecting one or more modules from at least one of the layer of the stack to form an optimal combination of modules indicative of the preamble module defined, wherein

the optimal combination is based on quality of service (QoS) desired by the at least one application using a communication module;
wherein, the selection of the one or more modules from the at least one layer is based on the selected modules in preceding layers and available modules in succeeding layers.
17. The computer program product as recited in claim 16, wherein the
preamble module is defined based on a type of the at least one application.
18. The computer program product as recited in claim 16, wherein the
selection of one or more modules from each of the layers is randomly updated based
on any change in the requirement of the at least one application.
19. The computer program product as recited in claim 16, further
comprising a categorization module comprising program code adapted to categorize the at least one application into one or more categories for defining the preamble module.
20. The computer program product as recited in claim 16, further
comprising program code adapted for mapping the set of requirements for the at least
one application to available modules in at least one of the layers of the protocol stack
on a per packet basis based on the processing of the preamble module of the protocol
stack.
21. The computer program product as recited in claim 16, wherein the
selection of one or more modules from the at least one layer is dynamically updated
based on any change in overall system context.