1. Introduction
-
MAC layer design: MAC layer algorithmic changes are required to realize native and foreign-channel access by multiple WSNs. A disconnected sensor node or even a group of such sensor nodes utilize the presence of other networks’ nodes in its transmission range, communicating with them using certain channels. Algorithmic modifications are proposed in association procedure that allows native and foreign channel access and scheduling of nodes of co-existing sensor networks.
-
Routing protocol design: Algorithmic changes are incorporated in the implementation of routing protocol in order to make multiple sensor networks mutually beneficial. The idea is to give sensor nodes the provision to employ nodes of other sensor networks for route discovery and data delivery.
-
Overhead modeling: The proposed architecture is mathematically modeled in terms of energy overheads associated with MAC layer design and routing.
2. Related work
3. Problem definition
4. Proposed architecture
4.1 Design elements
-
The operator’s first choice must be its home network, switching to cross-network communication only when home network is not available.
-
The design must be mutually beneficial for all co-operating sensor networks. A sensor network offers routes to other networks while utilizing the routes through them for connectivity of its isolated nodes.
-
The participation of nodes in cross-network communication must not be overwhelming compared to their participation in native network operations. There must be well-defined criteria to distinguish traffic these nodes carry for the native network from the cross-network traffic. Such criteria would ensure to limit packet processing at nodes that are not supposed to handle the cross-network traffic otherwise the design would not remain economically feasible for native network operations.
-
The design must be transparent to the application and transport layer of nodes executing the applications.
-
The new set of algorithms and protocols for cross-network communication must be based on existing standard protocols.
-
The design must be simple to integrate medium access, routing and data delivery algorithms and protocols.
4.2. Design assumptions
-
Sensor nodes operate in low duty cycle to save energy thus ensuring long network life.
-
Each sensor network has gateway(s) and the data communication takes place between sensor nodes and gateway.
-
We assume fixed channel assignment instead of dynamic channel assignment in sensor networks in order to minimize interference and reduce complexity.
-
The data communication paradigm can be event based (triggered by sensor nodes) or on demand (triggered by gateways).
-
The reconciliation of co-existing networks is managed through wired inter-connection in order to exchange information related to co-operative routing and data communication.
-
The networks operate using non-overlapping addressing schemes such that a sensor node can identify a packet by the addressing scheme of source/destination.
4.3. MAC layer design
4.3.1. Channel assignment for co-existing sensor networks
4.3.2. Implementation of shared channel connectivity
4.4. Routing protocol enhancements
4.4.1. Route discovery
-
Route request: The modified RREQ packet is shown in Figure 5a. The field ‘Nets’ is added before ‘hop count’, and ‘trailer information’ about contributing networks is appended at the end of the packet. ‘Nets’ represents the number of networks, other than native network that have forwarded the RREQ packet. If the packet is only processed by the native network (e.g., when packet is sent via native channel) the value in ‘Nets’ would be zero which means packet has no trailer information and is only using the native network resources. The trailer is appended to represent the networks that have forwarded the RREQ packet. Each network that forwards or broadcasts the packet inserts its unique 8-bit network ID and count of packet relay (8-bit “relay count” field). Thus, the ‘Nets’ value reports the number of exterior networks that participate in packet transmission and the trailer entries that are appended at the end of the packet provide information about those exterior networks.
-
Route reply: Route reply process is similar to the single sensor network route reply process with the same modifications as described in route request process. The role of ‘Nets’ value and packet trailer information is same as described in RREQ packet format and the packet format for RREP is shown in Figure 5b.
-
Algorithm at sensor node: The sensor node runs an algorithm for common channel route discovery which is simple and is explained as follows:1.If a packet arrives through flooding and requires response, the sensor node sends response packet with ‘Nets’ field set to zero without any trailer information. An example of this case is the arrival of RREQ packet.2.If a packet arrives through unicast and requires response, the sensor node sends response packet with the same value of ‘Nets’ and trailer fields as in the arriving packet. This way the gateway is informed about the complete forwarding information of packet round trip. An example of this case is receiving data packet.3.RREP and ACK packets do not require response thus there is no special handling for these packets at the sensor node. Data packets are not part of the route discovery process and are discussed later.
4.4.2. Gateway functionality
-
Route discovery process
-
During the route discovery process, the gateway tracks the record of relays by foreign network nodes through ‘Nets’ field, corresponding Net IDs and their relaying counter. Two possible scenarios in route discovery are:
-
If route discovery is initiated by sensor nodes, receiving gateway records external network relays listed in RREQ packet. The gateways distinguish RREQs by RREQ source address and RREQ ID. If RREQ is not already registered with gateway, it registers it in database and responds with RREP. If already registered, it updates the record. This gives an accurate measurement of reverse path and related data path cost.
-
If route discovery is initiated by either of the gateways, all gateways broadcast RREQ with same RREQ ID because destination node is unknown. The destination node responds to first arriving RREQ as per AODV, and RREQ corresponds to the path between node and closest gateway. The closest gateway notifies the originator gateway if it is not the originator of RREQ packet itself. RREP informs gateway about the cost of RREP.
-
Management information sharing
-
Each sensor network belonging to an operator is associated with a management and database server. The central database server is linked with each gateway and records attributes of the shared network resources. Individual database servers of each network operator are connected to the central database server in order to exchange pricing information. The gateway upon receiving a packet through shared channel updates its database server. These databases are RREQ database and unicast database (Figure 6). RREQ database records the arrivals of RREQ packets. A gateway may receive duplicate RREQ through different paths as a result of flooding but RREQ arriving through the shortest path is added in database after ensuring that RREQ is not registered at other gateways of the same operator. ‘Gateway ID’ is the destination address of the receiving gateway that responds to the RREQ through the shortest path. ‘Source Node ID’ is the ID of the node originating RREQ and ‘RREQ ID’ is the ID of the RREQ packet. Hop count is the minimum hop count value in arriving RREQs. ‘Relay count’ is the hop count in foreign networks identified through their respective ‘Nets’ fields (see Figures 5 and 6). For each arriving RREP or data packet, the gateway updates the unicast database for recording the cost of traversal. This method is useful for measuring the cost of transmission of packets in unicast since the exact number of forwarding by each network is retained in the packet. Figure 7 gives the algorithm at gateway to handle RREQ, RREP or data packets. The database information is periodically updated by individual database servers at the central database server for reconciliation of revenue based on predefined network resource sharing agreement.
4.4.3. Handling route errors
4.4.4. Data delivery process
5. Mathematical analysis
5.1. Overhead at MAC layer
Parameter | Value |
---|---|
E
r
| 0.0123 J |
BI | 1.92 s (for BO = 7) |
SD1 | (a) 0.015 s (for SO = 0) to 0.48 s (for SO = 5) |
(b) 0.015 s (for SO = 0) to 0.96 s (for SO = 6) | |
SD2 | (a) 0.06 (for SO = 2) |
(b) 0.03 (for SO = 1) |
Parameter | Value |
---|---|
E
r
| 0.0123 J |
BI | 1.92 s (for BO = 7) |
SD1 | (a) 0.48 s (for SO = 5) |
(b) 0.96 s (for SO = 6) | |
SD2 | (a) 0.015 s (for SO = 0) to 0.06 (for SO = 2) |
(b) 0.015 s (for SO = 0) to 0.03 (for SO = 1) |
5.2. Overhead at routing layer
Parameter | Explanation |
---|---|
N
| Total number of networks |
n
j
| Number of nodes of a sensor network |
A
| Area of deployment (in m2) |
ρ
j
| Node density for a single sensor network (nodes per unit area) |
r
o
| Transmission radius of node (in meter) |
λ
j
| Average rate of route requests/node for sensor network |
Network 1 | Network 2 | Network 3 | |
---|---|---|---|
Number of nodes | 70 | 75 | 60 |
Area (m2) | 100 | 100 | 100 |
Transmission radius (m) | 1.5 | 1.5 | 1.5 |
Node density | 0.7 | 0.9 | 0.6 |
5.2.1. Routing overhead optimization
5.3. Packet overhead
6. Simulation results
Parameter | Explanation |
---|---|
Standard | IEEE 802.15.4 |
Total number of sensor networks | 4 |
Terrain (area) | 1000 × 1000 m2 |
Number of nodes in area | 60 |
Number of nodes in observed network | 32 |
Simulation time | 100 s |